JavaScript considered harmful (was Re: New online index to Be azley's tutorials)

[Delaney, Timothy]

> From: aahz at panix.com [mailto:aahz at panix.com]
> 
> Note that I don't even call JavaScript evil.  I just point out how
> useless and dangerous JavaScript is, and let people draw their own
> conclusions.  ;-)  Seriously, my only objection to JavaScript is when
> it's *required*; ditto for cookies.  If people want to create a
> JavaScript-enhanced or cookie-enhanced browsing experience, 
> that's fine
> with me.

There are however certain circumstances where a non-javascript version of
something is not feasible.

For example, in a particular project I worked on, the results of a search
page as straight HTML ended up being approx 2MB in size. Not feasible over
our international link. However, there was a desire to have all the results
returned on a single page (rather than having to skip through say 100
results at a time). This was after all an admin site where the users were
expected to know what they were doing. I must admit that much of that desire
was mine (as I was one of the people at the time who would be using it
most).

Of course, I would consider anyone who performed a search without specifying
any criteria there to *not* know what they were doing, but it's always
possible to accidentally submit something. The majority of search requests
should only return a few records (in fact, most would probably return a
single record). It was important that my solution not harm the most common
case in its attempt to help the pathological case.

My solution? Send all the data as a single Javascript string (fields
tab-delimited, records cr-delimited). Then a client-side JS function parsed
the string and produced the required HTML.

This had multiple advantages - #1 being that I didn't have to send all the
HTML, #2 being that each piece of info only needed to be sent once, and
could then be used as many times as required (for example, both appearing in
a generated URL, and appearing in the textual representation of the URL).

There are of course, some disadvantages - the need for Javascript being #1
and memory use being the #2. It was very important to only deal with one
record at a time. However, the solution used ended up with very little extra
memory overhead (a poor solution could have really blown out memory usage
however).

In any case, the final page ended up at approx 100K - 1/20 the original
size. I was tempted to huffman compression on the JS string, but in the end
decided that I had met my requirements and anything further would be
over-engineering (and just for the fun of it, no less).

Even the common case of returning only a single result produced smaller
pages (although not by much). Time to actually *lay out* the produced page
was similar in the patholigical case both with straight HTML and the JS
version. The difference is that the HTML version had the additional overhead
of downloading 20x as much information, and then had the same layout
overhead.

There is much to be said for using client-side dynamism to reduce the amount
of traffic across the network - especially in a world where we are still
dealing with the majority of net connections being 56Kb/s.

Tim Delaney