Reflections on NationJS, Part 2, the Afternoon Sessions


… continuing my previous post on NationJS.

At lunch, the conference attendees broke up into small groups that ate at various nearby eateries. I elected to have a FuddRuckers burger with a side of conversation about AMD.

Interactive Data Visualization with Backbone and D3 by MIchael Tierney

Michael’s talk was a case study about creating reusable charting components using D3 on top of Backbone’s models. I had hoped to see more intimate details about how he hooked Backbone’s eventing into D3, but the talk stayed at a high general level rather than down at the weeds. He strongly recommended using Marionette, but didn’t give a good reason as to why. While he’d examined some D3-based component libraries such as nvd3 (which I’ve used a little) and Mike Bostock’s examples page, he found much of the code to be too heavily biased with assumptions from the particular problem each component was solving. In order to generalize charting components, Michael’s main task was to extract a common set of generic charting parameters to form the basis of his component library.

I wanted to ask him after the talk whether he’d thought about open-sourcing that set of parameters but didn’t get the chance. In thinking more about this approach afterwards, it seems to me that writing a Common Charting Specification would be a good idea. Michael came up with an internal specification and wrote brand new charting components to use that specification. One could probably get a little more bang for the buck by writing adapters from the common specification to already existing components.

SpiderMonkey Parser API: A Standard for Structured JS Representations by Michael Ficarra

Mozilla open-sourced their JavaScript abstract syntax tree (AST) API as the SpiderMonkey API a while back. Since then, a large number of open source projects have sprung up around the API, despite some quirks/bugs. Michael pointed out some of the major quirks and then described the projects in the SpiderMonkey ecosystem.

  • reflect.js — this was the first project to make use of SpiderMonkey. It is now superseded by esprima, which has the same API but better.
  • esprima — ecmascript parser.
  • escodegen — a popular tool to regenerate JavaScript code from AST. It is one of several projects by Constellation. Guarantees roundtrip fidelity and is compatible with sourcemaps.
  • esfuzz — Michael’s project to generate random JavaScript. This is used to create roundtrip fidelity tests.
  • esmangle — a minifier/mangler like uglify js, but works on tree transformations rather than JavaScript source code. Also generates simplified source (but not simplified AST). Another project from Constellation.
  • escope — a scope analysis tool by Constellation. There are a number of tools derived from this such as esmangle, eslevels, and estoggles
  • esgraph – a tool to map the flow of JavaScript programs to a graphviz diagram.
  • half-and-half — partial evaluator for JavaScript.
  • metajs — metacircular interpreter visualizer
  • eslevels— using escope to highlight identifiers based on distance. I wonder if this tool was inspired by Douglass Crockford’s 2012 YUI conference talk in which he wishes for a JavaScript IDE which colors based on scope rather than syntax?
  • brushtail — tail recursive optimization, written by Brian McKenna, another speaker at the NationJS conference.
  • esquery — selector for AST, using a CSS selector style syntax.
  • eslint – linter based off of SpiderMonkey. Still at an alpha stage of development as of this post.
  • sweet.js — adds macros to JavaScript.
  • commonjs everywhere — browser bundler with sourcemaps

There are a number of notable exceptions which don’t belong to the SpiderMonkey ecosystem — uglify.js and typescript. For me, this talk was very useful, as I’d wanted to work with JS parsers but couldn’t figure out which to use because there were so many choices.

Express on Rails by Kyle Hill

I didn’t actually go to this one but the slides seemed interesting — especially the point about how Rails is opinionated while express sets no conditions on code file organization at all.

Testing the Night Away by Chris Moultrie

This is another talk that I heard was good. Guess I’ll review the slides.

jQuery is Not the Answer by Ed Kim

Using a list reordering as an example, Ed worked through some arguments about jQuery. For me, the two takeaways from this talk were

  • jQuery isn’t a framework, so when your code quickly goes beyond a certain point, jQuery becomes ugly or unmaintainable, and you’ll want to use some kind of MV* framework.
  • Naive use of jQuery results in lots of slow DOM manipulations.

That’s it. Looking forward to next year!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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