State of the Art?

10 Apr

As you can see, it’s been a while since I’ve posted anything about JavaScript but my world has changed dramatically in that period that I’ve been away.  For a quick glimpse of what I’m working on and what’s to come, here are the technologies and libraries that I’ve been working with more recently.

Actively using:

  • JavaScript in general (duh)
  • jQuery (for core awesome-sauce, e.g. DOM manipulation, AJAX network requests, Promises/Deferreds)
  • RequireJS (for Asynchronous Module Definition, async script loading, and dependency management)
  • Backbone.js (for MV* structuring)
  • Underscore.js (for client-side templating) — Not a huge fan, really only using it because it’s integrated with Backbone.js)
  • QUnit [and its alternate upcoming site] (for JavaScript unit testing)
  • Jetty (for an on-demand HTTP server to execute HTTP-bound JavaScript unit tests during CI)
  • JsMockito (for mocking) — I’ve heard praise that Sinon.js is better. Any feedback?
  • JSCoverage (for code coverage) — Isn’t there something better than this yet? Can someone explain how I can use NodeCover to gather the same/better metrics?
  • PhantomJS (for headless execution of unit tests during CI) — Rocks so hard!
  • JSDoc Toolkit (for documentation generation from comments)
  • Ant plus Ant Contrib (for main build) — Old, I know, but struggling to find better alternatives. Do you know of any?
  • Rhino (for running the r.js optimizer via Ant)
  • YUI Compressor (for JS and CSS minification) — Employer is understandably hesitant to switch to a minifier that rewrites our code (e.g. UglifyJS, Google Closure Compiler) on a large, existing JavaScript web app. Do you have any info/stats to help me push them past this?
  • JetBrains WebStorm (for IDE on Windows)
  • SASS (for “more awesomer” CSS)
  • IE Dev Tools, Firebug, & Chrome Dev Tools (for debugging)
  • Node.js (as potential replacement of Ant as a build tool, as potential replacement of Jetty as an on-demand HTTP server, and other experimental purposes)
  • TestSwarm (for cross-browser unit testing during CI)
    • Beautiful reporting grid output
    • Requires pre-attachment of browsers
    • Definitely alpha software, though
  • Selenium Grid (for cross-browser unit testing during CI)
    • Much more robust than TestSwarm
    • Can launch its own browsers
    • Crappy reporting output

Evaluated and didn’t see any immediate use for:

  • CoffeeScript (for “more awesomer” JavaScript?) — Seemed more like a learning curve for our large employee base of non-Rubyists/non-Pythonistas
  • Dart (laughably heavy, plus yucky old Java syntax)
  • Jasmine / Pavlov (for BDD testing)
  • JsUnit (used to use it for unit testing before QUnit)
  • JavaScriptMVC (too heavy-handed compared to Backbone)
  • Knockout (preferred Backbone)

Help me out!

Do you know of tools I should utilize for use cases not mentioned (e.g. tool to detect changes to JS/CSS and auto-refresh my browsers)?  Do you know of better alternatives for a given use case mentioned above?  If so, I’d love to hear about it!  Please leave a [constructive] comment.


