Why not embed?
March 15, 1999
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 Scripts
Creating Portable and Modular Client-Side Scripts
Modularity
|
