Why it Doesn’t Matter that Javascript Sucks 1
Alexei Boronine wrote a piece criticizing Javascript last week that received some play in social media circles. Alexei’s compellingly entertaining rant focuses on core weaknesses of the javascript platform, specifically:
- No OOP. I am not familiar with any other way to structure imperative programs. Yes, JavaScript has a rudimentary object model, but literally no one knew how it actually worked.
- No standard library. Copying functions from forums and pasting them into your code. Not fun.
- No module system. Constant scouting for download links and ridiculously long source files.
- No language resources. No high-quality resources (and hardly a single decent book) meant your best reference was misguided blog posts and newbie forum questions.
Alexei is completely correct, and for years this was the reason I avoided Javascript like the plague, resorting mostly to the Java based GWT to ease the pain. By letting you code in Java, GWT solves every one of Alexei’s problems, with varying degrees of success. It even throws on a few other bonuses like code completion in Eclipse and auto-generated cloud apps using Google’s plugins. Unfortunately none of that matters when it comes down to one overriding fact.
Despite years of effort by Google and apparently declining interest in javascript, there remains over an order of magnitude more people working on and with Javascript than with GWT. And there are more people working with GWT, than working with any of the other alternatives that Alexei lists.
The Libraries
Alexei mentions that people started good libraries for Javascript, but it would be more accurate and proportional if he mentioned that HOLY CRAP PEOPLE STARTING WRITING INHUMAN LOADS OF GOOD LIBRARIES. jQuery for example is 84 times as popular as Coffeescript, the most popular tool that he references.
A google search for “Javascript Library” produces 70,600,000 results.
Javascript Compatibility is the Only Feature that Matters
This is probably the most important point if you are currently looking into a new technology for a major project or focus for your development team. The extant library ecosystem for javascript is probably hundreds of times larger than its nearest competitor, so no matter how well designed, architected, or intentioned a client side scripting engine is, if it can’t interop with Javascript, then you won’t be able to get real-world projects done with it as fast as you could with Javascript.
In the current ecosystem of tools and languages attempting to solver Javascript’s problems (and mentioned by Alexei) there are only two that do this well enough not to slow you down, Coffeescript and Typescript. Of the two, Typescript seems superior in that it solves some tooling difficulties that afflect Coffescript. I haven’t done major development in Typescript but I am tempted to. Typescript primarily adds objects and static typing to Javascript, and a tool that automatically compiles Typescript into Javascript. It can call Javascript directly using Javascript native syntax, which means that the author-provided examples on how to use those blessed Javascript libraries will still work. But you can also add typing to let the compiler keep track of the bits it can for you more easily. There is a big downside though – you can’t debug the code you wrote. When you pull up Firebug to debug your Typescript app’s strange behavior, you will see the generated Javascript, not the Typescript. This by extension means you will have a harder type debugging in Typescript, but hopefully not as many bugs to debug thanks to static typing. Whether this is worth it is left as an exercise to the reader.
So there’s my argument. The overwhelming number and quality of Javascript libraries make the underlying language quirks irrelevant. For the foreseeable future, the only possibly helpful tool or bridge language that I see is Typescript, and even that’s a maybe. Good Coding!
