Jan 19

Comparing the performance attributes of iOS browsers

Mobile, Tech, Web Browsing with tags: No Comments »


I recently talked about the attack of the mobile browsers.

Then, Steve shared bookmarklets for mobile performance work.

He and Jesse hosted a fantastic Velocity Summit in the city today with the best and brightest in the realms of web ops and browser land combined. It was an honor learning from them, and it was just fantastic to see top notch folks from Chrome, Firefox, IE participating and sharing ideas.

With all of the performance talk, I started to play with Steve’s work, and was reminded how much of a pain it is to work with bookmarklets on iOS. There are some solutions, from Dropbox, to syncing bookmarks (from iTunes as well as Firefox Home), but in general it can be a pain.

Some of the new iOS browsers have extension support though… such as the 360 Browser. I wondered if it would be more efficient to great extensions (they call them plugins, but that confuses the world with Flash etc) that are quickly actionable from within the browser. Ideally, I could tell the browser to always run the extension so I could collect data throughout a session.

One concern though was the fact that most users on iOS are coming at you from Mobile Safari, and although these new browsers are using the iOS WebKit APIs (as Apple won’t let them do anything else) how different are the browsers themselves?

BrowserScope to the rescue. I fired up and ran all of the tests in each browser application and compared the results. They were incredibly consistent. All of the numbers were the same when run on: Mobile Safari, Sleipnir, 360 Browser, and Skyfire except for the “Cache Redirects” test in the Network section. In that case, two of the browsers passed the test and the other two didn’t. All in all that is pretty friggin’ consistent though. The network connections were all the same for example….. so this makes me feel like there is room for a nice developer oriented iOS browser. Sure, it can’t get access to a lot of the low level data, but there is much that can be done, especially if you pair it with a remote session ability so you can power the beast from a desktop rather than the dinky device itself!

Jul 29

Capability based JavaScript loading; JS libraries catch up to GWT

Ajax, JavaScript, Tech with tags: 6 Comments »


Web developers have to walk around dragging a ball and chain. It is fantastic that we have a ridiculous install base (browsers, the Web runtimes) and a dynamic language in JavaScript.

The ball and chain though is the fact that we have to care so much about the payload of the application that we write. Less code means less bytes to download, and less for the JS runtime to load up.

This has bad consequences:

  • You are tempted to write hard to understand code
  • You have to balance functionality and code size much more than other environments
  • You end up getting tricky and come up with ways to dynamically load modules on demand
  • All of this time is time not spent on the app logic.

When you run into a problem like this in computer science what do you do? Build an abstraction!

GWT has done a great job here. It’s very nature requires a compilation step, and once you have to deal with that step…. you can do a lot at build time to change the above dynamics.

For example:

  • You can write nice explicit source code, and trust that the compiler will output optimized JS (which can look as ugly as sin for all anyone cares)
  • Your application can get faster with a new release of GWT, as the compiler gets better
  • A lot of advanced techniques such as code splitting, and deferred binding can be applied to allow logic to apply at build time as well as runtime.

Ignoring GWT, when you write a pure JS application for the Web, you are writing a cross platform application. Unlike clean portable C, you don’t have that compilation step to do clean up work for you on each platform, so you end up with a lot of runtime conditional logic.

You try to do object detection rather than user agent conditional, but still, you end up both downloading the code necessary to run in all environments, and you have the overhead of loading and executing that code.

Chances are you are smart and don’t do if() checks all the time, but maybe do so once when loading up. For large chunks of big differences, maybe you do something like:

