A blast from the past!
This is similar in design to version 1 of Source Maps, which I prototyped
at Google in 2009. You can still see the original "parsing" code here:
We moved away from doing so not only because of file size concerns, but
performance as well. At the time, pulling the entire JSON object at load
time into memory was less efficient than having a string, even if we had to
parse the string to find column positions. We actually had separate JSON
objects on each textual line as a way to partly alleviate the "load entire
I imagine that these concerns are somewhat still valid for extremely large
maps, but far less so today where JSON parsers are far more optimized. It
might be worth adding some benchmarks of parsing the JSON-only format vs
the current version 3 format.
On Sat, Aug 15, 2015 at 2:28 PM, wrote:
> I've worked with source maps for a few years now. I've contributed to
> several compilers and worked with source map issues on them, such as
> [reworkcss/css], [postcss] and [CoffeeScript]. I've also contributed to
> I've thought a long time about proposing an alternate, human readable
> format to complement today's (version 3) format. You can read all about it
> The above link also contains real-world testing and practical examples of
> the proposed format.
> I'd love to hear somebody else's opinions, thoughts and feelings on this!
> [reworkcss/css]: https://github.com/reworkcss/css/
> [postcss]: https://github.com/postcss/postcss/
> [CoffeeScript]: http://coffeescript.org/
> [mozilla/source-map]: https://github.com/mozilla/source-map/
> dev-js-sourcemap mailing list