Is JavaScript ready for serious development? – Part IV

In this part of the series, I want to talk about tooling around JavaScript.

There are some established tools for Flash and Java development. For Java, there’s Eclipse & IntelliJ for IDEs, JUnit for testing, Ant/Maven for building, and JavaDoc for documentation. Similarly, for Flash, there’s Flash Builder/IntelliJ for IDEs, FlexUnit/MxUnit for testing, Ant/Maven/FlexMojos for building, and ASDoc for documentation. These tools might not be perfect but they work, they are maintained by a number of people, and there’s a community around them, so you don’t have to spend a lot of time and effort figuring out what to use for your project. There are established tools for the job.

In JavaScript, the tooling environment is messy to say the least. It’s ironic because the only way an inadequate language running inconsistently on different screens would be considered for serious development is if the tooling around the language was rock solid. I don’t think that’s the case in JavaScript.

There are some great initiatives from Google on this front with Closure Library and Closure Tools but my sense is that these tools are not perceived as standard as for example JUnit is perceived in the Java world at this point in time.

In my project, I couldn’t find a decent IDE to start with. I tried from Aptana to JSEclipse to IntelliJ JavaScript Editor and finally, I settled on IntelliJ which is somewhat decent but it’s far from Flash Builder in terms of debugging, code hinting and code templates.

For debugging, I mostly relied on browsers. I used the built-in debuggers in Chrome, Safari, Internet Explorer, and I used Firebug in Firefox. Chrome has by far the most responsive and useful debugger, so thanks to guys in the Chrome team for helping me debug a number of issues. Firebug was ok but a little slow and crashed a number of times. By far the worst debugger was Internet Explorer. The debugger had a difficult time just loading up and when the test hit a breakpoint, it would stop and refresh the whole page for 2-3 seconds. I don’t know if this is because I’m on Mac and I was running Windows 7 in VMWare but the debugger in IE was just awful. It’s great that all these browsers support some kind of debugging but I missed the consistency of Flash Builder every time I switched from one debugger to the next.

For testing, we were hoping to find something similar to JUnit in Java and FlexUnit in Flex, and after some research, we settled on Jasmine. The testing convention of Jasmine is somewhat different than JUnit but it met our needs for the most part and I do recommend it. I think Google’s Closure Library has a more JUnit like testing framework but by the time we found that, half of our tests were written in Jasmine, so we didn’t bother to switch at that point.

For JSDoc tool, there’s nothing standard for JavaScript mainly because the looseness of the language makes doc generation difficult. It looks like JSDoc-ToolKit is one of the main ones along with Yahoo’s YuiDoc but getting these tools recognize your coding style is a challenge. I think you’re better off if you stick with Google JavaScript Style Guide right from the beginning. This way you make sure JSDoc can generate docs for your JavaScript among many other benefits.

The conclusion here is that there’s some useful tooling around JavaScript but they are not mature yet and as a result no de facto standard tools have emerged. This means you need to spend some time researching into different tools and frameworks that you otherwise take granted in Java and Flash. Google’s Closure Library and Tools definitely have potential to be one of those de facto tools/frameworks and hopefully that will help to establish a solid environment for developers to build on.

3 thoughts on “Is JavaScript ready for serious development? – Part IV

  1. Try using NetBeans. It is great for Web development (JavaScript, HTML, CSS, JSP) and it is very good when it comes to Java development too. It has native support for ant, maven, svn, git, mercurial and so much more benefits. It saddens me because it is not even mentioned.

  2. True. I googled for a FlashBuilder in the JavaScript world today in the hope that I can find something useful to continue a previous line of work, and guess what. This blog is what I found in the top notch instead of a real candidate. It’s sad that people discard good technology because of immature idiosyncrasy like JavaScript on HTML5, based on the fact that it replaces modular plugins with standardization that is yet to come in the unforeseeable future.
    For disclosure, I had JavaScript experience in developing a web app (LAMP) before picking up Flash/Flex. If you have build anything with GoogleMap using Flex, and now javascript, you will understand that we are back to the dark ages (practically) with the downfall of more advance languages like Flash/AS3.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s