var Foo = (sometest) ? function() {
    // do it like this
} : function() {
    // do it like that

If you take a look at some parts of popular JavaScript frameworks, you see that they are abstractions or fixes for various browsers. As browsers have stepped up to the plate recently, they have fixed a lot, and suddenly you take a step back. A lot of frameworks have a chunk of code to give us the ability to do smart things with CSS querying. Modern browsers support querySelectorAll (even with some bugs) and getElementsByClassName so a lot of the code is un-needed…. unless you care about the old browsers.

We shouldn’t have to download all of that cruft on the other side of the if() statement when we don’t use it!

The GWT compiler can output versions of your application targeted to a given browser. Only the fastest, minimal code, will get sent down. Deferred binding goes far beyond just browser type (can deal w/ locales and much more) too.

GWT isn’t the only horse in this race though.

Alex Russell started to sprinkle in some directives to Dojo that would enable you to do a build that is WebKit targeted. A major use case for all of this is making sure that you are sending down lean code in the mobile space. It can matter everywhere, but when you are dealing with grown up walkie talkies…. you want to really optimize.

And this brings us to YUI. I was really excited to see some of the features in the YUI 3.2.0 preview release. Great stuff for touch/gesture support, but what stood out for me was “YUI’s intrinsic Loader now supports capability-based loading”. A-ha!

I poked around the source to see how it was used. Here is one fake example that shows how it works. When you boot up YUI you can add in “conditions” which are in charge of working out whether to load something. You can currently tie on to user agent, or write a test function:

    modules: {
        lib2: {
            requires: ['yui'],
            fullpath: 'js/lib2.js',
            condition: {
                trigger: 'node-base',
                ua: 'gecko'
        lib3: {
            requires: ['yui'],
            fullpath: 'js/lib3.js',
            condition: {
                trigger: 'event-base',
                test: function(Y, req) {
                    return Y.UA.gecko;
}).use('node', function (Y) { .... });

The YUI team uses this themselves to only load certain ugly DOM stuff for IE6 when needed:

"dom-style-ie": {
    "condition": {
        "trigger": "dom-style", 
        "ua": "ie"
    "requires": [
YUI.add('dom-style-ie', function(Y) {
    // ....

This makes a ton of sense, especially for the libraries themselves to do this work. They are the ones that do the heavy lifting of cross browser ugliness, all to allow us to write to an API that works.

Beyond that, we can then ourselves split out code if it becomes a performance issue.

Of course, the value of the test() function is that you can do capability based testing (not just user agent testing…. hence the name!). This means that you can do a test say for Canvas support (as Zach mentions in the comments) document.createElement(’canvas’).getContext, and load up excanvas or another shim library if it doesn’t exist.

Using modernizr and ilk, we could build out “plugins” for YUI that auto load based on common capabilities. You can imagine running a YUI build, having it detect that you are using a capability, and then automatically load up a plugin that has the condition all loaded up. What a great user experience as a developer!

Maybe it makes sense to come up with a common pattern and conventions for dealing with this issue. How do you name your CSS/JS? Do we setup server side hooks so we don’t even need loaders necessarily?

I can certainly see a day where you may be asking the Google Ajax Library service for jquery.js, but it is returning jquery.ie.js to you.

Aug 22

TraceMonkey: DOM, Canvas, Opensource and more

Ajax, JavaScript, Tech with tags: 6 Comments »

Brendan Eich promised that trace based JIT’s will give us killer JavaScript speed and now we have seen the fruit of his labour with TraceMonkey (adds trace smarts to Tamarin-tracing).

A lot has been said already, but I am really excited about much more than the “look at how we run Sun Spider”.

The DOM matters

Although it may not sure in todays code drop, Brendan gets that you have to care about the DOM and not running while(1) { cheasyTest(); }:

  • He gets it: “As we trace more of the DOM and our other native code, we increase the memory-safe codebase that must be trusted not to have an exploitable bug.”
  • If DOM code comes out of native code and into JavaScript, it matters: “TraceMonkey advances us toward the Mozilla 2 future where even more Firefox code is written in JS. Firefox gets faster and safer as this process unfolds.”


You know Canvas? It’s days are coming… fast, as John Resig mentions:

One area that I’m especially excited about is in relation to Canvas. The primary thing holding back most extensive Canvas development hasn’t been rendering – but the processor limitations of the language (performing the challenging mathematical operations related to vectors, matrices, or collision detection). I expect this area to absolutely explode after the release of Firefox 3.1 as we start to see this work take hold.

Opensource matters

None of this could be accomplished without the great side of opensource. TraceMonkey uses Tamarin-tracing, which enables it to build on amazing code.

TraceMonkey itself is opensource, which enables the SquirrelFish team say, to check it out. And, vice versa. This will keep the competition going along nicely.

This kind of competition is phenomenal for us, the consumers of the Web. Performance is key in 2008, and Web developers get to laugh all the way to the bank.

Thanks guys!

Dec 30

Steve Souders is no longer Chief Performance Yahoo! Instead, a Googler

Google, Tech with tags: , 1 Comment »

Steve Souders is known for:

The last point is the most important of course. Although it must be fun to say that you are Chief Performance Yahoo! to non-geeks at parties, he has left Sunnyvale, and has head a touch North to Mountain View.

I am very excited indeed to say that he is going to be starting at Google on January 7th, as you can see from the top of his site:

I’m at Google as of January 7, 2008.

I am glad he put a link to Google in there, so we can get the Guice.

It will be great to start working with Steve, even if we differ on some points. For example, he prefers the non-Ajax versions of maps as he thinks they are too slow. Are you kidding me? Do you never move around in the map then?

Lunch is on me on the 7th, Steve :)