36 responses to “State of the Art?

  1. geddesign

    2012-04-11 at 12:22 AM

    Looking good! I use a pretty similar set of tools. Go with whatever works for you of course, but here’s what I like:

    Handlebars for templates. Underscores templates are a bit weak sauce IMO. Handlebars templates can be precompiled as part of your RequireJS build, making them extremely fast. This plugin does that:

    r.js is going to run way faster in Node than in Rhino (about 30 times faster from what I’ve seen). Might be time to embrace you some Node. Node.js is really, really awesome. I use it for my web servers and for some project tools. My build is a simple node script that does some things and calls r.js. I’m using the default optimizer uglify.js on many large projects with no problems at all.

    For testing I’ve switched to BusterJS. It’s new and beta-ish, but has some seriously awesome features like browser capturing, support for TDD and BDD, mocks, stubs, etc. It’s written by Christian Johansen, the guy that wrote the “Test Driven JavaScript” book, also author of sinon.js.

    I use both WebStorm and SublimeText2. Like things from both. I use LiveReload for refreshing my browser on file change. I use git for version control and love it. Chrome dev tools for debugging. Semantic Grid for responsive grid layout. Normalize.css for CSS “reset”. JSHint for linter (supported by WebStorm too). I use LESS but SASS is good too.

    Fun stuff huh. Thanks for the post!

    • James M. Greene

      2012-04-11 at 11:10 PM

      I agree that Underscore is kinda weak; I’ve heard Handlebars or Mustache are nicer.

      I’m fine working with Node (or, hey, Grunt — as seen at JSConf 2012), just haven’t made any commitment to it so far. When I was initially investigating it, I had to run it via Cygwin on Windows so you can probably imagine why I wasn’t completely thrilled with it. Looks like it will now run in the Windows native command shell, though, so I’ll have to give it another look. 😉

      BusterJS looks pretty great. Silver bullets for me would be adding PhantomJS for headless execution (looks like that’s already in the works) and adding some hook to automatically launch and capture the browsers (e.g. a Selenium initializer). Any insight or tips on how other users may be bridging that gap? We’ve only recently got momentum behind converting our large suites of JsUnit tests into QUnit, so I’m hesitant to flip-flop my orders just yet for an early beta product like BusterJS.

      I love WebStorm (and also use Resharper) but I’ve heard good things about SublimeText2. Thanks for the tip on LiveReload (I knew there was something like that around, just hadn’t started using it yet). Also, we currently run JSLint/JSHint locally but not with the build as we have a large developer base with lots of existing code that they were allowed to write in varying styles. That said, I suppose we should at least run it all through the validation for TRUE errors (though it does get syntax checked by the YUI Compressor used for minification).

      Thanks for the reply!

  2. Eric Wendelin (@eriwen)

    2012-04-11 at 12:12 PM

    On the testing front, I agree with @geddesign about busterjs. It’s awesome. Regarding mocking, I like sinon.js much better because it integrates well with other testing frameworks and has fake timers and fake XHR, both of which I’ve found to be really handy. If you’re looking for integration between QUnit and PhantomJS, you can steal my adapter from stacktrace.js:

    I use Gradle for building because, hey, I wrote the Gradle JS plugin and I know Gradle very well. If you try it out, please let me know what you think.

    I also go for WebStorm over ST2 just because I use a bunch of other Jetbrains editors like IDEA and RubyMine. WebStorm can run tests from certain frameworks within the editor itself (not buster though, that I’ve figured out) and you can attach breakpoints and step through your JS (not sure if ST2 has that).

    • James M. Greene

      2012-04-11 at 11:22 PM

      I’ll have to give BusterJS a solid look, and its out-of-the-box Sinon.js integration is encouraging me as well. Your adapter doesn’t look too different from the PhantomJS stock one though I like what you’ve done with the JUnit outputFormat input argument. That said, where are you actually generating the JUnit-style test ouput? I’ve done similar things in our QUnit test runner for PhantomJS at work but I had to add an JS library of my own attached to QUnit’s lifecycle events in order to log it all properly (and performantly: rather than constantly doing console.log invocations).

      I haven’t heard of Gradle (other than from your Tweets). Does it have any particular benefits over an Ant/Maven/Node-based build system?

      Finally: yay for WebStorm!

      Thanks for the reply! And keep pondering a better API for StackTrace.js, please. 😉

      • gregturn

        2012-04-12 at 12:55 PM

        Gradle is a groovy-based build tool that is very analogous to ant. One top feature is getting away from the ugly XML coding. Things like if statements, string interpolation, and other features make writing gradle tasks smoother than ant tasks. Also, ant tasks are first class citizens in gradle, so you can easily invoke any 3rd party libary’s ant tasks from within your gradle build script. You can skim some stuff at

        • James M. Greene

          2012-04-13 at 9:14 AM

          Hmm… still looks very geared toward Java/Groovy, I guess, although I do understand it can be used as a generic build system and that Eric has written Gradle JS plugins.

          However, as I generally only use Java when doing Android development, I would probably prefer a build system like Grunt or another using Node.js to another Java-based system like Ant.

          • Eric Wendelin (@eriwen)

            2012-04-13 at 10:41 AM

            The reason I like Gradle is that it includes all of the functionality of Ant and Maven (common Java build tools) but with a lot more flexibility than maven and a lot easier to write complex tasks than Ant.

            The thing that a node.js build system would have is that you can use node modules directly from the build. You can do this with Gradle, but it’s not well integrated (yet).

            HOWEVER, there are a bunch of cool tools that are written in Ruby (like jsduck and kss) and Python and I can integrate more tightly with those in a Gradle build via JRuby and Jython. Like before, you can still run these tools with any build system that allows command-line execution (including Gradle). The thing I can do is hook into these tools at a lower level. Stay tuned 😉

      • Eric Wendelin (@eriwen)

        2012-04-13 at 10:44 AM

        Yeah, I know the stacktrace API need some love ;). I haven’t had time to really improve stacktrace.js lately because of all the extra other work I’ve been taking on. I’m hoping to be in a not insane work state sometime next month.

        If you want to fork it and experiment with the API some, that’d be huge also.

        • James M. Greene

          2012-04-13 at 3:46 PM

          I’d love to but I’ll be much in that same boat (overwhelmed with other work). 🙂

  3. justinbmeyer

    2012-04-11 at 12:36 PM

    On JavaScriptMVC being too heavy handed compared to backbone, I hope you realize that you shouldn’t be comparing it to backbone, but to almost everything on that list. It’s highly unfair to evaluate it against something that does 1/20th of what the framework provides. For a more fair comparison, check out CanJS , it’s JMVC’s MVC parts. You’ll find it slightly lighter and more powerful (live binding) than backbone.

    As for your list:

    JavaScriptMVC comes with QUnit, Phantom, Selenium, all under FuncUnit. All are setup to work out of the box much easier than setting it up yourself. And it fixes a lot of selenium’s warts.

    Oh FuncUnit also supports code coverage.

    DocumentJS is included in JavaScriptMVC as a much better replacement for JSDoc.

    Steal is a much more powerful require.js (comes with closure). It can automatically package your build across multiple web-pages for fast loading and caching. It can auto-generate a google searchable version of your page. It supports stealing LESS files. It supports CoffeeScript.

    So, instead of learning everything independently, on your own. One can simply use JavaScriptMVC where pretty much everything you have above is integrated and designed to work together.

    • James M. Greene

      2012-04-11 at 11:36 PM

      Don’t get me wrong, I think JavaScriptMVC is pretty cool all around. That said, I happened upon it when I was specifically seeking out MV* frameworks (i.e. Backbone.js, CanJS, etc.). Alas, at that point, we already had oodles of infrastructure work in place that JavaScriptMVC apparently would’ve provided out-of-the-box as well. It would’ve been a great starting point, but it seems a much less good thing when we were already in the middle of a HUGE JavaScript-intensive project. While it may have made for a better end result, we simply discovered it too late.

      When I was looking at JavaScriptMVC, I thought FuncUnit was one of the coolest things I’d heard of in a long time… so, good work on that. 🙂

      I’ll have to give DocumentJS a look, though I keep receiving suggestions now to try out Docco instead as well.

      While I agree that Steal is a much more powerful version of RequireJS, I honestly prefer the simplicity of what RequireJS provides instead. Steal seems a bit complicated and I’m not wild about the API. Plus, RequireJS provides me with an AMD loader such that I can also create modules and avoid polluting the global namespace.

      Long story short: while JavaScriptMVC didn’t work out for our timing, I think it looks like a great JS project boilerplate. Also, it makes my heart happy knowing that there are actual JavaScript consultants around (JupiterJS were the first I had heard of, several years back).

      Thanks for the reply!

  4. Ariya Hidayat

    2012-04-11 at 11:01 PM

    For code coverage, node-cover works really well. However, it does not work yet outside Node.js. I believe work is being done so that the instrumentation can be carried out in any JavaScript environment. The nice thing about this approach is because the instrumentation (on the AST) can be enriched to give more just coverage info.

    Beside Sass, there is also Less and Stylus. I guess in the near future modern browsers will support many form of this “expressive” CSS natively, which is fantastic for performance. A fallback mechanism is still needed to support browsers which are behind.

    Finally, as a self-promotion, I hereby would like to mention Esprima, the modern and fast JavaScript parser written in JavaScript. Various future tooling relies on a solid parser which understands modern constructs (strict mode, module, lexical block scope, …) and permits complicated (and in many cases, non-destructively) modification of source.

    • James M. Greene

      2012-04-11 at 11:28 PM

      I’ll be looking forward to using node-cover if at all possible. I believe I heard its use of Esprima allows for expression/statement coverage rather than just line coverage? If so, that’s pretty fantastic!

      With further regard to Esprima, I’ve been pondering applications for its awesomeness (I’ve dealt with ASTs for C# to C conversion before, very interesting stuff). That said, I’ve come up a bit dry so far but I’m perhaps not that creative in that area. 🙂 Do you think use of Esprima’s instrumentation might be able to aid in Eric’s ventures to provide better results from StackTrace.js for unhandled errors? [i.e. read: for details]

      Finally, a special thanks for PhantomJS. It’s still been the biggest leap forward in our CI test automation to date.

      Thanks for the reply!

      • Ariya Hidayat

        2012-04-13 at 12:26 AM

        Esprima permits tons of possible instrumentations, node-cover actually parses the code, modify the AST, and regenerate the code again. This is much better than line-by-line hackery. But even some basic non-destructive modification should allow function tracing already, see e.g.

        While PhantomJS is already useful as is, this is just the beginning. Its power gets multiplied as soon as it is combined with other tools, as demonstrated in the execution tracing example above.

  5. Paul Dixon (@mintbridge)

    2012-04-12 at 11:30 AM

    Grunt is a task-based command line build tool for JavaScript projects.

    • James M. Greene

      2012-04-13 at 9:17 AM

      I took a quick peek at Grunt both before and during this year’s JSConf. Looks pretty handy, though I’ve seen some complain about the API. I’ll have to take a closer look in the near future. Anything adopted by jQuery generally acts as a bonus in catching my attention pretty quickly.

      Thanks for the reply!

  6. Dave Mosher (@dmosher)

    2012-04-12 at 11:50 AM

    Good list of tools, it’s always interesting to see what other people are using for front-end dev. I’d add Docco ( to the list as well, it’s supremely useful for generating library/framework documentation 🙂

    One thing I disagree on is the classification of tests as you put here: “Jetty (for an on-demand HTTP server to execute HTTP-bound JavaScript unit tests during CI)”. I’d argue that if a test is HTTP-bound then it’s not a unit test.

    From Michael Feathers article entitled “A Set of Unit Testing Rules” (

    A test is not a unit test if:

    It talks to the database
    It communicates across the network
    It touches the file system
    It can’t run at the same time as any of your other unit tests
    You have to do special things to your environment (such as editing config files) to run it.

    Another great post on this is Types of Tests by @searls (

    As for mocking, I’ve found that the built in spying capabilities in Jasmine offer all the mocking capability I need without having to use an external mocking lib. I also write all my unit-tests in Jasmine so it’s a good fit in that regard.

    • James M. Greene

      2012-04-13 at 11:01 AM

      I think Docco is great for showing annotated code (more like for open source development projects) but showing the whole code library is much too verbose for a framework/library API-level documentation effort. For example, most consumers of jQuery would NOT want to be drilling through their annotated codebase to try to find API usage documentation.

      Oh, and I do agree with your distinction of HTTP-bound tests not being qualified as “unit tests”. That said, devs on my LARGE project team (200+ devs) still write them with a JavaScript “unit testing” framework (e.g. QUnit) and put them into the unit test codebase, so I fudged the fine print there.

  7. Domenic Denicola

    2012-04-12 at 11:51 AM

    Some thoughts:

    * QUnit is looking pretty dated these days. Jasmine is much nicer, but I think Mocha is the new king. QUnit just has architectural issues that make it very hard to work with (e.g. requiring custom integration with QUnit.push and the QUnit lifecycle events). Plus of course the whole module/test/asyncTest + flat global assertion functions setup makes your tests into spaghetti compared to a nice BDD setup, but that is admittedly a taste thing.
    * I haven’t used JsMockito, but +1 for Sinon.JS as an awesome fake framework.
    * +1 for NodeCover. I love it.
    * Most people seem to be using Jake instead of Ant?
    * Use Node.js; Rhino is crazy-sauce.
    * Everyone uses UglifyJS these days. I would definitely ditch the dated YUI Compressor.
    * I’d put the Q promise library there [1]. See [2] for why you should be using promises.


    • James M. Greene

      2012-04-13 at 3:43 PM

      Thanks for the recommendation to Mocha. I’m liking what I’m seeing from both Mocha and BusterJS as even better options than QUnit (though I don’t have any real issues with QUnit other than its lack of proper nested suites). I generally prefer XUnit style over BDD but, as you said, that is a preference.

      Promises are also great, we use some of jQuery’s promises and deferreds. Q’s setup doesn’t look especially better than jQuery’s, but Q would be a handy library to pull in if we weren’t already using jQuery. …or did I miss something that is especially better about Q?

      Thanks for the reply!

      • Domenic Denicola

        2012-04-15 at 5:30 PM

        The biggest advantage of Q over jQuery promises is that Q promises are chainable by default, without the `$.pipe` usage. jQuery’s broken implementation here leads to bugs like [1] in libraries that try to use promises interoperably.

        jQuery promises also break the return value fulfillment value and thrown error rejection reason correspondence, since jQuery promises can be fulfilled with more than one value or rejected with more than one reason.

        Finally, jQuery promises do not guarantee resolution in the next turn of the event loop; see slides 57 through 61 of my deck for the problems this can cause.

        These are just my personal pet peeves (in order of importance). But you’ve clearly seen the comparison-with-jQuery documentation for Q, so you should be fine, as long as you’re aware of the differences 🙂


        • James M. Greene

          2012-04-16 at 3:56 PM

          That’s great information to differentiate jQuery’s Promises from Q’s. Thanks!

  8. mykesx

    2012-04-12 at 1:30 PM

    • James M. Greene

      2012-04-13 at 4:18 PM

      Care to tell us:

      • What you use it for?
      • What you use it as alternative to?
      • Generally, more about it?
  9. Jake Verbaten (@Raynos2)

    2012-04-12 at 6:01 PM

    Half of the tools your using are sub optimum. Some of the tools you are using are awesome sauce.

    • James M. Greene

      2012-04-13 at 2:11 PM

      You write very harsh critiques. 🙂

      Feel the love:

      Some of your points seem to be agreeing with me (e.g. your disdain for Underscore) yet you spin them as if I was screaming their praises from the rooftops. 🙂

      I also dislike that you have an artificial/predicted quote from me in there about not having a unit test suite as a reason to not use UglifyJS. We have many tests, of course, but not 100% coverage. As a side note, the tests don’t normally run against our minified JS — although now that you mention, I suppose they really should!

      All that aside, some of your thoughts are valid and well-taken, others just seem very opinionated such as your apparent slant to CommonJS over AMD. One of the niceties of RequireJS is that it even though it is intended for AMD, it also supports CommonJS. Personally, I find CommonJS to be very sub-optimal for the browser, though perhaps better suited for server-side usage as with Node.js.

      Thanks for the recommendation to Mocha. I’m liking what I’m seeing from both Mocha and BusterJS as even better options than QUnit (though I don’t have any real issues with QUnit other than its lack of proper nested suites). I generally prefer XUnit style over BDD but that is also preference.

      Thanks for the reply!

      • Domenic Denicola

        2012-04-13 at 2:14 PM

        Don’t worry about Raynos, he is the pinnacle of not-invented here.

        • Eric Wendelin (@eriwen)

          2012-04-13 at 5:09 PM

          +1 to this comment. But FWIW I found the gist hilarious so it’s still worth a read.

  10. akismet-62453a54b90f6c5a0959300a95c4ab70

    2012-04-12 at 10:46 PM

    For templating have you looked at dustjs – linkedin seems to be a big fan Great summary of tools.

    • James M. Greene

      2012-04-13 at 4:13 PM

      Dear Mr. Anonymous DublinSoft: (a.k.a. “Gavin” 🙂 )
      I have not looked at Dust but I am sad to see that it is not yet been incorporated into this JSPerf comparison of templating performance results:

      I went ahead and dropped an issue on the DustJS GitHub for this:

      Though, notably, it seems that LinkedIn are being bad citizens: they’ve made their own fork of DustJS without any suggestion of a plan to contribute back to its mainline (as their repo doesn’t even have a real GitHub fork relationship with the original upstream repo):

      Thanks for the reply!

  11. huntchr

    2012-04-13 at 12:49 AM

    I’m the main committer for so I’m going to be biased, but I’m obviously using Maven for my builds, managing dependencies, testing deployments and many other things. I leverage Jetty/QUnit/Phantom.js with my project.

    In terms of the toolkits I use presently:

    * jQuery
    * Bootstrap
    * Knockout.js
    * d3.js
    * Almond.js

    These more than satisfy my needs in developing large scale quality driven applications for desktop and mobile.

    One thing about the above that I find satisfying is that the toolkits are focused in their scope and are not trying to be all things to all people. For example, Knockout is *just* a data binding toolkit. I consequently find it easy to mix and match other toolkits on this basis.

    • James M. Greene

      2012-04-13 at 5:20 PM

      Is there a good compact page/document where I can see all the JavaScript-related capabilities of your JavaScript Maven Tools (e.g. minify, run tests, concat, lint, etc.)? I wasn’t finding one offhand.

      I also like finding libraries/toolkits with a distinct focus, probably another reason I ended up avoiding JavaScriptMVC. I love Bootstrap for CSS but I’ve never actually used the JavaScript part of it… may have to give it a go sometime. Almond is also a great shiv to slim down RequireJS for production. I have no current use for D3, and we chose to avoid Knockout’s MVVM (although I find it pretty cool, I hate having data bindings in the markup; and yes, I know there are alternative patterns) in favor of the more MVC/MVT style of Backbone.

      Thanks for the reply!

  12. Afonso França

    2012-10-02 at 5:46 PM

    for automated code coverage I created a grunt step that uses phantomjs + qunit + jscoverage to do this.
    The project is in the beginning and I need help to improve it. But it is completely usable.
    I’m still writting the readme, but if you have doubts please ask me.

%d bloggers like this: