Wednesday, June 16th, 2010

JSKB: JavaScript Knowledge Base. Shrinking your code via BrowserScope and Caja

Category: Performance

We have a screwed up tensions on the Web. The size of your source code really matters for performance. The larger your .js…. the longer it takes it to get down the pipe. This has a perverse incentive to write terse uncommented code. Add to this the problem of having to work cross browser, and having to do so all at runtime, and you end up shipping a ton of code to browsers that will never touch it.

This is where Mike Samuel of Caja, and Lindsey Simon of Browserscope come in. They have a plan to help reverse code bloat with JavaScript:

Lots of compilers (incl. (JSMin, Dojo, YUI, Closure, Caja) remove unnecessary code from JavaScript to make the code you ship smaller. They seem like a natural place to address this problems. Optimization is just taking into account the context that code is going to run in to improve it; giving compilers information about browsers will help them avoid shipping code to support marginal browsers to modern browsers.

The JavaScript Knowledge Base (JSKB) on seeks to systematically capture this information in a way that compilers can use.
It collects facts about browsers using JavaScript snippet. The JavaScript code (!!window.JSON && typeof window.JSON.stringify === 'function') is true if JSON is defined. JSKB knows that this is true for Firefox 3.5 but not Netscape 2.0.

Caja Web Tools includes a code optimizer that uses these facts. If it sees code like if (typeof JSON.stringify !== 'function') { /* lots of code */ } it knows that the body will never be executed on Firefox 3.5, and can optimize it out. The key here is that the developer writes feature tests, not version tests, and as browsers roll out new features, JSKB captures that information, letting compilers produce smaller code for that browser.

The Caja team just released Caja Web Tools, which already uses JSKB to optimize code. We hope that other JavaScript compilers will adopt these techniques. If you’re working on a JavaScript optimizer, take a look at our JSON APIs to get an idea of what the JSKB contains.

You can see graphically how this works and learn more about how browser detection info is packaged:


  1. {
  2.   "!!this.window !== 'undefined' && this === window": true,
  3.   "typeof addEventListener": "function",
  4.   "typeof attachEvent": "undefined"
  5.   "typeof document.body.outerHTML": "undefined",
  6. }

Definitely feels like there is a lot of room to do more with a compilation step that only sends down the right JS for the given browser.

Posted by Dion Almaer at 8:16 am

3 rating from 2 votes


Comments feed TrackBack URI

So, browser detection rather than feature detection…?


Comment by adambankin — June 16, 2010

@adambankin: Feature detection by the coder, then one centralised place that does browser detection. You can’t expect everybody to update their code every time a new browser comes out, but you can expect (I hope) JSKB to update itself when a new browser comes out. Makes sense to me.

Comment by Skilldrick — June 16, 2010

@skilldrick — but we still have to know/be notified when a browser feature set changes (with a release/patch) so that we can recompile our code against the latest ruleset, right?

Comment by getify — June 16, 2010

This sounds interesting! Thanks for share!

Comment by fmvilas — June 16, 2010

Wow… as adambankin notes – browser detection? Really?

Assertion – not assumption, please.

Comment by rasmusfl0e — June 16, 2010

@Skilldrick… if the code isn’t updated then what good does it do that JSKB has the info about the new features. JSKB isn’t writing code for you.
I’m still thinking that this is browser detection no matter what and I had thought we were supposed to be moving away from that.
That’s not to say that JSKB is useless or has no purpose, just not sure if this much optimization is actually optimization.

Comment by edthered — June 16, 2010

GWT has been doing this for years now, along w/a whole lot of other optimizations.

Comment by abickford — June 17, 2010

This is feature detection at it’s utmost as these tests exercise the JS engine itself. How you use this info (in terms of delivering the payload) is another matter. I happen to think browser detection at that point in the game is pretty ok.

Comment by elsigh — June 17, 2010

THis is good project. I think there already was such project, or at least i have the same idea many years ago.

As of updates JSKB can assume that if browser have higher version than previous than it have the same functionalisties as latest one in database.

If some version or browser is unknown, it will not optimalize any code, and send full code.

What is problematic is dynamic detection and generation (of course with caching on server) based on UserAgent sent to client. But now if there is a proxy in beetwen (forward or reverse, both are highly probably), then we will have caching not working (because we can’t cache it) or we will broken page (becasue even different useragent will receive the same javascript from proxy cache). This can be solved by two phase loading, but then it adds some latency to the crucial loading of our page. :(

Comment by movax — June 19, 2010

Eventually for newer version of browsers (based on some version heuristic) it can send slightly less optimalized content. But still with many code fragments removed (for example this for especially OTHER browsers. [we are in Opera, but this code fragment is for fixing stupid IE], or this which are fallbacks of functionality which we know is supported, [we don’t need flash fallback code because we know Opera>10.50 supports HTML5 video]), but still send some detection codes for NEW features which possibly can be added later [We have unknown Opera 10.70, maybe they added WebSockets, who knows, send this detection code if not it will just not execute, at the slight cost of incresed size).

Considering all this, it doesn’t make any harm (if above rules can be implemented in JSKB). It never sends more bytes than in initial code with (properly done) capabilities detection, and degrade to sending more code (but still no mor ethan original one) if browser is unknown or it is newer version of browser (in which case some safe heuristics can be made).

Comment by movax — June 19, 2010

Leave a comment

You must be logged in to post a comment.