Friday, January 27, 2012

Why we should care about server side JavaScript

A software practitioner recently asked me what are the benefits of a functional language, and why would one want to use, say, JavaScript for an MVC Web application stack. A stack to consider would be Ruby on Rails for instance. Clearly, developers in the Node.js community have their eyes set on that problem space.

I wasn't prepared answer his question, at least not adequately.

JavaScript certainly offers interesting things like closures and anonymous functions, which make event-driven programming interesting.  Closures, my friend pointed out, are like deep class hierarchies in an OO system, and can obscure the flow of control. It is true that closures come at a cost, but there are benefits as well in the reduction of code and less time spent in allocating temporary variables and in avoidance of copying. But closures are just one construct among several primitives in functional programming that work together to form an extensible system of logic. A grammar, if you will.

Why should we care?

Improved engines, especially Google's V8, have brought speed characteristics to rival that of C++. If JavaScript were still as slow and memory intensive as, say, Java, it might have survived in the browser space. Yet V8 brings JavaScript benchmarks into the same order of magnitude as statically compiled languages. It still isn't as fast as C or Perl5, but it is on-par with PHP and C++ and edges out Ruby (sorry Ruby, I do love you, but you're not quite as fast as V8). That is one characteristic that has some Web app developers all hot and bothered about Node.js.

And for whatever faults it has, JavaScript has less cruft than PHP, C++, or Java. Functional primitives combined with a kind of Lamarkian inheritance and minimal data types make it a very cohesive language despite its half-baked flaws. It doesn't have classes, but then again, it doesn't have classes. JavaScript does have prototypal inheritance. Modules and packages have much more practical benefit, and you can make those in JavaScript.  With cleaned up syntaxes such as that offered by CoffeeScript, some of the worst flaws can be entirely elided from the coding experience while making programs even shorter.

As a language, JavaScript leaves some things to be desired. The lack of tail-call optimization, while generally treated as YAGNI, prohibits some interesting implementation techniques. The widely used long-running script detection makes sense for browsers and servers, but for background processing tasks and monitoring not so much. There are some interesting ways of managing blocks of code, formulating methods, and handling control flow in Ruby and Python that I sometimes wish were in JavaScript.  The weirdness of falsiness and truthiness and == is eye-rollingly campy.

But in spite of its flaws, JavaScript is still a much saner language than Java and unlike Java/Ruby/Python/C++/Perl/PHP/whatever, it is part of almost every Web browser. Node opened up the path to a coding experience in which the seams between deployment environments are much cleaner and tighter, allowing them to be increasingly well-defined, well-factored, well-integrated, and well-tested with less code.

As a spiritual descendant of Scheme it is difficult to stay mad at JavaScript for very long even when the browser environment makes simple tasks grueling; eventually the elegance and simplicity of the language still draws you in.

Approachable beauty intrinsically engenders creativity and productivity. That in a nutshell, in my very humble and only poorly-informed opinion, is why programmers are noticing JavaScript.



Post a Comment