Category Archives: Process

JavaScript: Noteworthy Tools & Libraries

Last Updated: 2013-03-19

I am the co-organizer of the Twin Cities JavaScript users group known as JavaScriptMN.  At one of our recent meetups (2012-05-31), we were set to have 30 minutes of discussion and/or lightning talks on the theme of “tools and libraries that you couldn’t live without”.  While the goal of the theme was to point out the most valuable tools and libraries available, our main speaker for the night was missing in action and so we continued discussing tools and libraries for the entire duration of the meetup.  I’ve put all the suggestions together into a composite list and categorized them all, though the order of the categories themselves is definitely a bit askew.

Please note that this is not intended to be a list of the best tools/libraries in each category but rather providing a small set of those available.  The reason behind this is that many of them are still actively in development (the coverage tools are a good example), and so I don’t want to only list the single option that I feel is best at this point in time as it may be eclipsed by one of its listed competitors (or something totally new!) in the near future.

My intent is to keep this blog post up-to-date as time marches on, so be sure to keep a link to it handy (or just to my main blog page, as I’ve made this post “sticky” as well).  Now, on to the list!

Read the rest of this entry »


The Node.js Revolution, or: How I Learned to Stop Worrying and Love the Node

Hello, Node!

As a self-admitted JavaScript lover, I was neither surprised nor disgusted (as some JS “haters” were) when I first heard about Node.js bringing server-side JavaScript to the masses!  Running on top of Google Chrome’s V8 JavaScript engine clearly gave it an advantage not shared by its predecessors like Microsoft’s JScript (atop the Windows Script Host) and Mozilla’s Rhino.

That said, I investigated Node.js early in its life and the stability I was seeking from it in order to utilize it for enterprise-level production-ready server-side JavaScript (for a purpose very similar to the one outlined by David Padbury on his blog) was simply not there yet, especially on the Windows platform.

And so I shelved looking at Node for about 9 months.

Nine Months Later…

Perhaps Node.js was pregnant unbeknownst to me when I left her… because when I returned to my abandoned fling 9 months later, I found that she had given birth to a great many new and wonderful things!  Weird analogies aside, what I hadn’t noticed happening due to my absence from the scene was that many strong JavaScript developers in the community had rallied around Node.js.  Eager for a reprieve from the web-based world where JavaScript was bound by browser incompatibilities and inconsistencies, they happily brought their skills and ideas to the beautifully browserless world of Node.js and began to form an incredibly rich and thriving ecosystem around it.

While existing tools like PhantomJS and Esprima became even more useful than before, many new tools — Mocha, BusterJS, node-cover, and coveraje, to name just a few — came into existence to improve upon existing but stale tools (e.g. JsUnit/QUnit/Jasmine, JSCoverage).  More recently, Grunt, a promising new build tool for front-end projects was released, again built atop Node.js.

Also, having a completely server-side environment also drove home the importance of JavaScript’s lack for modules, and so CommonJS and Asynchonous Module Definition (AMD) were both solidified as a result.

What Does It All Mean?

The Good:

  • I think the new libraries and tools created as a result of the Node.js revolution are amazingly useful — but better yet, even though most of them were created for use with Node.js, they still apply (or have been retrofitted to apply) to the traditional browser-bound world of JavaScript as well.
  • Having CommonJS and AMD for module specs is great!  In fact, I actually prefer AMD over ECMAScript Harmony’s proposal for native module support.
  • Node.js has rallied the JavaScript community to band together again as professionals doing cool stuff as a collective group.

The Bad (or Regrettable):

  • Unfortunately, it seems that many of the JavaScript world’s best and brightest have almost completely abandoned the frustrating traditional browser-bound world of JavaScript in favor of the unshackled browserless world of Node.js.  While this is good for them as individuals and for the Node.js community, I can’t help feeling that it is also a loss for those of us still fighting the never-ending battle with client-side JavaScript in a world of incompatible, inconsistent browsers.  That said, again, we have still seen some residual benefits in the form of new libraries and tools that apply to both worlds.

So what do you think about the Node.js Revolution?


State of the Art?

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.


Aspirations of true agile practices in JavaScript development

My team regularly develops JavaScript for our piece of the application, but has struggled until recently to get decent test coverage of our JS code.  In an effort to see what the ideal state of such things could be, I’ve setup a website on my local IIS 7 instance with the following set of tools that I believe would satisfy the needs of doing real TDD/agile practices with JavaScript development: JSUnit, JSMock, JSCoverage, and the JSDoc Toolkit.  We’ll see how it goes!

Note that for JSUnit, the download links are sadly out of date.  You must drill into the SourceForge trunk of the codebase in order to get a remotely recent version.

Comments Off on Aspirations of true agile practices in JavaScript development

Posted by on 2009-09-11 in Coverage, Documentation, JavaScript, Process, Testing