To mark the 25th birthday of JavaScript we have refreshed an article on the language from 2011 - so does JavaScript inherit the earth? Read on for a look at how things were.

Forget Java killers or any other language killers, JavaScript is about to ensure the mass extinction of every other programming language on the planet. This isn't a mass extinction by design or disaster - it is simple negligence.

We seem to be sleepwalking into an event of huge importance. We are about to promote JavaScript into the most important computer language ever.

Yes that's right - JavaScript.

JavaScript is set to become the single most used language in the near future simply because of the HTML5 bandwagon and the enthusiasm we seem to have for web apps. You may argue about the next Java killer, but I can tell you now it is JavaScript.

You may think that Scala is an elegant language, you may even yearn for the days of Lisp or Fortran but they are all, both the new and the old, dead meat.

We are handing the keys to the empire over to JavaScript - it is as simple as that.

OK you may not like it and you may want to take issue with me, but wrapped up in the assumption that Web 3 is all about HTML5 is the deduction that the language of client side coding is going to be JavaScript.

The reasons are obvious. JavaScript is the only language supported on standard browsers and you cannot expect the end user to have a browser that supports anything else. Rather than implement a virtual machine approach to browser language implementation, we have adopted a single language for all approach.

Why?

I can't be sure and neither can you but it seems that in the case of the web the tail is still wagging the dog.

What color would you like your web app?

Despite the fact that the revolution of Web 2 was about  dynamic web applications and databased websites, what are we concentrating on? Semantic markup and making things look pretty using CSS. All of the headline news is about how HTML5 is going to bring about the new revolution amounts to prettier typography and multi-column layouts. For some reason the revolution seems to be hung up on what things look like not on how they behave. Even semantic markup leaves everything to be desired in that you might well use it but we have little idea what to do with it next.

OK - so HTML5 is good, CSS3 is good but where is the push to make programming the thing better? We have JavaScript and to make life a little more interesting we have some new sub-systems - Canvas, Websockets, web helpers and even WebGL if Microsoft ever manages to see that standards are a good thing.

All good but... where is the "big push" for programming language support?

Why is it we can focus on what color the web app is but never ask how best to code it or what is needed to get the more difficult job done.

Where we are

I'm not going to bore you with the fine details of why JavaScript stagnated but it is worth figuring out where we are today.

JavaScript was the first scripting language to be supported by browsers and it has never lost that lead. It has been standardised as ECMAScript but most still call it JavaScript. It has been through three major revisions but version 3 (JavaScript 1.8) is more or less the version you meet in the real world today  and it was completed in 1999 - which makes it ten years old. Version 4 was supposed to make it into the real world but basically it all fell apart because no one could agree on what should be in the language or out of the language.

Now we have ECMAScript 5, which is at long last working its way into browsers that people actually use. This said, the changes to create ECMAScript 5 are welcome but small and we will probably be writing ECMAScript 3 for some time to come as we wait for older browsers to die away.

The issue really isn't just the core JavaScript language either. Why for example has the DOM long been regarded as a second class citizen? OK, you may want to maintain that JavaScript is a pure language that runs anywhere but in most cases the interaction of JavaScript with the DOM is vital to the way applications work .

Equally you can pretend that the DOM is something separate from JavaScript but what other language makes as much use of it? If we are serious about making JavaScript our number one language we should recognise the DOM as being its fundamental framework and make DOM objects full JavaScript objects.

Server Side and  client side

So you still don't like the conclusion that JavaScript is about to rule the planet - especially so when you realise how little effective effort has been put into improving it. 

You might try consoling your self with the thought that JavaScript is client side and this means that its important will be well fenced in. You can still continue to use your favourite server side language and ignore JavaScript. You might even stretch this point to include out of browser applications on the client side. So .NET, Java, Ruby, Python, PHP etc.. they all have their niches either server side or where no sensible browser would venture.

Well think again - JavaScript is coming.

As JavaScript becomes even more important than it is there is no way that you are going to ring fence its use into "client side".

Just look at what is happening at the moment with NodeJS which lets you work perfectly happily on the server side. Notice that NodeJS in itself isn't particularly innovative, other languages have also used an event driven I/O approach to web services. NodeJS just happens to work with JavaScript, which programmers who know the language prefer. The CommonJS project is working hard to produce an environment for JavaScript outside of the browser and this extends its reach not only to server side apps but to client side, out-of-browser apps.

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...

Update

It is odd to read what I wrote almost a decade ago and to realize how things have changed. Now JavaScript, or rather ECMAScript, is updated every year and it has so many new toys it is difficult to know where to start. JavaScript is mature and it is firmly number one. The only sign that anything might be about to push it to one side is the development of Web Assembly - although even this cannot work without JavaScript to act as an intermediary between it and the DOM. The rise of web apps never actually happened to the extent that we thought it would and the fuss about HTML5 simply died away. Today our only hope for web apps is PWA - Progressive Web Apps - even if no one is quite sure what this means.

For more reasons why JavaScript is unique, for better and, arguably, in some instance, for worse, see JavaScript Jems: The Amazing Parts (I/O Press) by I Programmer founder and CEO, Mike James.

• Ian Elliot is the author of several JavaScript titles. Just JavaScript: An Idiomatic Approach, intended for programmers who are familiar with another language takes a radical look at JavaScript that takes account of the way it is object-based. JavaScript Async covers asynchronous programming in JavaScript, async/await, Promises, Service Workers and so on.  His latest book, JavaScript Bitmap Graphics with Canvas, shows you how to use Canvas to create graphics without resorting to a library of any kind.

Related Articles

JavaScript Is Basic's Offspring

JavaScript The Language With Two Names

JavaScript Beginners Book Choice

Advanced JavaScript Book Choices

<ASIN:1871962579>

<ASIN:1871962560>

<ASIN:1871962501>

<ASIN:1871962528>

<ASIN:1871962625>

<ASIN:1871962420>