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.

 

firebugIcon

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

Source

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.

 

Banner

The Art Of Computer Programming - A Great Present
15/12/2024

If you are looking for a programmer present this holiday season, there is one book, or set of books, that should be top of any list... Donald Knuth's The Art of Computer Programming.


+ Full Story
Google Releases Gemini 2 And Jules Code Agent
18/12/2024

Google has announced an updated version of Gemini, saying that Gemini 2.0 Flash Experimental will "enable even more immersive and interactive applications", along with new coding agents that can take  [ ... ]


+ Full Story
More News

 
Last Updated ( Tuesday, 09 August 2011 )