Ionrock Dot Org

My Weblog

The Quest for One Language

It seems that one goal of frameworks is to allow a programmer to abstract things away such that one language can be used everywhere. ORMs are the best example of this in that they translate SQL to language constructs so a programmer doesn't need to make the paradigm shift to SQL's declarative model. Templating languages are another example where often times the selling point is to use your language of choice in the template. Generally, I've thought that these sort of single language abstractions are good, but have the potential to be dangerous. Google Web Toolkit is a good example of a system that seems to go too far abstracting away an entire programming environment (javascript). 

Still, the idea that one language can be used everywhere has its benefits. For example, if there is an expensive loop for the server, pushing it to the client could be trivial in the case of a single language. Also, the simple differences in basic looping techniques can take its cognitive toll. When you're accustomed to doing list comprehensions or blocks and then need to use something like each() (in jquery), it can take a little thought. I'm not going to act as though this transition is very difficult, but simply that the changes add up over time. This is especially true when you think about something as expansive as the Python standard library vs. jQuery, Prototype and Dojo. They meet different needs for different domains, but the fact remains there is a ton of code on both sides of the fence that might be very similar in intent. 

The only pragmatic decision then in finding a single language is Javascript. Lets face it, the browsers are not going to change anytime soon. Even ActionScript is effectively a Javascript with a more traditional object oriented model. This makes things like the recently released Joyent Smart Platform appealing. The now defunt AppJet was another example of a Javascript based server side framework that aimed to make similar strides in the cloud. They even released their platform so it could be run locally. 

These platforms seem pretty compelling when you consider the current technologies available to web developers. While the browser is still a painful platform at times, JSON is everywhere. If you choose Flash or Silverlight for your frontend, you can use Javascript (more or less). Likewise, there is an obvious relationship between client and server side Javascript. Also, configuring a server wouldn't be any more difficult, as using something like nginx as a proxy is simple and convenient. The biggest gotchas I see are persistence in traditional databases, even though I'm sure the runtime a server side Javascript run on top of provides more than enough well tested persistence capabilities. 

When it gets down to it, my bet is that the hesitence to use Javascript on the server side is a marketing issue. People still don't like Javascript. I know I'm sick of it. But, when I really consider what I'm sick of, it isn't Javascript as a language, it is the browser implementation. There is a certain amount of uncertainty that is always present for me when writing Javascript. Will this attribute be there when I use another browser? Will the DOM be written to at the same time when I test this in IE? If this goes slowly, am I going to find a way to speed it up reliably? My curiousity is that when I take these issues away, does Javascript become a more enjoyable platform? I'd imagine it might. 

Hopefully I can find some time to play around with it. At the moment, I'm really happy with Python and don't see many reasons to try other options. And yes, I've used Ruby and I prefer Python thank you very much. That in mind, I find most of my day ends up in Javascript one way or another, so I bet trying it server side might be a beneficial experience.