Jetlag has me in its throes which is as good an excuse as any to share what has been keeping me up many nights over the past couple of years; a theory of the web as a platform.
I had a chance last week to share some of my thinking here to an unlikely audience at EclipseCon, a wonderful experience for which my thanks go to Mike Milinkovich and Ian Skerrett for being crazy enough to invite a “web guy” to give a talk.
One of the points I tried (and perhaps failed) to make in the talk was that in every platform that’s truly a platform it’s important to have a stable conceptual model of what’s “down there”. For Java that’s not the language, it’s the JVM. For the web…well…um. Yes, it bottoms out at C/C++, but that’s mostly observable through spooky action at a distance. The expressive capacity of C/C++ show up as limitations and mismatches in web specs all the time, but the essential semantics — C/C++ is just words in memory that you can do whatever you please with — are safely hidden away behind APIs and declarative forms that are unfailingly high-level. Until they aren’t. And you can forget about composition most of the time.
For a flavor of this, I always turn back to Joel Webber’s question to me several years ago: why can’t I over-ride the rendering of a border around an HTML element?
It’s a fair question and one I wrote off too quickly the first time he posed it. We have
<canvas> which lets us draw lines however we like, so why can’t we override the path painting for borders? Why isn’t it just a method you implement like in Flex or Silverlight?
Put another way: there are some low level APIs in the web that suggest that such power should be in the hands of us mortals. When using a low-level thing, you pay-as-you-go since lower-level things need more code (latency and complexity)…but that’s a choice. Today’s web is often mysteriously devoid of the sort of sane layering, forcing you to re-build parallel systems to what’s already in the browser to get a job done. You can’t just subclass the right thing or plug into the right lifecycle method most of the time. Want a
<canvas>? Fine. There you go. Want a
<span>s coming up! But don’t go getting any big ideas about using the drawing APIs from
<canvas> to render your
<span>. Both are magic in their own right and for no reason other than that’s the way it has always been.
You can see why people who think in terms of VM’s and machine words might find this a bit ahem limiting.
But how much should we “web people” care about what they think? After all, “real programmers” have been predicting the imminent death of this toy browser thing for so long that I’m forgetting exactly when the hate took its various turns through the 7 stages; “Applets will save us from this insanity!”…”Ajax is a hack”…”just put a compiler in front of it and treat it as the dumbest assembler ever” (which is at least acceptance, of a sort). The web continues to succeed in spite of all of of this. So why bother with the gnashing of teeth?
Thanks to Steve Souders, I have an answer: every year we’re throwing more and more JS on top of the web, dooming our best intended semantic thoughts to suffocation in the Turing tar pit. Inexorably, and until we find a way to send less code down the wire, us is them, and more so every day.
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 for gawker, 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 provide an API that becomes the new platform, 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 pages just 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.
What would it mean to be able to subclass an HTML Element?
We observed that most of what the current libraries and frameworks are doing is just trying to create their own “widgets” and that most of these new UI controls had a semantic they’d like to describe in a pretty high-level way, an implementation for drawing the current state, and the need to parent other widgets or live in a hierarchy of widgets.
Heeeeeyyyyyy….wait a minute…that sounds a lot like what HTML does! And you even have HTML controls which generate extra elements for visual styling but which you can’t access from script. This, BTW, is what you want when building your own controls. Think the bullets of list items or the sliders generated by
<input type="range">. There are even these handy (non-constructable!?!) constructors for the superclasses in JS already.
None of these are satisfying. Certainly not if what we want is a platform of the sort you might consider using “naked”. And if your “platform” always needs the same shims here and polyfills there, let me be candid: it ain’t no platform. It’s some timber and bolts out of which you can make a nice weekend DIY project of building a real platform.
So we need to do better.
What does better look like?
Better is layered. Better is being able to just replace what you need, to plug in your own bits to a whole that supports that instead of making you re-create everything above any layer you want to shim something into. This is why mutable root prototypes in JS and object mutability in general are such cherished and loathed properties of the web. It is great power. It’s just a pity we need it so often. Any plan for making things better that’s predicated on telling people “oh, just go pile more of your own parallel systems on top of a platform that already does 90% of what you need but which won’t open up the API for it” is DOOMED.
Thus began a archaeology project, one which has differed in scope and approach from most of the recently added web capabilities I can think of, not because it’s high-level or low-level, but because it is layered. New high-level capabilities are added, but instead of then poking a hole nearly all the way down to C++ when we want a low-level thing, the approach is to look at the high-level thing and say:
How would we describe what it’s doing at the next level down in an API that we could expose?
This is the reason low-level-only API proposals drive me nuts. New stuff in the platform tends to be driven by scenarios. You want to do a thing, that thing probably has some UI (probably browser provided), and might invoke something security sensitive. If you start designing at the lowest level, throwing a C++ API over the wall, you’ve turned off any opportunity or incentive to layer well. Just tell everyone to use the very fine JS API, after all. Why should anyone want more? (hint: graph above). Instead of opening doors, though, it’s mostly burden. Everything you have to do from script is expensive and slow and prone to all sorts of visual and accessibility problems by default. If the browser can provide common UI and interaction for the scenario, isn’t that better most of the time? Just imagine how much easier it would be to build an app if the initial cut at location information had been
<input type="location"> instead of the Geolocation API we have now. True, that input element would need lots of configuration flags and, eventually, a fine-grained API…if only there were a way to put an API onto an HTML element type…hrm…
In contrast, if we go declarative-only we get a lot of the web platform today. Fine at first but horrible to work with over time, prone to attracting API barnacles to fill perceived gaps, and never quite enough. The need for that API keeps coming back to haunt us. We’re gonna need both sides, markup and imperative, sooner or later. A framework for thinking about what that might look like seems in order. Our adventure in excavation with Web Components has largely been a success, not because we’re looking to “kernalize the browser” in JS — good or bad, that’s an idea with serious reality-hostile properties as soon as you add a network — but because when you force yourself to think about what’s already down there as an API designer, you start making connections, finding the bits that are latent in the platform and should be used to explain more of the high level things in terms of fewer, more powerful primitives at the next layer down. This isn’t a manifesto for writing the whole world in JS; it’s a reasonable and practical approach for how to succeed by starting high and working backwards from the 80% use-case to something that eventually has most of the flexibility and power that high-end users crave.
The concrete steps are:
- Introduce new platform capabilities with high-level, declarative forms. I.e., invent new tags and attributes. DOM gives you an API for free when you do it that way. Everyone’s a winner.
- When the thing you want feels like something that’s already “down there” somewhere, try to explain the bits that already exist in markup in terms of a lower-level JS or markup primitive. If you can’t do that or you think your new API has no connection to markup, go back to step 1 and start again.
- When it feels like you’re inventing new language primitives in DOM just to get around JS language limitations, extend the language, not the API
The trash truck just came by which means it’s 6AM here in almost-sunny London. WordPress is likewise telling me that I’m dangerously out of column-inches, so I guess I’ll see if I can’t get a last hour or two of sleep before the weekend is truly over. The arguments here may not be well presented, and they are subtle, but layering matters. We don’t have enough of it and when done well, it can be a powerful tool in ending the battle between imperative and declarative. I’ll make the case some other time for why custom element names are a good idea, but consider it in the layered context: if I could subclass
Cognitive dissonance, ahoy! You’re welcome ;-)