2013-01-14
Why JavaScript (or something like it) is in demand
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.)
Good JavaScript usage is a good thing
A commentator on yesterday's entry wrote the standard sort of anti-JavaScript note. Quoted in part:
[...] 99.9% of websites do not need scripting. (Perhaps 100% -- google maps should be a standalone program.) I am convinced JS is a make-work phenomenon by a large amount of underemployed web-monkeys, desperate to create "work" that is not needed. [...]
I disagree strongly. Despite my grumbles yesterday and despite my use of NoScript to mostly block JavaScript in my own browser, I am all for well-done JavaScript usage. There are two things that JavaScript is really good for.
The first and most obvious is enabling interactive web applications that would not be possible otherwise. Google Maps is a good example, as are a number of other highly interactive and responsive websites (some of them operated by Google). The second is for augmenting already functional websites with additional useful interactivity, a topic I have some experience with. There are any number of websites that do this (if you browse with JavaScript on you probably don't even notice this).
It is no accident that I've emphasized interactivity in both cases. The problem that JavaScript fixes is that without it your only real way of interacting with a web page and a web server is by clicking on things and generally getting a new web pages. Clicking on things is a fine way of getting stuff done, but the problem is that it is obtrusive, limited, and explicit. There is a universe of other ways of interacting with an application (eg clicking and dragging) and another universe of automatic actions that an application might want to take without requiring the user to explicitly invoke things with a click.
What's bad about JavaScript is threefold. First, people have used it to do evil things. Second, people have used it to create terrible, obnoxious interfaces. And third, what I ranted about yesterday, people have used it to destroy otherwise functional websites. But none of these are intrinsic in JavaScript itself. JavaScript is a tool that can be used well or used badly.
Sidebar: Why I disagree that Google Maps should be a program
I will put it simply: if Google Maps was a program, it's likely that I would not be able to use it and it's even more likely that people using FreeBSD would not be able to use it. The advantage of JavaScript applications is that they are more or less portable more or less for free.
(This is not just portability between operating systems. It is also portability between Debian, Fedora, Ubuntu, SUSE, and so on, and between old distribution releases and new ones.)