“What programming language should I study next? What framework?” I occasionally receive emails from younger — and not so young — readers alike asking me for guidance about such matters. “Use the right tool for the job” is the correct answer, but it’s cheap advice when there are a plethora of tools seemingly right for the job. For most people these days the job at hand is of course web application development.
Should they study Ruby and Ruby on Rails? Or Python and Django? How about C# 4.0 and ASP.NET MVC? Maybe CakePHP? Java and Stripes? And how about more exotic choices like Clojure and Compojure or Scala and Lift?
With very few exceptions, in 2010, it’s hard to choose a combination of semi-popular technologies that couldn’t do the job. Does it really make a huge difference if you choose to study Ruby on Rails or Django? In all honesty, despite all the existing differences, it doesn’t really matter. As long as you become proficient with one of these tools, you will be adequately equipped to approach most web development tasks. Your experience as a server-side developer will be the bottleneck, not your framework of choice.
The real reason why I get asked these questions though, is that these people are mostly looking for a silver bullet, a language-framework combo that will magically allow them to create fantastic web applications in a matter of weeks. They are often after a shortcut, but there is no royal path to web programming.
When I think about the future of programming languages, I envision Babel not people talking Esperanto. We are destined to live in a technological world were there will be many valid server-side options, which are similar yet different enough to justify their own existence and that of their respective communities.
There won’t be a programming language to rule them all, but I believe one language will continue to be the lingua franca of the web. In that sense, it’s the most important programming language today and I think its relevance will only continue to grow in the future. I’m talking of course about JavaScript.
Today JavaScript is king when it comes to client-side web programming. It took us a while to reach this point. In the collective mind, JavaScript was considered a poor language used by amateurs to create annoying web pages. Today (thanks to AJAX amongst others factors) it’s a language that’s appreciated by many professionals and used by the vast majority of web developers. Whether you program web applications in Ruby, Python, Perl, PHP, C#, or something else, you’ll deal with JavaScript (it’s the greatest common denominator of the web development community). I know of very few professional web developers who lack a cursory knowledge of the language (or its cousin, ActionScript).
Over the past few years the browser has become the single most important application on users’ computers. This in turn, sealed JavaScript’s fate for the foreseeable future. Despite its many flaws, JavaScript is a powerful and elegant language that has advanced features which are blatantly missing from “full blown” languages like Java. Programmers have come to realize its power and usefulness within the browser. Beautiful JavaScript frameworks like jQuery, YUI, and more recently SproutCore and Cappuccino (Objective-J), showcased the art of what it’s possible to accomplish with this language. And with HTML5 becoming closer to reality, there will be an ever greater emphasis on DOM scripting and less reliance, when feasible, on RIA plugins.
If generally speaking, JavaScript is a solid and powerful language that most web developers need to know anyway, why can’t we develop in JavaScript server-side as well? And while we’re at it, maybe use it for desktop applications too? It would seem rational to capitalize on the benefits of having a huge percentage of programmers use the same language for both client and server-side programming. (If an update to the language is required to clean it up a little, let’s do that.) Why shouldn’t we be able to run js myscript.js, outside of a browser, and obtain the result of the computation in output? There is no inherent reason why JavaScript needs to be tied to the browser.
Thankfully times are changing and concrete answers to those rhetorical questions are emerging. The V8 JavaScript Engine is a project that was started by Google which provides us with a standalone shell to execute scripts and try out code in a basic REPL (Read-eval-print-loop). It’s the same engine embedded into Google Chrome, and as such, it’s a fast implementation as well.
Another great effort that’s headed in the same direction, and builds on top of V8 is Node.js, an evented I/O framework. You can think of it as Tornado, Twisted or EventMachine, simplified for server-side JavaScript. Node doesn’t require as much knowledge about event loops and non-blocking I/O, and the look and feel of such callbacks is very reminiscent of the type of AJAX code we’ve all seen before. Node can easily be used as a basic, ultra fast web server, to which one can delegate I/O callbacks for scalability and efficiency.
Recently Heroku announced beta support for Node1. It’s a risk on their part, but one worth taking in my opinion. If nothing else, at the very least, Rails developers deploying on Heroku will have the option to integrate Node to increase scalability and performance.
But Node (which embeds the V8 engine) has a lot more potential than just that. The ultimate goal is to become a self-contained solution which would allow one to develop and deploy server-side JavaScript code in production mode.
Node is just a prominent example of the impact of the CommonJS project/movement, which is aimed at making JavaScript available outside of the browser (on severs and desktops). There is in fact an ecosystem of new .js libraries that are meant to be used with server-side JavaScript (this is likely to grow over time).
What we really need is a lightweight web framework that well integrates server and client-side JavaScript. This would have game changing potential (think Rails back in 2004). Developers have grown accustomed to a high level of abstraction when it comes to web development though, so there are a couple of possibilities here: either Node will become that framework or someone will create such a framework (perhaps on top of Node). Whoever does that will hold a piece of future and a golden ticket in their hands.
[1] For a terrific demo of a Cappuccino + Node application deployed on Heroku, check out GitHub Issues.
Translations: Serbo-Croatian
Leave a Reply