The future of JavaScript

Written in November 2003. Will not be updated, though I will probably write another piece on this very interesting subject.

After my site's launch Tristan Nitot reacted on his StandBlog. Apart from some slightly ad hominem remarks, he raised one valid and important point about the future of JavaScript.

Nitot writes:

"To defend him, one must note that PPK is primarily a Javascript developer, which isn't quite the same as a web developer. He's into Javascript and the DOM. He's into writing programs that run in web pages. But the times of tag soup are gone. 11% of users don't have Javascript enabled. What could be done previously with Javascript only can often be emulated with CSS. Remember pure CSS menus, tabs with sub-menus, or rollovers that all required Javascript, and that are done with CSS nowadays.
In the same way that Java nearly disappeared from web pages, Javascript is dwindling. Evidently, PPK can't stand this perspective and holds on to his field of expertise. It's human, and even very common among web developers who hold on to their old habits."

Is JavaScript dwindling? I don't think so. Nitot has some of his facts right, but his conclusions are wrong.

Irrelevant facts

Let's go through his assertions:

"To defend him, one must note that PPK is primarily a Javascript developer, which isn't quite the same as a web developer. He's into Javascript and the DOM. He's into writing programs that run in web pages.

I am a web developer. I immediately agree that JavaScript is my strongest point, but I've written HTML without <font> tags since early 2000 (yes! even in commercial projects!), and I've solved my share of CSS bugs.

But the times of tag soup are gone.

True, but it doesn't have anything to do with JavaScript. JavaScript can work on a GoLive generated HTML house of horrors or on cutting edge XHTML 1.1 Strict. Coding style doesn't matter, as long as you can access the HTML elements you need.

11% of users don't have Javascript enabled.

For years I've felt that the majority of these noscript browsers are actually search engine spiders. These high numbers usually come from large stat farms like TheCounter whose browser detection methodologies I've always distrusted.

Browser detection is a subtle art that's easy to botch. If 90% of the available JavaScript browser detects are unable to identify Opera at all times (Opera's identification string always contains Opera, but the writers seem to be unaware of that fact), I shudder when I think of browser detects written by server side programmers who don't work with browsers on a daily basis, and I certainly don't trust their secret applications to predict the future of JavaScript.

Besides, the average end user doesn't know what JavaScript is and that it can be turned off. Therefore I do not believe that end users turn off JavaScript in large masses. Of course a sysadmin could do it for them, and there are still a few companies that disallow JavaScript for security reasons, but 11%?

Finally, the reported noscript figures at TheCounter have remained stable for years:

May 2003 13 %
May 2002 12 %
May 2001 12 %
May 2000 17 %

These figures don't show a clear upward trend of noscript browser market share.

In the same way that Java nearly disappeared from web pages, Javascript is dwindling.

JavaScript is not dwindling. It's not Java, either.

Relevant facts

What could be done previously with Javascript only can often be emulated with CSS. Remember pure CSS menus, tabs with sub-menus, or rollovers that all required Javascript, and that are done with CSS nowadays.

Here Nitot snaps back to the right track. This is a very perceptive remark, browser incompatibility problems aside. In fact I have recently reached the same conclusion.

In the past people have focused far too much on the presentational side of JavaScript. Mouseovers and sliding layers, especially, were the great examples that "proved" that JavaScript was "really cool".

Whole flocks of wannabe web developers bought bad JavaScript books that taught them how to get mouseovers and DHTML working, browser detects and bloat code included for free, so they learned to see JavaScript as something like Flash, something to do cool stuff with, like sliding layers.

Nowadays CSS has become good enough to handle most of the presentational side of websites. Are mouseovers presentational? You bet. And DHTML? Most of the time. What do we use to code them? CSS. Simple, efficient. CSS can't do sliding layers, but we've got to get rid of them anyway. If you want animations, use Flash.

Nitot rightly points to the fact that JavaScript's traditional function is heavily eroded by the advance of CSS, and he wonders what JavaScript is good for, if not for doing "cool" presentational stuff.

Although I agree the question is perfectly valid and very important, I do not share his hurried conclusion that, like Java, JavaScript is on the way out.

A changing of roles

JavaScript has a PR problem. It's been associated with sliding layers too long. So let those dusty layers slide out of sight forever and reveal ... what?

JavaScript needs a new job description. It's going to have to prove itself all over again to a critical audience of web developers who want to know exactly why they should use JavaScript.

In the same way that Java nearly disappeared from web pages, Javascript is dwindling. Evidently, PPK can't stand this perspective and holds on to his field of expertise.

Evidently, Nitot cannot envision a JavaScript that adds value to a standards compatible, accessible XHTML/CSS page and holds on to his sliding layers mindset.

Need to have

The new style of standards compatible coding lays heavy emphasis on the structure of XHTML document. These documents contain information that should be presented "semantically correct" and in an accessible way. So in the end it's all about delivering information.

However, merely delivering the information is not enough. Users should be allowed to sift through the material and to compare files. On their own XHTML and CSS offer only two ways of sifting and comparing: by including all the information the user wants in one long sequential page, or by linking to relevant other files.

Don't underestimate these two functions: they always work. They'll keep a site accessible at all times. They are "need to have" functionalities.

Nice to have

Nonetheless large amounts of information cry for a way to be searched and sifted in a user friendly way. This is a "nice to have" functionality that XHTML/CSS can't deliver, except through endless reloads from the server.

Wouldn't it be great if a large majority of the audience (89%, according to Nitot) would get a better, more usable way of sifting and searching, for instance by silently loading small XML files with the necessary data, to be read and presented in the user's main search menu as they come in?

Wouldn't it be great if the user can remove an item with a single mouse click? Or enlarge it, or compare a paragraph to a bit of text in another document? And without the reloads that inevitably cause a slight desorientation and a short wait? JavaScript can deliver all that, and more.

Accessibility should not restrict usability

A site should be accessible to any device. That does not mean, however, that its usability should be limited to what the lowest common denominator of user agents can handle.

Way back in 1999, when CSS began to become reliable, many of us did not use it because our sites had to work perfectly in Netscape 3. Back then, "accessible" meant "looking exactly the same in all (major) browsers". Out went CSS, in came nested tables.

Disallowing JavaScript-powered layers of usability would be exactly the same silly decision. "If it doesn't work in screen readers we can't use it!". Nonsense. Once you've created a solid XHTML structure you can put anything you like on top of it.

CSS, for instance. Or JavaScript.

The future of JavaScript

JavaScript is meant for adding layers of usability (and not presentation) on top of structural, simple XHTML documents. These layers of usability will probably allow users to organize the data they receive, and maybe also to send out new data queries.

Although there are countless applications and programs that do this, JavaScript is unique in being seamlessly integrated in 89% of the most important data access applications there are: the browsers.

Evidently, PPK can't stand this perspective and holds on to his field of expertise. It's human, and even very common among web developers who hold on to their old habits."

What shall we do with the W3C DOM?, I asked only a year ago. Hardly an old habit. I'm still searching for an answer, too, so it's not becoming an old habit in a hurry, either. I think my Usable forms script is a step in the right direction, but the work has hardly started yet.

All this is vague, I know, but I don't quite know what I'm looking for myself. I'm still searching. That's human, and even very common among web developers who are looking for new ways of making websites.

The burden of evidence is very much on the shoulders of JavaScript developers. We'll have to convince the other web developers that JavaScript is good for more than sliding layers.

Duly noted.

I hope that in a year or so I can point M. Nitot to a convincing example of what JavaScript can do for the usability of a standards compatible, accessible XHTML/CSS page.

In the mean time I would like him either to soften his tone a bit, or not to write about my projects at all.