JavaScript grows up

You might ask why hasn't this already happened?

Part of the reason is that JavaScript is only now being taken seriously - partly because of the apps that are being created to demonstrate that HTML5 can be a platform for web apps and partly because some programmers are at last seeing the future clearly. The CommonJS project for example only got going in 2009 and  NodeJS is only just over a year old.

A language that we have lived with for 15 years is suddenly emerging from its scripting days.

What is really interesting is that if you look at many of the so called HTML5 based web apps you can see that they could have been written using HTML4 and a bit of lateral thinking.

If you still don't believe that JavaScript will inherit the earth simply ask yourself what killed XML?

The answer is, of course, JSON.

You can argue that XML is an over complex and verbose way of getting tree-structured data coded in a form that we can process. If you have XML then you have to work quite hard to process it. If you have JSON then the data is already in a form that can be instantiated at once to JavaScript objects. Is it any wonder that it and JSONP are becoming the norm for data exchange?

What is even more indicative of the shape of things to come is that you now see JSON being used to explain the structure of data that has nothing to do with JSON or JavaScript in articles and books.

Notice that this not an argument that JSON is better than XML just that it is making in roads not only into what we use but the way we think.

One language to rule them all

So why should JavaScript spread just because it is to be the powerhouse of the client side web app?

Well the simple answer is programmers like to use one language.

I can write code in a range of different languages but after writing code in one language it takes time to swap to another language. It is obvious that there is a penalty in, say, swapping from PHP to JavaScript and then back again. It is possible, it isn't even difficult, but it isn't as efficient as thinking in one language and this extends to debugging and refactoring.

Language swapping needs a good reason and not just the unintelligent one of "the language isn't available".

When you think how hard it is to work with two-tier applications that demand that you move your attention from client to server and back again then you can also see that it makes no sense to make this round trip harder by a language swap on the way!

Put simply - no matter how clever we think we are and no matter what our language loyalties are, working in a single language is usually easier than working in multiple languages unless there is a very, very, very good reason.

Dystopia?

So JavaScript is going to rule the planet.

How should you feel about this?

I like JavaScript. No not the boring underutilised language dialect that you find in badly put together web pages, but the full-blooded, dynamic, object-oriented, functional language as used by Google and others to implement major systems.

Even so, being a JavaScript enthusiast doesn't mean that I can't see the dangers into sleepwalking into a situation that potentially takes programming back to the dark ages. To build the next generation of applications we need to move forward. If the inevitable does happen then no doubt JavaScript will evolve, acquire the tools and infrastructure it needs to be the language of the 21st century and in time it won't be recognisable as JavaScript.

You can argue that this has already started to happen - but also you can argue not fast enough.

What we really need is language flexibility.

In this day and age I should be able to pick the language for the job and just use it on the client side or the server side, in or out of the browser. The logical way to have done this is to include a byte code interpreter or some other design of virtual machine able to run any language within the browser.

A second best option would be to freeze a subset of JavaScript now and treat it as a byte code. In either case you could then run any language for which there was a compiler.

This is of course what Google Web Toolkit does with its Java-to-JavaScript compiler, but it isn't ideal because it still exposes too much JavaScript to the programmer. It is as if the JavaScript is a layer that can be invoked to save you from any serious problems.

For JavaScript as intermediate code to work we have to abstract way from it as far as possible.

My best guess is that because JavaScript looks like a just-adequate, high-level language most programmers will attempt to use it and regard compilers that target it as a crazy idea getting between them and "reality".

The situation is not a happy one. As the masses treat HTML5 with love and affection we need to realise that

from here on in it's JavaScript all the way down...