How much code in the browser is too much?

Jul 7, 2005 12:26 · 458 words · 3 minute read

With the ascent of AJAX, many people are writing or considering writing more code to run in browser than they had in years. JavaScript, once left for dead as being too incompatible and impossible to debug, is now being viewed as something usable.

Firefox/Mozilla has certainly helped the renaissance. With an honest-to-goodness debugger, plus a super-handy web developer toolbar, you can really get a view into once going on. Selenium provides a mechanism to run tests in-browser, so that you can get all of the benefits of an automated test suite making sure your code works in different browsers.

All of this recent goodness is causing people to start approaching JavaScript as a real programming language. However, JavaScript is still implemented a bit differently between browsers, and its object model is definitely different from what most people are used to. Ian Bicking wrote about his troubles working with Prototype.js’s extended object model. Bob Ippolito has been writing all month about JavaScript warts when it comes to real programming.

If you take a look at the kinds of things that Bob is implementing, you’ll get the idea that Bob is trying to do real development in-browser, turning it into a real layer in an application. Given that people have made sophisticated email programs and spreadsheets in JavaScript, people have certainly done this before. But, most of the scripts I’ve seen have been focused on whizzy special effects.

So, to the question then: how much should you do with JavaScript? For just about any application, I would say that the answer is “as much as you can”. Assuming you don’t have some weird requirement to support Netscape 4.x or IE on the Mac, and I feel sorry for you if you do, you can reasonably do quite a bit in JavaScript. The limiting factor will likely be JavaScript performance.

JavaScript is slow. Don’t believe me? Check out something computationally intensive like encryption or trying doing an XSL transform without native browser support (you’ll have to use Safari for that, to see what I mean).

The benefit to using JavaScript can be huge, though. Even though it is slower than the language being used on the server side, that work is being done off of your server. If you’re careful about how much data you feed to the browser to process, quite a bit of the formatting work can be offloaded there. And, if you take advantage of native code as much as possible, you can even handle fairly sizable chunks of data.

Given the value in doing JavaScript today, a framework like Bob Ippolito’s MochiKit that extends JavaScript’s object model can seriously ease the burden of putting together robust code that runs in-browser. JavaScript is definitely entering a new era.