Javascript is eating the world

Javascript has since the 90s been confined to the web-frontend. Frontend developers have since then enjoyed building dynamic web-apps that interacts with the user, asynchronously handles data and controls the browser in a nice, fast and loosely typed way. All the way until 2009 Javascript was confined to the client-side scripts.

But then things started to change. In 2009 Ryan Dahl presented Node.js.

Node.js logo This allowed Javascript to be used as a server-side language, what Ruby-on-Rails had been doing so well. But Node.js is both faster and allows frontend developers to develop server-side applications as well! As a newcomer to Node.js I really enjoy the sufficiently low granularity control you get with Node, which (at least for me) enables a clearer understanding of what's going on. Even though it may at take me a bit longer to get there compared to using Rails.

In 2013 a company called Technical Machine released the Tessel.

The Tessel is a Raspberry Pi like device but which can be programmed by Javascript and can even take advantage of the many modules already avaiable using the Node Package Manager (npm). Now frontend webdevelopers from the 90s can suddenly build hardware devices.

So what does this mean?

The Internet-of-Things is said to generate 14.4 trillion USD over the next 10 years. And now we have one programming language that can be used to program all parts of an Internet-of-Things application (except for a bit of HTML and CSS). Now being a Javascript developer is truly full-stack.

As someone with a classical embedded systems (what Internet-of-Things devices used to be called) engineering degree behind me I'm used to thinking about hardware and software in completely different terms. If I write a software application that is supposed to run on a laptop I'm fully aware that I'm not really constrained by a lot of things. There's plenty of computing power and I don't really need to care that much about battery life unless my application is really supposed to be used when the user is on the go.

But if I'm writing software that is supposed to run on a device that is battery powered and for that reason has a slower processor, the effectiveness of my code suddenly becomes a big factor. Now if that device also has actuators I need to be very careful about my battery budget and I probably need to write driver for driving the actuator.

But today, battery power and computing power will continue to scale so to write code for Internet-of-Things devices will not be as important as it once was. There's simply more resources available now compared to then so writing effective code for many Internet-of-Things applications may not be as necessary as it once was. And let's face it the Tessel comes with 14 different general purpose actuators out of the box for which I don't need to write my own driver.

NASAs Mars Exploration Rover vs. The Tessel

Let's compare NASAs famed Mars Exploration Rover mission from 2003 to a Tessel.

The rover brain was a RAD6000

It features a 20MHz PowerPC based processor with 128MB DRAM burning between 5-20W depending on what it is doing. It is radiation hardened obviously (since it needs to go to space) and weighs 1Kg.

The Tessel on the other hand sports a 180MHz ARM Cortex M3-based processor featuring 32MB SD RAM, it has WIFI and definitely does not weigh 1Kg. Pound for pound the Tessel is kicking the RAD6000s ass. (But I'm actually a little suprised to see the Tessel not kicking the RAD6000s ass even more).

The Raspberry Pi is even more powerful as it comes in with a 700MHz ARM core sporting upto 512MB RAM.

The need for speed and power

So is there still a need to write effective code?

Probably yes. Yes the technologies are scaling in our favour which allows us to get more performance pr. line of code. But we also want to do more and more stuff.

The question is then if Javascript has got what it takes. Is Javascript code really that effective when writing code for embedded devices?

Compared to writing embedded software in e.g. C - you can't do very low level ressource management even though Node gives you much lower level access than say, Rails.

We'll see where this goes. My Tessel is waiting at the post office :)

Michael Reibel Boesen

comments powered by Disqus