Hardly had I begun to play with
Node.js when a friend pointed me to
this news item about JavaScript being used
to run Linux.
Déjà vu all over again.
Some months ago, after the perceptible pall that descended on Java with the Oracle takeover of Sun, a group of tech enthusiast friends of mine opined that the time was ripe for a new technology. Java was now legacy. It would continue to grow and influence, of course, but its glory days were over. Java had been a shooting star under Sun. Under Oracle, it was now a cash cow. The next paradigm shift would therefore have to come from a new technology altogether. Much as we might pride ourselves as technology futurists, we only struggled to pierce the veil. We spoke about Android, cloud computing, NVIDIA processors and Web 3.0, but none of us imagined that the revolution would come from an established and very familiar technology.
JavaScript is as old as the web, and born close on the heels of Java, which explains its confusingly similar name. (Well-meaning managers at leading technology companies were known to discourage programmers from writing JavaScript because they heard that the corporate firewalls were configured to block Java applets. Microsoft evangelist Stephen Jeffries even ruined a perfectly credible sales pitch for Microsoft technology in 1999 by claiming to have written "some Java scripts", which were inferior to his company's offerings, of course.)
Naming confusion aside, not many will remember that in the early days of the web (circa 1995), Netscape not only had a browser (the legendary Navigator), but also a web server, a directory server, a certificate server and many other components of a web-based ecosystem. JavaScript was a Netscape invention, and the Netscape web server could run Java servlets as well as JavaScript code. There was an attribute that could be used with the "script" tag in HTML, which was "runAt = 'server' ". JavaScript running on the server - imagine that!
But that initial innovation died out shortly after. JavaScript became a purely client-side phenomenon. Other languages, notably Java and PHP (and ASP in the Microsoft world) took over the server side.
The next time I heard of JavaScript running on the server side, it was in the context of WSO2's highly innovative
Mashup Server.
Server-side JavaScript was still a rare phenomenon, and had the faint aroma of a toy system to boot. After all, serious software was written in Java. JavaScript was at best useful to demonstrate clever ideas. It wasn't production strength.
Now along comes Node.js with its innovative thesis about how to do I/O right. Ryan Dahl
explains the philosophy in a way that appears obvious in hindsight. When you see the numbers he puts up comparing the CPU cycles for different levels of I/O, it becomes extremely clear that it's criminally wasteful of computing resources to wait on disk and network I/O.
L1 cache: 3 cycles
L2 cache: 14 cycles
RAM: 250 cycles
Disk: 41,000,000 cycles
Network: 240,000,000 cycles
Node.js boasts a single event loop which, combined with its absolute
refusal to block on any external I/O operation, allows it to scale up to ridiculous levels of concurrency. Add to that the simplicity, flexibility and familiarity of the JavaScript language, and the runaway popularity of Node.js becomes understandable. I'm personally blown away.
Even Ryan Dahl, its inventor, struggles to explain what Node.js
is (beyond the obvious fact that it's a bunch of libraries on top of Google's V8 JavaScript virtual machine). That's because Node.js is nothing less than a new platform for innovation. It's clay in the hands of a new generation of developers, and fascinating new products (Node.js modules and frameworks) are emerging.
I think one of these will be a rich GUI library to rival the offerings from Adobe. It will be possible to build extremely flexible and lightweight client apps with rich user interfaces very soon. Web forms will soon seem clunky, because we can soon have web applications without web forms.
Another phenomenon that Node.js will enable is peer-to-peer systems. I believe we've outgrown the synchronous request-response behaviour of the traditional web. Something new and big is coming soon.
So move over, Java. Here comes JavaScript.
A Broker is used to connect to legacy business logic through mediation, routing or transformation.
A Process Engine is used to coordinate two or more services into a process and expose that as a composite service.
We put these together in different combinations to build out the specific business processes we need. Needless to say, what we run on these components should be reusable, so their interfaces need to be generic, yet extensible. Good data design is required for this.
