Infrequently Noted

The interwebs, they are aboil!

People worthy of respect are publicly shaming those who don't toe the Progressive Enhancement line. Heroes of the revolution have taken to JavaScript's defense. The rebuttals are just as compelling.

Before we all nominate as Shark or Jet, I'd like to take this opportunity to point out the common ground: both the "JS required" ("requiredJS"?) and "PE or Bust" crews implicitly agree that HTML+CSS isn't cutting it.

PE acknowledges this by treating HTML as scaffold to build the real meaning on top of. RequiredJS brings its own scaffolding. Apart from that, the approaches are largely indistinguishable.

In ways large and small, the declarative duo have let down application developers. It's not possible to stretch the limited vocabularies they provide to cover enough of the relationships between data, input, and desired end states that define application construction. You can argue that they never were, but I don't think that's essentially true. Progressive Enhancement, for a time, might have gotten you everywhere you wanted to be. What's different now is that more of us want to be places that HTML+CSS are unwilling or incapable of taking us.

The HTML data model is a shambles, the relationship between data, view, and controller (and yes, browsers have all of those things for every input element) is opaque to the point of shamanism: if I poke this attribute this way, it does a thing! Do not ask why, for there is no why. At the macro scale, HTML isn't growing any of the "this is related to that, and here's how" that the humble <a href="..."> provided; particularly not about how our data relates to its display. Why, in 2013, isn't there a (mostly) declarative way to populate a table from JSON? Or CSV? Or XML? It's just not on the agenda.

And CSS...it's so painful and sad that mentioning it feels like rubbing salt in a wound that just refuses to heal.

Into these gaps, both PE and requiredJS inject large amounts of JS, filling the yawning chasm of capability with...well...something. It can be done poorly. And it can be done well. But for most sites, widgets, apps, and services the reality is that it must be done.

Despite it all, I'm an optimist (at least about this) because I see a path that explains our past success with declarative forms and provides a way for them to recapture some of their shine.

Today, the gap between "what the built-in-stuff can do" and "what I need to make my app go" is so vast at the high-end that it's entirely reasonable for folks like Tom to simply part ways with the built-ins. If your app is made of things that HTML doesn't have, why bother? At the more-content-than-app end, we're still missing ways to markup things that microformats and schema.org have given authors for years: places, people, events, products, organizations, etc. But HTML can still be stretched very nearly that far, so long as the rest of the document is something that HTML "can do".

What's missing here is a process for evolving HTML more quickly in response to evidence that it's missing essential features. To the extent that I cringe at today's requiredJS sites and apps, it's not because things don't work with JS turned off (honestly, I don't care...JS is the very lowest level of the platform...of course turning it off would break things), but because stuffing the entire definition of an application into a giant JS string deprives our ecosystem of evidence that markup could do it. It's not hard to imagine declarative forms for a lot of what's in Ember. Sure, you'll plumb quite a bit through JS when something isn't built into the framework or easily configured, but that's no different than where the rest of the web is.

Web Components are poised to bridge this gap. No, they don't "work" when JS is disabled, but it's still possible to hang styles off of declarative forms that are part of a document up-front. Indeed, they're the ultimate in progressive enhancement.

I'd be lying if I were to claim that bringing the sexy back to markup wasn't part of the plan for Web Components the whole time. Dimitri's "you're crazy" look still haunts me when I recall outlining the vision for bringing peace to the HTML vs. JS rift by explaining how HTML parsing works in in terms of JS. It has been a dream of mine that our tools would uncover (enabling understanding of) what's so commonly needed that HTML should include it in the next iteration. In short, to enable direct evolution. To do science, not fumbling alchemy.

It's key to understand is that "PE or Bust" vs. "requiredJS" isn't a battle anyone can win today. The platform needs to give us a way to express ourselves even when it hasn't been prescient of our needs -- which, of course, it can't be all the time. Until now, there hasn't been that outgas, so of course we reach out and use the turing-complete language at our finger tips to go re-build what we must to get what we want.

The developer economics will be stacked that way until Web Components are the norm. Call it PE++ (or something less clunky, if you must), but the war is about to be over. PE vs. requiredJS will simply cease to be an interesting discussion.

Can't wait for that day.

This was originally drafted as response to [Jo Rabin's blog post] discussing a meetup the W3C TAG hosted last month. For some reason, I was having difficulty adding comments there.

Hi Jo,

Thanks for the thoughtful commentary, and for the engaging chat at the meetup. Your post mirrors some of my own thinking about what the TAG can be good for.

I can't speak for everyone on the TAG, but like me, most of the new folks who have joined have backgrounds as web developers. For the last several months, we've been clearing away old business from the agenda, explicitly to make way for new areas of work which mirror some of your ideas. At the meeting which the meetup was attached to, the TAG decided at the urging of the new members to become a functional API review board. The goal of that project is to encourage good layering practice across the platform and to help WGs specify better, more coherent, more idiomatic APIs. That's a long-game thing to do, and you can see how far we've got to go in terms of making even the simplest idioms universal.

Repairing these sorts of issues is what the TAG, organizationally, is suited to do. Admittedly, it has not traditionally shown much urgency or facility with them. We're changing that, but it takes some time. Hopefully you'll see much more to cheer in the near future.

As for the overall constituency and product, I feel strongly that one of the things we've accomplished in our efforts to reform the TAG is that we're re-focusing the work to emphasize the ACTUAL web. Stuff that's addressable with URLs and has a meaningful integration point with HTML. Too much time has been wasted worrying about problems we don't have, or for good reasons, are unlikely to have. Again, I don't speak for the TAG, but I promise to continue to fight for the pressing problems of webdevs.

The TAG can use this year to set an agenda, show positive progress, and deliver real changes in specs. Already we're making progress with Promises, constructability, layering (how do the bits relate?), and extensibility. We also have a task to explain what's important and why. That's what has lead to efforts like the Extensible Web Manifesto. You'll note other TAG members as signatories.

Along those lines, the TAG has also agreed to begin work on documents that will help spec authors understand how to approach the design process with the constraints of idiomaticness and layering in mind. That will take time, but it's being informed by our direct, hands-on work with spec authors and WGs today.

So the lines are drawn: the TAG is refocusing, taking up the architectural issues that cause real people real harm in the web we actually have, and those who think we ought to be minding some other store aren't very much going to like it. I'm OK with that, and I hope to have your support in making it happen.

Regards