JournoGeekery


  1. Bedrock | Infrequently Noted, aka Alex Russell

Let that picture sink in: at 180KB of JS on average, script isn’t some helper that gives meaning to pages in the breech, it is the meaning of the page. Dress it up all you like, but that’s where this is going.
Don’t think 180KB of JS is a lot? Remember, that’s transfer size which accounts for gzipping, not total JS size. Oy. And in most cases that’s more than 3x the size of the HTML being served (both for the page and for whatever iframes it embeds). And that’s not all; it’s worse for many sites which should know better. Check out those loading “filmstrip” views forgawker, techcrunch, and the NYT. You might be scrolling down, looking at the graphs, and thinking to yourself “looks like Flash is the big ticket item…”, and while that’s true in absolute terms, Flash isn’t what’s blocking page loads. JS is.
And what for? What’s all that code doing, anyway?
It’s there for three reasons: first, to clean up the messes that browser vendors aren’t willing or able to clean up for themselves; second, to become the new bedrock that you can build on, and lastly to provide the app-specific stuff you are trying to get across. Only the last one is strictly valuable. You’re not including JQuery, Backbone, Prototype or Dojo into your pagesjust because you like the API (if you are, stop it). You’re doing it because the combination of API and even behavior across browsers makes them the bedrock. They are the new lisp of application construction; the common language upon which you and your small team can agree; just don’t expect anyone else to be able to pick up your variant without squinting hard.
This is as untenable as it is dangerous.

I find myself wishing more jet lag on Alex.

    Bedrock | Infrequently Noted, aka Alex Russell

    Let that picture sink in: at 180KB of JS on average, script isn’t some helper that gives meaning to pages in the breech, it is the meaning of the page. Dress it up all you like, but that’s where this is going.

    Don’t think 180KB of JS is a lot? Remember, that’s transfer size which accounts for gzipping, not total JS size. Oy. And in most cases that’s more than 3x the size of the HTML being served (both for the page and for whatever iframes it embeds). And that’s not all; it’s worse for many sites which should know better. Check out those loading “filmstrip” views forgawkertechcrunch, and the NYT. You might be scrolling down, looking at the graphs, and thinking to yourself “looks like Flash is the big ticket item…”, and while that’s true in absolute terms, Flash isn’t what’s blocking page loads. JS is.

    And what for? What’s all that code doing, anyway?

    It’s there for three reasons: first, to clean up the messes that browser vendors aren’t willing or able to clean up for themselves; second, to become the new bedrock that you can build on, and lastly to provide the app-specific stuff you are trying to get across. Only the last one is strictly valuable. You’re not including JQuery, Backbone, Prototype or Dojo into your pagesjust because you like the API (if you are, stop it). You’re doing it because the combination of API and even behavior across browsers makes them the bedrock. They are the new lisp of application construction; the common language upon which you and your small team can agree; just don’t expect anyone else to be able to pick up your variant without squinting hard.

    This is as untenable as it is dangerous.

    I find myself wishing more jet lag on Alex.