Why not embed?
Given the lashing we've slapped at embedding scripts within HTML, the natural question is "what's so wrong with embedding?" Indeed, embedding scripts inside HTML documents is the model on which client-side scripting has been built, and to a certain extent is unavoidable as a result. There are two types of arguments against embedded scripts: philosophical and practical. Both merit consideration.
A common mistake in Web-parlance, especially among those without hands-on development experience and/or within enhanced resumé lingo, is to call HTML a "programming language." It is not. HTML is a markup language and this difference is quite meaningful. A programming language proper supports a set of instructions to the computer which can flow in a logical manner; "logical" in this case used literally -- that is, certain things can happen when conditions meet certain criteria. Conditions can be evaluated, criteria modified, and so on, using logical evaluations. A programming language supports instructions which process data, whether that includes evaluating data so as to make logical decisions or modifying data through calculations and other operations. HTML can do none of these things -- HTML's sole purpose in life is to give structure to the data which makes up a page of information. Secondarily, HTML is often used to apply aesthetics to this structure, such as font sizes and colors, although purists would rightfully argue that this is the job of CSS (Cascading Style Sheets) and not HTML proper.
The introduction of LiveScript, now commonly known as JavaScript (although now technically but uncommonly called ECMAScript), brought the abilities of a programming language into the Web page. This was a good thing, but literally mixing the two languages -- programming and markup -- within the same document and in some cases within the same line, results in cross-pollution that is conceptually misleading and practically difficult to manage.
| For the typical developer there is no meaningful distinction between "scripting" and "programming". It's unclear whether there is even an official distinction; one might say that scripting has tended to refer to languages which are lightweight, meaning they possess a limited amount of intelligence and are easy to learn while programming has tended to recall the traditional computer language which many find more esoteric and computer-science oriented. One might also say that scripting languages tend to be interpreted on-the-fly while programming languages tend to be based on source code which is compiled into platform-specific binary code. Still, these distinctions are growing ever muddier, as newer languages such as Perl are script-like in agility yet fully "intelligent", and can be both interpreted and compiled. |
Practically speaking, many web sites are not created entirely by a single omniscient individual -- often several people with several strengths work to create the final product. Some folks are HTML gurus while others are style fanatics and yet others are programming gods. Mixing together programming language within HTML within a single document makes life difficult for these folks who would be more productive working on their own distinct modules which can be pieced together to create the final product.
Traditionally, the art of program design endorses two major architectural styles: modularity, which eases the maintenance and modification of complex programs by subdividing them into meaningful components, and portability, which roughly equates to "don't reinvent the wheel". Adherence to either style is difficult in a world where script is embedded within an unrelated markup language, yet both styles are critically important to large and complex programs, as Web-based scripts are inevitably becoming.
Creating Portable and Modular Client-Side ScriptsCreating Portable and Modular Client-Side Scripts
Modularity
