<a href="/old?u=http%3A%2F%2Fwdvl.internet.com%2FRealMedia%2Fads%2Fclick_lx.ads%2Fintm%2Fwebdev%2Fwww.wdvl.com%2FAuthoring%2FScripting%2FModular%2Findex.html%2F3763%2F125x125-1%2FActivePDF_4d%2F125x125_blue_DC2_clickTAG.html%2F64316564656561333364663233643830%3Fhttp%3A%2F%2Fwww.activepdf.com%2FAdTracking%2F4guys%2F125x125-DC.asp&y=1999"><IMG SRC="/old?u=http%3A%2F%2Fwdvl.internet.com%2FRealMedia%2Fads%2FCreatives%2FHouse_Partners_1c%2F125x125_backup_GIF.gif&y=1999" WIDTH=125 HEIGHT=125 BORDER=0>

In the evolution of browsers from mere hypertext viewers towards meta-operating systems we gained the ability to process data and interaction from within the browser. Where previously we had to rely on the Web server to execute any instructions, the introduction of LiveScript which quickly morphed into JavaScript enabled Web developers to execute certain types of scripts on the client-side, saving bandwidth and increasing response time. At first, script code was simply embedded within the HTML document, but this rubs against the traditional aim of programming to create modular and portable code. Several enhancements to the scripting environment help the developer separate program code from HTML markup; while still immature, these techniques indeed work towards the goal of taking Web scripting seriously. This article examines the few methods available today for externalizing your Web scripts in attempting to keep them modular, portable, and outside HTML. Experience with HTML markup and embedded scripts will be useful; we'll be using JavaScript as our de facto scripting language although there are alternatives (Microsoft's VBScript, ActiveState's PerlScript, etc.)

Contents:

Why not embed?