“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
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
actually the gnome desktop project now ships with some applications written in javascript. see http://live.gnome.org/Seed.
I have to agree. Javascript has a monopoly on client-side development for browsers. So there is no room to debate if it is god or bad language to develop in. For better or worse we’re stuck with it.
Interesting but I’ll have to disagree. JavaScript has ACCIDENTALLY become the only language used to write client side code. There is no reason for other other languages not to be used to do client side logic in the future. Google is on this with the Native Client SDK. Also, most of Google WebApps client code is already written in GWT Java that is compiled to JavaScript. It is entirely conceivable that this step will at some point not be necessary anymore.
Agreed! JavaScript is already next to impossible to maintain when you talk about anything beyond an average web app with some decent client-side interaction…I think focusing on the language as it looks now is suicidal!
> And while we’re at it, maybe use it for desktop applications too?
Microsoft’s actually been there for years, with JScript and that whole HTA thing, and now with JScript.NET.
Javascript, Simply Rocks!!
I mean like every programming language (and almost human created things ;-)), it has its inherent drawbacks. But this new trends, opens a new world of posibilities for server-side development. I totally agree with you.
The only thing i really hate from Javascript is it’s name JAVA-Script???
Wtf??
Thx for this post Antonio!
Right, so if you work on a site that has 10 pages and you never have to maintain the SpaghettiScript it’s a great language, but if you really want to do something that would give you the “wtf” in 2 years when you try to add/modify something it’s the wrong language to get behind.
I’m sure you also think that Ruby is the best out there and the only other language that can compare with it is PHP, eh?
>why can’t we develop in >JavaScript server-side as well?
Serverside JScript (Microsofts ecmascript impl) was moderately popular at the start of the century as an alternative to basic. In my experience it was not a good fit for serverside programming – it was very difficult to build robust apps in part because of its dynamic nature and in part because of Microsofts poor impl.
I think of Javascript as the ‘assembler of the web’ hence a target for other possible languages.
For those who prefer type checking and the help of a compiler, the haXe language (http://www.haxe.org) targets Javascript PHP, Flash and C++. haXe is very similar to Javascript.
Via my haxe type signatures for node.js (http://github.com/blackdog66/hxnode) you can use a compiled language for your entire web stack.
@Jonas
Google does not “eat it’s own dog food” when it comes to GWT. Most of their apps are *not* written with GWT. It’s a nice framework but id rather just learn JavaScript as you’re going to have to know it anyhow when you start running into browser problems in a GWT app.
Does it really matter what programming language does certain development tasks at it’s best? I think most important is (unfortunately) what is most popular in business! The world wide job crisis gives us no freedom to chose a language we like. We are forced to chose what’s most popular to make us attractive on the job market. :-/
Very interesting overview of the current state of JavaScript beyond the browser, thanks.
@RainerHimer I don’t think this is actually true. A market is about demand and supply. I remember when I started working as a developer, just after the dot-com bubble burst, I didn’t even have a degree and I found work because I had learnt Perl while graduated people who knew Java or VB where struggling to even get an interview. From what I’ve observed, when you’re expert in emerging/confidential technologies, you just end up spending less time applying for jobs, because there are less jobs, but the result is equivalent because there are also less applicants.
In fact every programming language is same. Every language has loops, variables, functions, class etc. Just there is implementation differences. In fact we only need one simple programming language and Java is a good candidate. Crappy languages like PHP sprang out because Java was slow to reach the market. Also Flash and actionscript came out because java applets were slow, and could not gain popularity. I would recommend Java for everything, but on practice I am a PHP programmer. In the past I learned C++ but I had to develop in Object Pascal, because delphi was the best development tool in those days. Mostly you do not have the freedom to choose.
1995 – Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
🙂
http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html
You are able to write Linux Desktop applications using JavaScript via Seed and GJs.
You can also create graphical front-ends using a combination of HTML and CSS using JQuery via SeedKit rather than using traditional graphical toolkit API’s. I have created a log viewer as an example and created a wee tutorial. Links are here:
http://alsaf1.wordpress.com/2010/05/20/seedkit-tutorial-sort-of/
http://alsaf1.wordpress.com/2010/05/13/first-seedkit-program-sort-of/
http://live.gnome.org/SeedKit
I remember years ago when you tried to search for a JS reference, you would often wind up at Netscape’s reference which confusingly defaulted you to the reference for server-side scripting and not client-side.
The most important programming language is English (or whatever the native tongue is where you are). So many projects have been derailed by people not understanding the syntax of this ubiquitous language in which programmers and other stakeholders should be proficient. How many times have you heard something like, “I know that’s what the requirements said, but that’s not what I meant. Fix it.”?
I heard it one time too many, and now I no longer do programming for anyone but myself.
Why not use Java applets on the client side? There are a few interesting examples where this works wonderful, e.g.
the ‘go’ server of the popular game,
http://www.gokgs.com/applet.jsp
or an interesting thing is an online design tool (these are usually done in flash) http://designer.weebmeister.com/en/example-ultima-edition
both really uniquely extend the web-experience of the user and have a well-tested, typed oo-language below.
hmm, it’s similar to playing a video, it was done as swf since thats a reliable way of playing them before the html5 specification came and it’s still widely used.
If you look at the js team of the opera browser, it’s interesting that they’ve implemented a js to native conversion in order speed up execution time in the browser engine, same thing as the java hotspot virtual machine uses…
regards nico
I developed server side javascipt in the 90s that were run on iPlanet application server so the idea is not new.
Today a language usually imply a runtime. JavaScript has a VM. Java has its own VM. Python might start using Parrot together with Perl6, but somewhere down the line we should split up language (as a way of explaining the idea you want to achieve) with the runtim (native, parrot, .net VM, java VM, …)…
Think how great it would be if I could use a .net library and some java classes to create a python script that does something without having to port anything and if i find it too slow I can compile it to run nativly on my ARM cellphone.
Merely wanna input that you have a very nice site, I enjoy the design and style it actually stands out.
I would to learn Java so i want to know how market demand on java now a days