The Javascript Problem

Earlier this week Microsoft unveiled its brand new web programming language Typescript. If you don’t know what Typescript is or what features the language has, please take a look at Anders Hejlsberg’s great introductory video. Also, take a look at the Typescript ‘playground’ that Microsoft has posted if you haven’t tried the language at all; it is similar to the interactive console that Ruby has had online for a while. The big question that keeps getting asked is why yet another web development language? The ugly truth is that there is a serious problem in the web development space: a good portion of the Javascript code out there and that is currently being written is terrible.

Some people blame Javascript itself. Others feel that it is a fine language and the real issue is the developers working with it. I  agree with the second statemet to a point. I do agree that a lot of the blame for the current state of affairs can be easily laid at the feet of a large portion of the web development community, but I don’t think that helps or is productive in addressing the issue of poor code quality on the web.

The truth is your average developer knows Java or some Java-like language like C#. That means classical inheritance. It also means that most developers have been trained to think in a object oriented way and for these devs object orientation means classical inheritance. Javascript’s prototypical inheritance model is as foreign to them as functional programming. So, what ends up happening is that these developers end up trying to force what they know on Javascript and things get messy.

To be fair, we’ve tried to address some of the uglier issues in a Javascript development by developing tools designed to add some more discipline to the workflow. Still, we can’t seem to agree on if these tools are even valuable or what ones to use. Should client side Javascript be unit tested? If so, is JSUnit the tool for the job? Ask that question on a forum of web developers and watch the sparks fly. All this division does is further confuse our poor transplanted Java dev. Also, none of these tools actually do anything to change the nature of the language nor do they re-train the dev.

Ah training! Education! That’ll fix all our problems… right? Wrong. Take a look at O’Reilly or any other tech publisher’s Javascript offerings. They are publishing books on developing with the language at a furious pace. Certainly, there are more than enough texts out there for aspiring web developers to learn the intricacies of the language. Unfortunately, that is not a realistic hope and doesn’t take into consideration the vast majority of software developers: Dark Matter Developers.

Let’s assume that getting all (or even a significant number of) developers to re-educate themselves for Javascript or even that they’d be willing to do so is unrealistic. A number of tools have already come out that allow us to write our code in a  classical object oriented language and have it compile down to Javascript such Script# (C#) or the Google Web Toolkit (Java). Unfortunately, there have been a few problems with that approach; chief among them is that you often have to know Javascript to debug the generated code.

Ok, I’ve posted a lot of what we can’t or shouldn’t do here, so let’s get proactive! We can replace Javascript with an object oriented language that follows classical inheritance. Blasphemy! I know this sounds crazy but it makes sense when you consider that the size of the web is growing at an exponential pace and our clients / customers are going to expect increasingly rich and sophisticated web-based experiences as the HTML5 trend continues to grow. The need for a replacement language that is friendlier to the wider development community becomes more pronounced when you consider the fact that there are not enough of us Javascript literate developers to handle the coming / current workload.

Thoughts? Comments? Blood boiling rage? I’m happy to hear all feedback on Google+, Twitter, or

Comments are closed.