May 11, 2015
I gave a talk at NebraskaJS about my journey with source maps:
Video
Demos
The source is available on GitHub.
Slides
We’ve complected things with tools
You probably don’t deploy your JavaScript or CSS to production in the same format as you write it. Or rather, you probably shouldn’t. Maybe you’re concatenating files, or minifying the assets, or even compiling from another language like Sass …
May 11, 2015
I gave a talk at NebraskaJS about my journey with source maps:
Video
Demos
The source is available on GitHub.
Slides
We’ve complected things with tools
You probably don’t deploy your JavaScript or CSS to production in the same format as you write it. Or rather, you probably shouldn’t. Maybe you’re concatenating files, or minifying the assets, or even compiling from another language like Sass or CoffeeScript. Tools like Rails’ Asset Pipeline do this automatically.
But! Debugging concatenated, minified code is a huge pain. Prior to Source Maps, the best tool available was Chrome’s Pretty Print. But it’s only a partial solution, as it doesn’t restore variable names, show code transformations, etc. It’s a slog working through the generated code and try to figure out what’s going on.
The solution? More tools!
I’d heard of Source Maps a few years ago. At the time, it was being touted as the solution to the tooling problem we created. Way back in 2012, Ryan Seddon published an article outlining all the cool stuff you could do with the technology. But it didn’t seem to catch on; I hardly ever noticed a site with source maps enabled.
So what gives? From my perspective, the problem wasn’t with individual tools, it was with the toolchain. If any step in your app’s asset pipeline didn’t properly support source maps, everything fell apart. So while you may have source maps configured for Sass, if you then ran it against Autoprefixer, you’re at the mercy of Autoprefixer’s support.
And the more complicated your asset pipeline, the more likely one link was going to fail. Supporting Source Maps right is hard. Check out the release notes for Grunt’s uglify plugin. Nearly every release in 2013 and 2014 was fixing or enhancing something with source maps.
An end to the teething years
But I think we’re at a turning point. For my Node-based toolchain, source maps are finally working across the board.
- Concatenate? Added less than a year ago.
- Uglify? Took a complete rewrite to support.
- Sass? Just got consistently working maps in node-sass last week.
Some of this credit has got to go to Nick Fitzgerald and the excellent work Mozilla has done on the source-map library, which provides the bulk of the code folks need to enable source maps without having to dive deep into the spec. It works great, has a simple and flexible API, and over 200 npm modules depend on it.
It works for The Terminator
The source-map library works so well, I took it and implemented a new language that compiles to JavaScript, with full source map support. Granted, the language is ArnoldC and quite possibly the dumbest project ever conceived, but it works, damnit! And I never once had to open the Source Maps specification to learn its mysterious secrets.
(ArnoldC should probably be detailed in its own post, this has gotten way too long.)
So if you’ve been waiting to investigate Source Maps, now might be a great time to start. You have nothing to lose but your one-character named minified functions.