JavaScript debugging tools move forward
Written by Ian Elliot   
Tuesday, 09 August 2011

Improved debuggers for JavaScript are vital but what about debugging JavaScript code that is machine generated? The solution is on its way and it is all a matter of SMAPs.


One of the consequences of the elevation of JavaScript to the central language of our time is that it now needs the tools to make it possible to use it to build serious applications. It has moved on from being a scripting language used by weekend programmers to a language for implementing multi-tier applications and games. What is less obvious is that it also functions as a browser assembly language in the sense that the JavaScript running in browsers is often machine generated. The generation mechanism varies from simple minification to being the result of compilation from other languages.

One of the problems that this causes is that while we have had reasonable debugging facilities as part of modern browsers for some time but they treat JavaScript as the language the program was written in and hence relate break points and debugging information to the JavaScript code that is running. This is fine if the code is human generated and nice and neat but trying to relate errors in say minified code to the unminified JavaScript can be difficult. The same problem with relating errors back to the compiled language - CoffeeScript say - is even more difficult.

A solution to the problem is in the use of Source Maps (SMAP) which relate each piece of generated code to the source code that produced it. Using a SMAP it is possible to report errors in the code that is running in the browser or on the server to the line in the source code that produced it so allowing the programmer a better chance of understanding the nature of the problem.



Currently only Google's Closure compiler generates SMAP files and the only tool that can make use of them is Closure Inspector a Firebug extension. Now we have news that both Mozilla and WebKit are working on projects that might result in something that supports SMAP more widely. Mozilla outlines the requirements for the project as:

  • When a sourcemap is available, error messages in console will link to the original source, not the generated JS
  • Likewise, console log output will link back to the original source
  • Patches for CoffeeScript will be used to produce examples
  • The Closure Compiler should generate compatible source maps
  • A specification for generated scripts to refer to their mappings and a mapping format
  • SpiderMonkey needs to output column in addition to source/line.
  • code that is loaded via eval() should also support sourcemaps

This move towards better tooling is welcome but it does emphasise how ill prepared JavaScript and the whole HTML5 approach is to creating apps. Yes it can be done but at what cost?

More Information

Closure Inspector

Closure Tools - Google Code

Mozilla: SMAP and debugging functionality


Thanks to InfoQ for bringing this development to a wider audience.


If you would like to be informed about new articles on I Programmer you can either follow us on Twitter or Facebook or you can subscribe to our weekly newsletter.



The Most Important Features To Include In An E-Commerce App

An e-commerce application serves a clear and simple goal. To make it successful, there are several tips to keep in mind when starting a new project. Learn what they are, and create an effective e-comm [ ... ]

Nvidia's AI Supercomputer For Medical Research And Drug Discovery

Last month Nvidia unveiled plans to build a supercomputer intended for AI research in health care. This prompts us to look at AI's potential role in health care and how it is already being used.

 [ ... ]

More News


Last Updated ( Tuesday, 09 August 2011 )