In June of 2004, W3C held a workshop on the future of client-side Web applications. I presented there and said, right in front of Brendan Eich, the inventor of JavaScript, that JavaScript was the worst invention ever. So what did I mean by that?
Right up front, let me say that I didn't mean that JavaScript is a bad programming language. It's a pretty straightforward language. Whatever its particular strengths and weaknesses, I wasn't referring to any of those.
My remark was in the context of client-side Web applications. I had just compared the situation to that of ten years earlier, when typography was what people were asking for and the browser makers responded by adding attributes to HTML. People that thought ahead a bit realized that HTML was more useful without such attributes and that styling was better done with style sheets. Likewise, HTML is more useful without scripting; downloadable applications are better built with a specialized technology.
What I said at the workshop was a bit longer than just what my slide said. The fact that Netscape allowed JavaScript programs inside HTML to modify that HTML is one of the biggest factors, if not the biggest, why HTML hasn't fulfilled its promise as a device-independent format for reusable information. In other words, it is an obstacle to the Semantic Web.
Scripting is worse than stylistic attributes/elements (<font>, <center>, color=, etc.) Those make the text harder to read if you aren't using a graphical browser on a color screen, but at least the text is still there. You can index it, print it out, transform it, etc. And luckily, people are using them less and less, in favour of style sheets. It has taken ten years before authors realized that Web pages aren't always read with a graphical browser and that style sheets really do make Web sites easier to manage, but with the advent of mobile browsers and other non-desktop Web tools, device-dependent HTML pages are getting rarer.
So what are the problems of scripting?
First of all, the page you download isn't the page the author wants you to see. Which is a problem if you have JavaScript turned off (which more and people have, for many of the reasons mentioned below), if your browser doesn't support JavaScript, or if you aren't using a browser at all, but downloading the page for other purposes, such as printing, indexing, syndicating, analyzing in other ways or converting to a format for reading on a PDA, for example.
JavaScript also changes the document while you read it. Which means, for example, that you cannot print it and you cannot bookmark it.
Scripting makes a document behave in unfamiliar ways. Everybody has his favourite browser and especially if you browse the Web a lot, it is a big time saver if you can rely on the browser to behave identical no matter what Web page it has loaded. You can almost navigate with your eyes closed. Moving the mouse has no effect, apart from some stylistic changes, clicking has a specific, predictable effect, depending on whether you click a hyperlink or a form control, you can toy with forms any way you like and fill them in backwards, because nothing happens as long as you don't hit the submit button.
But Javascript changes that. Suddenly, the keyboard behaves differently, the mouse doesn't do what you expect, forms are submitted without any action from you. In short, you are slowed down and very frustrated.
JavaScript is a programming language and it executes programs on your system that you didn't write and that you didn't install. But JavaScript doesn't have any of the security safeguards that Java, Perl and others have. There is no “sandbox” that contains the program and keeps it from accessing your system. And thus bugs in the interpreter can be exploited by writers of viruses and worms.
JavaScript is a big hurdle for the Semantic Web. HTML isn't a full-fledged knowledge representation language, but it is static, declarative and it has some useful structures, and thus it can be exploited by search engines and other robots that process information on behalf of a user who doesn't want to go and read every page himself. But JavaScript turns the page into a program. Understanding what a program does is difficult even for humans, let alone for computers. Computers are good at executing programs, but that is not the same thing.
Thus a Web page that has the actual information hidden in JavaScript is lost for posterity. Unless a human reads the page and puts the information in a form that computers can do something with, the page might just as well not have been written. Which is a waste of resources and a pity as well. Maybe there was actually something worth keeping in that page…
JavaScript isn't very good at what it is supposed to do either. When people want to distribute programs instead of document and try to do that by writing the program as a mixture of HTML and JavaScript, the results aren't what they could have been if those people had had access to a real client-side Web applications technology, with a GUI language instead of a document mark-up language, a system that automatically worked on non-graphical browsers and that allowed multiple UIs for the same program.
I've written elsewhere about what such a technology might look like (and an essay on requirements), so I won't go into that here. I called a client-side Web-based application a “proglet,” because “Web application” is much too wide a term (it also includes server-side applications) and to both associate and distinguish it from “applet.”
JavaScript might well be the programming language in a proglet, although Ruby and Python also seem good candidates.
Java is the only currently available system for client-side Web applications, but it is too advanced for many of the things people want to write programs for. And because applets are meant for complex programs, they lack some of the nice features that a simpler proglet can have (in particular, device-independence).
Because Java is available and because most Semantic Web people concentrate on declarative knowledge, proglets have been ignored for too long. Proglets are good for certain kinds of procedural knowledge for which Java would be overkill. It will be a difficult fight to undo the damage that JavaScript has done to the Semantic Web. Style sheets took ten years to be accepted, even though they were available from very early on and it took the mobile phone revolution before authors realized their benefit. How long will it take before people will use proglets instead of JavaScript and HTML? First we have to develop the proglet technology, of course. But maybe now that desktop browsers aren't the only clients on the Web anymore, it won't take ten years. Let's be optimistic.
Bert Bos