John Resig on TraceMonkey and the future of JavaScript-based RIAs

Posted by Dionysios G. Synodinos on Sep 01, 2008

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

.NET ,

Ruby ,

Web 2.0 ,

Javascript ,

Java ,

Rich Internet Apps

Tags

Firefox ,

Web 2.0 ,

Browsers

The newly announced TraceMonkey is a trace-based JIT compiler that will be featured in the next release of Firefox and pushes the envelope on JavaScript performance. InfoQ has a Q&A with Mozilla JavaScript Evangelist and jQuery  creator John Resig about this exiting development and what it signifies for the future of JavaScript-based RIAs.

InfoQ: How do you think this development will affect RIAs? Do you think that it will open the road to even richer applications? What would those look like?

Without a question, absolutely. There is a whole realm of applications that are very difficult to implement, right now, in the JavaScript realm: Those that are computationally intensive. Trying to implement any sort of complicated game or graphics simulation becomes incredibly challenging. With Tracemonkey (and other ECMAScript engine performance improvements) coming in to place these challenges now enter the realm of possibility - which is quite exciting.

InfoQ: Dion Almaer wonders on Twitter, "How hard will it be to debug code via Firebug once you are in JIT'd code?". What do you think about that?

Honestly, it won't be that different (to the frontend web developer, that is). Most of the changes are taking place far underneath the core of the engine, making the end result quite seamless to most web users.

One gotcha that exists right now (and it's unclear as to if it'll be resolved in time for Firefox 3.1's release) is that Mozilla's internal JavaScript debugger (the one that allows you to set breakpoints, etc. - and the one that powers Firebug) is unable to run at the same time as when tracing is enabled. This is another matter entirely, to the one outlined above, since once the user turns on the debugger they'll still be able to, happily, debug their JavaScript code (just not the JIT'd code).  

InfoQ: Do you see other vendors following the example of Mozilla, with just-in-time native code compilation?

Sure thing. A lot it depends on the details of how other ECMAScript engines are implemented. I fully expect to see other engines making improvements similar to what was done with Tracemonkey. 

InfoQ: Besides TraceMonkey what other breakthrough should we be expecting in the area of client-side scripting in the near future?

The next big thing is going to be threading. There is the Web Worker proposal being worked on by Google, Apple, and Mozilla under the auspices of the W3C. We'll start to see this arrive in browsers quite soon (some form will be in Firefox 3.1) and it'll absolutely help to revolutionize what's traditionally possible in a web application. 

InfoQ: Do you see JavaScript libraries like jQuery, ever shipping bundled with browser software? Would you foresee some of the functionality they offer, being offered by native browser APIs?

Shipping bundled with? doubtful. Packing useful APIs? absolutely. We're already seeing this with the implementation of the Selectors API specification in all browsers (IE 8, Firefox 3.1, Safari 3, Opera 10). Once all of those browsers reach a point of market saturation we'll be able to remove a large chunk of code from most JavaScript libraries.

Expect to see more of these improvements make it in to browsers in the upcoming years.

Dionysios G. Synodinos is a Web Engineer and a freelance consultant, focusing on Web technologies

1. Back to top

   GWT

   by Miguel Ping

   I think GWT will play a big role here. With all respect to javascript developers, currently the Java tooling is way ahead, with a native-performant javascript engine and the tooling available for Java, GWT will be a more common option in regards not only to RIA but also for more complex applications not necessarily UI related. If only GWT compiled other languages than Java...

   Reply

• Older >