Why JavaScript (or something like it) is in demand

January 14, 2013

I've recently formed an opinion about why people keep wanting JavaScript, or perhaps I should say instead 'come to a realization'. Put simply, people want to increase the interactivity and responsiveness of their websites.

Let's rewind to the old days of basic HTML websites, which you have to admit are neither very interactive nor very responsive. You interact with such sites pretty much only by clicking on links (or form submission buttons) and they respond by giving you a new web page, which is usually both disruptive and not really fast; your browser window clears then fills in, things may shuffle around, your position on the page almost certainly changes even if the page looks more or less the same, and so on. This is workable but very limited and not particularly attractive; in many ways it goes against almost every tenet of good GUI design that we know.

(Part of the appeal of frames was that they were less disruptive this way because not all of the web page shuffled itself around when you clicked on links.)

Modern HTML and CSS improved this by adding support for a certain amount of standardized interactive behaviors and elements (eg you can now make pure HTML/CSS dropdown menus); because they're rendered in the browser as changes to page appearance they have basically instant responsiveness and don't require your browser to fetch a new page (with all that that implies). But this support can only go so far because in practice there is a fundamental conflict between simplicity and comprehensiveness (and thus flexibility) in specifying interactivity. The more options for interactivity you offer to people, the more complex the descriptions of those options need to be. Fully general interactivity requires a very general way to specify the logic involved, to describe what happens and when.

A very general specification of logic is called 'a programming language'. You cannot have general interactivity without a general language. The more restricted you make your language the less interactivity you can create. If you want as much interactivity as people can design, you need a general language. Hence, well, JavaScript.

(In this sense HTML plus CSS is a language, although an odd and rather restricted one.)

Note that this has nothing directly to do with browser vendors refusing to implement enough specifically hard-coded interactivity features in HTML and CSS. Even if they wanted to, they simply can't make HTML plus CSS powerful enough to cover the union of what everyone wants without turning it into a programming language. And a lot of language design experience suggests that doing so would actually suck badly (see, among other things, XSLT versus the programming language of your choice, and note that XSLT is Turing-complete).

(It also doesn't directly have to do with browser vendors not wanting to implement interactivity features at all. Implementing JavaScript plus all of its DOM and event hooks is implementing interactivity features, it's just not as visibly so as, say, new CSS properties. Implementing better JavaScript may also be a better use of limited browser engineering time because the browser developers can offload developing specific interactive behaviors to page designers.)

Now, you can have a vision of browsers as environments that should have deliberately limited interactivity and responsiveness and then argue from this vision that they should not support JavaScript and other ways of enabling 'too much' interactivity. There are even some reasonably rational arguments you can make for this position. However this argument is doomed to be very unpopular because people want to make pretty much everything more interactive and responsive (since that's a great way of improving the whole experience of using almost anything).

(This realization is undoubtedly obvious and well-trodden ground among the general web development community. I'm slow sometimes and I'm only an occasional tourist in this area.)

Sidebar: one potential rational argument against flexibility

The short version: common and unified interfaces. The more flexible you make interactivity, the more different websites can be from each other. You can argue that a great benefit of the browser over other interfaces is that everything has a common UI (especially in old school HTML) and that browsers should continue to act to enforce a relatively common interface by (among other things) limiting people's ability to create non-standard interactivity.

(Standard interactivity is offered through the browser's HTML and CSS, because the browser can control what you can do and how the result looks to give everything a uniform appearance and interface.)

If you want to make this argument you should be prepared to also argue against a number of current HTML and CSS design options because they do just as much damage to a common 'web UI' (if not more). For example, every CSS option that allows designers to confuse people about what is and isn't a link.

Sidebar: the purpose of CSS and HTML in this model

In this model, CSS (and HTML with it) has two purposes. The first is to be the rendering engine for the (JavaScript-based) interactivity logic. The second is to encapsulate sufficiently common patterns of interactivity into a form where you can express your intentions directly (and then the browser can execute them directly), much like how and why people add new functions to a standard library.

(As a consequence, if all you want is sufficiently common interactivity you can create it without needing JavaScript at all.)

My impression is that you can see both sorts of additions in modern CSS.

(I think I may have now horrified all of the designers who care about CSS. I've sort of horrified myself, honestly.)

Comments on this page:

From at 2013-01-16 16:49:42:

Another rational argument against flexibility (JavaScript): security. Imagine if every single random click of your mouse ran an unreviewed (and probably malicious) piece of C code -- how comfortable would you be? If instead of my de-centralized, community reviewed C-based email client (sylpheed), I download a completely different (and possibly malicious) one, every single time? JavaScript tries to naively bypass distributions and program packaging, as if de-centralized reviewing and community and packaging is something obsolete. In truth, JS supporters are merely appealing to the lowest-common-denominator of attention-deficit netizens, who don't know or care about security or software. Capricious consumers.

Another rational argument against JS: practically speaking, it only works on bleeding-edge new machines, and probably only those running a particular brand of JS compiler. (Certainly not the one that ships with my webkit-gtk browser.) I lost count of how many times JS laden websites crashed my browser, or took minutes to render at 100% cpu. Whatever theoretical gains should have been offerred by reloading an entire static page are definitely lost in the real world.

By cks at 2013-01-16 17:30:11:

Another rational argument against flexibility (JavaScript): security. Imagine if every single random click of your mouse ran an unreviewed (and probably malicious) piece of C code -- how comfortable would you be?

The difference here is less the language and more the level of sandboxing involved. JavaScript is extremely heavily sandboxed (and as a result is very, very restricted, limited, and controlled). I would be happy to download and run precompiled binaries (in any language) if they were as heavily and as well sandboxed as JavaScript is. In many ways I would rather run a JavaScript based web application than a native application from a source that I didn't entirely trust. The JS app may try to track me; the native app may screw up my entire workstation.

(Note that Java is not as well-sandboxed as JavaScript. We don't need theory for this, we can simply observe it in the real world: Java gets exploited for native code execution and JavaScript pretty much doesn't. I will leave theories about why this is for other people.)

Another rational argument against JS: practically speaking, it only works on bleeding-edge new machines, and probably only those running a particular brand of JS compiler.

This is not my experience and I have some quite old machines. Yes, there are environments with bad JavaScript interpreters just as there are bad C compilers, but there are also any number of environments with good JS interpreters that run on modest hardware. In addition, JavaScript used for increasing a website's interactivity and responsiveness is generally not what you would call particularly CPU-consuming.

From at 2013-01-16 23:17:12:

There are countless "execute arbitrary JS code" exploits:


And countless cross-site scripting vulnerabilities:


That can "potentially disclos[e] secret information or transfe[r] money without the victim's authorization"

Are drop-down menus really worth that risk?

From at 2013-01-23 10:07:42:

Just a recent article on the question of why java gets exploited so often: http://kohsuke.org/2013/01/20/javafx-needs-to-be-a-new-edition-of-java/

- Jeremy

Written on 14 January 2013.
« Good JavaScript usage is a good thing
How I drafted (okay, wrote) an entry in public by accident »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jan 14 23:52:57 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.