• Reported by liorean

Well, that is the position taken by Bert Bos (W3C) at the Web Applications and Compound Documents workshop W3C held recently. Brendan Eich, inventor of JavaScript and maintainer of the Mozilla roadmap, reacts on his blog Brendan's Roadmap Updates.

Now, I'm wondering what gripes Bert Bos have with JavaScript, really. He don't back his statements up by any examples of why JavaScript is such a bad invention, or really what is bad about the language. From what I can gather from his statements there, I really see very little in his statements there that does in any way target JavaScript specifically, so what is it that he really attacks with that statement? I wasn't at the workshop, so I'm probably only half wrong here, but let me give you my take on JavaScript's place in the world at large.

What is JavaScript, really?

First of all, let me describe what JavaScript is - my words, my view - and describe why I think mr. Bos is attacking the wrong piece of a chain of linked technologies. JavaScript is a modern, advanced, higher level programming language based on a slim, implementation and usage neutral, environment and platform neutral core language. This language has it's quirks. It's gone trough an evolution of incremental improvements that have led to many bad design decisions and language peculiarities that have not been removed despite excellent chances of doing so, probably because of corporate-political reasons and the commitee driven development of the standard, ECMA-262, that is the real definition of the language. JavaScript itself is not in any way confined to the browser as host environment. JavaScript is a scripting language, and besides PERL it may very well be the most deployed scripting langauge in usage today. Where can we find JavaScript besides in browsers? We can find JavaScript as a server side scripting language in both ASP (JScript) and the ONE server platforms (Netscape/Sun servers), we can find it in vector graphics formats such as Flash (ActionScript), SVG (ECMAScript 3/JavaScript1.5) and even the page description format PDF. We can also find it as the underlying language for much of the Mozilla application, and we can find JavaScript --> Java bytecode compilers as well, for application space. ECMAScript 4 (JavaScript2.0, JScript.NET) may be compiled, and is much more suited for application development using classical C/C++ derived object orientation methodics. JavaScript may be used by XAML, XUL, Flex (MXML) to create applications using Avalon, Mozilla GRE or Flash as the base environment. What I want to point out here is that JavaScript should not be considered a browser technology, or at least not any longer.

However, JavaScript as seen in browsers contain have other factors than the core language, which is the only part of the language that is standardised. In browsers we have the host bindings, relations to the browser environments, and the DOM. We also have persistence relations (cookies), privacy and security concerns, as well as accessibility and user integrity concerns. Of these, only the DOM is really standardised, but only at a host objects level, not a host instances level. The client side environment from JavaScript 1.1 could be considered a de facto standard since it's implemented across all browsers, though it is not a de jure standard.

Documents versus user interfaces

One of the distinctions that have crystallised with the new trend in web development is the clear user interface versus document distinction. More and more web developers consider web pages to be documents, where the contents are what you provide, but where disruptions of the user interface are considered bad form. You shouldn't make links open in new windows per default since the user should be in control of opening new windows - it's better if you suggest to the user they're better off opening a new window. You shouldn't disable right click or the context menu, since the context menu is a user convenience feature and not a part of the document, and is important for accessiblity. You shouldn't colour the scrollbars or change the look of form controls, since those are user controls that are made for the user to be able to interact with in a user environment (operative system/window handler/application environment) specific way, and should not be changed for that.

To counter this web site = document view we have the web application = user interface view. A web applications provides a user with a user interaction related feature set, and tries to describe and define the functionality, the user interactions and the behavior as well as the presentation of something that is not really a document, but an application. Currently, if you really want control, Flash or Java are your best choices. If you are willing to give up some control, you can let HTA, signed scripting or simple web pages do the same job. This is less reliable, but more accessible.

Back to Bert Bos

disclaimer: Of course, this is what I read out of Bert Bos's statement, and nothing he's explicitly stated. Conclusions drawn are my own and should not be considered to be his view.

What I read out of Bert Bos's statement, is nothing such as JavaScript - the language - being a bad invention. In fact, I consider that a bad choice of wording for a not that exceptional a view. What I read out from it is a twin message.

• For web applications the web page paradigm, using the document metaphor, is insufficient. Web applications need user interface control, more well defined user interactions control, more well defined graphical descriptions, than is possibly using the environment provided by browsers today, using JavaScript as behavioral and functional control technology.
• The host environment and script association mechanisms for JavaScript are not well defined and standardised enough to be able to achieve the kind of controll wanted from the web application, and are not integrated sufficiently for efficient application control.

Back to me

Well, that's what I read out of it from my position. I'd love to hear more from Bert himself on the issue, but that's what I can make out of it.

My solution to the problem I read out from Bert's statement is that we need two standards. One for the document metaphor, and one for the user interface metaphor. We need a web application language that has better defined behavior and user interaction control, better graphical control, better user interface control. In difference from him, I believe this can and should be built from existing technologies for existing browsers. I believe this is best created by introducing a document-application separation for the (X)HTML, CSS, DOM and JavaScript technologies, and a better defined and held-together interaction and description model. I believe this is what WHAT are in the process of making, and what will eventually be the web applications platform of choice for most usages. Anything based on XForms or SVG will take too long in the standardisation, too long in the making, too long in the implementation, and especially too long to propagate to the users. For the future we need something that can build on current technology, not something built on future technology. For all we can dream of perfection, we are in need of a smooth transition. If nothing else, this is the lesson Netscape's decline shouild have tought us. The web lives it's own life, and leads it's own development, defying control. We can only try to lead it in a way we feel is better.

The W3C are led less by web related interests and more than server and plug-in interests than I believe they should be, if they want to lead the developmen t of the future of the web. Instead of improving the web, they are developing standards and taking decisions that are device, server and transaction related rather than web related. The major members are not at all in the direct web business, neither as user agent manufacturers, web development shops, web content providers nor web transaction handlers. They are application side shops, and that is hurting the development of the web and web related specifications.