Tim McNamara

Why JavaScript will rule the world

This article discusses a few reasons why JavaScript will become the programming language for everything. The main driver discussed is the move towards cloud computing. Depending on one’s perspective, users are either first or second class citizens as a result of this movement towards JavaScript. I’ll try to cover a few arguments and then come to some conclusions near the end.

Reason 1: Effect of Cloud Computing

My suspicion is that the increase in the use of JavaScript is so that companies can outsource the expensive computation required of modern web applications to their users. I first cottoned on to this by watching Pamela Fox’s discussion about how the Google App Engine “should” be run. As an aside, Pamela’s from Google’s Sydney office and I met her at LCA2010. She’s a genuinely great person.

One assumption that underpins this argument is that disk space and memory are fairly easy to distribute, while computation is not. Therefore, cloud computing platforms should try to avoid computation as much as possible, because it’s much more difficult to scale. Therefore, the more computation that companies can send to their users, the lower their overall costs. This explains why Google has created an open source JavaScript engine. The faster the world’s JavaScript is, the cheaper their overall costs.

On the demand side, interacting with JavaScript is probably far faster than interacting with another computer over a network. Therefore, if users have a fast JavaScript implementation running, they can presumably get better-than-Internet speeds when using applications on served via the Internet.

Where’s your evidence?

We can take a look at pricing structures for rough estimates of how much things cost. It is not a perfect model, but it is better than nothing.

The Windows Azure Pricing structure charges 12c/h for CPU, but 0.15c/month/GB for disk space. If we assume that a month has 730h, e.g. 24*365/12, this works out to be something close to 0.0002/h/GB.

As a matter of comparison, Google App Engine is significantly cheaper, with its data storage costs of 0.10c/month/GB and CPU cost of 10c/h. That is, it’s somewhere between 20 and 50% less expensive on these two metrics. Amazon’s EC2 is cheaper again for CPU time, with its smallest instances being available for 0.085c/h although its high-durability storage is closer to Microsoft’s at 0.14c/GB.

The trend is that computation is more expensive than disk space. Its generally charged per hour, and That’s a fair bit cheaper than CPU cycles. It goes to show that it appears much cheaper for these infrastructures to scale disk and memory than it is to scale CPUs.

What incentives does this create?

Pricing structures like this make it very attractive to push computation to users. This means using JavaScript to process intensive parts of the application. I have no idea of the actual numbers, but for Google, it means that if their users get a JavaScript implementation that is 2% faster, they will potentially save millions running the Google Docs suite and other applications.

This means that it’s in shareholders’ interests that Google continues to spend lots of money improving the open source V8 engine and providing it for free. As long as the company saves money overall, its shareholders are better off.

Reason 2: Adobe Flash is being hurt

Apple’s decision not to support Flash will increasingly render the platform anemic. Apple’s market follows their leader, and their leader has said that Flash is bad. Apple tends to draw developers and designers that are creative and more demanding of (visual) design than CSS2 can provide. These are exactly the kind of people that would be pulled away concerns about poor search engine optimisation, inaccessibility in the pursuit of an enhanced web experience for the bulk of their users.

Given that they can’t have that rich web experience on their iPads, Adobe Flash doesn’t look likely to win this format war.

Reason 3: Mobile computing

A more general discussion needs to be had around the effect of the mobile web on the rest of the Internet. JavaScript implementations can be added to most devices fairly easily, even if Java ME and other solutions were there first on embedded solutions. This means that the Internet has become a true method of delivering applications that are independent of the architecture.

I’m actually a little disappointed that this is a reason. It should be clear that mobile devices are much less powerful than a datacentre. Therefore, it seems to make sense to do the hard parts of delivering a web page, the computation, in the datacentre. Then again, maybe the datacentre is living up to its name, just being the centre for delivering data.

Reason 4: JavaScript has good parts

The final major reason why JavaScript will rule the world is that is actually a language with fairly good fundamentals. To become convinced, you should read JavaScript: The Good Parts or watch the lecture if you can’t afford to spend money or more than an hour looking into it.

What does this change?

Sending data and instructions to a web client mixes the current standard. Ever since the emergence of Ruby on Rails, most web application frameworks have used the MVC pattern to produce web applications.

Pushing instructions to the client to process bends, and may break, this model. At some level, things remain the same. You’re code is just being evaluated by a processor on the other side of the world. You could just be sending your model, parts of the controller and the view to the client to process, rather than processing things yourself. However, given that there are so many different ways to implement this kind of computational outsourcing - I think that pure MVC implementations are likely to struggle in a price-sensitive world.

This means that smart, price-aware developers will not be using the 2005-onwards breed of web frameworks. They’ll be trying to export as much as possible in a cache-friendly manner. I expect that in a while, you will see projects like Pjyamas rise to the top. Pjyamas takes Python source code and compiles it into JavaScript. This means that you can have the readability, testability and maintainability of Python with the benefits of sending computation to the client.

The changes for for developers and companies are also intriguing. Sending JavaScript means sending source code. Therefore, more and more will be made open source. This is a big win for technological innovation. In a future post, I’ll provide some reasons justifying this.

It will also create another digital divide. People kept behind corporate restrictions on their internet browser are almost certain to experience a dramatic slow down in the performance of the web. I’ve heard first-hand accounts of government departments here in New Zealand that are stuck on IE 6. The internet browser for 2001 is not the internet browser for 2011.

What about the users?

Will this move benefit people, or just decrease the costs to the providers of the internet applications? It should benefit both parties. Networks are slow and unreliable. CPUs and RAM are much faster and reliable. Therefore, if it’s possible to send data & instructions to a user, the whole experience should be faster and more reliable.

However, things are not quite that simple. It’s probably the case that a move to sending data and instructions, rather than HTML, will make the web much more difficult for some users. The people affected will be behind corporate restrictions and stuck on old technologies and will become increasingly frustrated with the web.

Final thoughts

Overall, I think that a move towards JavaScript will create a new paradigm of web development. People have been experimenting with NoSQL for a while now. It’s about time that we take a look at other bottle necks when delivering excellent web experiences. I just hope that it wont leave people that rely on screen readers, text browsers and horrible internet browsers with nothing.

One thing that I am looking forward to is the use of JavaScript & web browsers to undertake distributed computing. No need to install BOINC, you just need to point a browser at an HTTP resource for instructions.

Feedback

Please send comments to my Identi.ca or Twitter accounts: @timClicks. I think that those fora are generally more sociable and more resistant to spam than blog comments.