JavaScript rules everything

Warning: this article may stir up controversy. When I talk about the past, present and future, I mean internet applications. Enterprise applications are a world of their own and follow different rules, though it would be surprising if none of what follows affected them.

Image could not be loaded. Illustration of the Big Bang

When you work with a group of people building an application with a particular technology, as I did at GoodData, you get a chance to learn a lot and put your understanding of that area in a wider context. It has been quite a few years since I wrote JavaScript myself. Honestly, I would consider the code people write today a different language. The language itself has stayed the same in many respects. What changed was the architecture of client applications. Naturally, that brought into use constructs and approaches we didn’t need before.

It used to be normal to use client-side JavaScript only to prepare data for submission to the server or to manipulate UI elements on a page. That era ended when asynchronous requests to the server, known as AJAX , appeared, and servers began sending partial responses alongside complete ones. Application architecture suddenly moved toward what we call a rich client.

Going round in circles

Software architecture is like fashion, history, design or anything else. We go round in circles, hopefully a little wiser with each turn. We once ran away from fat clients, partly to spare their limited resources. Now we are returning to them because server resources are even more limited. Some ideas work differently on a local network than on the internet.

JavaScript used to play a supporting role on the client. Now it is the workhorse. The client decides when the application moves from one state to another, a job that used to belong to the server. Of course, that puts more code on the client at once. JavaScript developers are suddenly looking for ways to write client code (some of the application logic) using the Model-View-Controller pattern so it stays maintainable and doesn’t turn into spaghetti. It won’t be long before client applications need inversion of control to solve tight coupling too, if they don’t already.

The change in client application architecture has also put browsers under pressure, especially to deliver fast, memory-efficient JavaScript engines. The V8 engine in Google Chrome is powerful enough to serve as the basis for the nodeJS server, which is built entirely around JavaScript.

JavaScript as the dominant language of the “desktop”

Image could not be loaded. Two wrestlers in a match

If application architecture is changing, it’s fair to ask why. The answer lies in where our data and the services we use are going. They live on a remote computer now, with the desktop, or more precisely the browser, acting as a terminal. Aren’t we back where we started? If any language comes to dominate the desktop, meaning the place from which we use services and data, it will undoubtedly be JavaScript, the language of the platform (the browser) on which these applications run.

If you ask me which language to learn with an eye to the future, I’ll answer JavaScript without hesitation. That includes the surrounding ecosystem, of course, such as JSON and HTML 5.

Conversely, there’s little point in debating which language is the future of the server, because it hardly matters to the architecture internet applications will have.