Web architecture separates structured content (markup), presentation (style), and behavior (JavaScript). As recently as a decade ago, many developers worked in all three, but the years since Ajax arrived have brought more specialization. The rise of JavaScript in particular has led to approaches that have JavaScript carry the load. In the past few weeks, I’ve been delighted to see work that suggests a different path forward, one that takes greater advantage of the flexibility markup offers.
Last week, at the Artifact Conference, I was delighted to return to the world of web designers. The crowd was full of people who know very well what JavaScript can add to their site and how they want to include it, but who don’t focus on it. JavaScript is just a tool, often even a tool wielded later in the process after the basic framing of the site is complete.
Though the emphasis on design meant that many people were still enthusiastic about creating comps in Photoshop, one of my favorite talks included Jen Simmons emphasizing an HTML-first approach to page building, getting the structure of the document right before focusing on either style or behavior. The unstyled HTML she showed from the New York Times made clear the tangles that emerge from thinking of markup as just a byproduct of the other work done to build the site. Other talks explored complex interactions between browsers, markup, and styling needed to make responsive web design work.
This week brings Polymer, a pre-alpha of a project that makes HTML usefully extensible. Instead of creating a JavaScript program that deals with the entire page, Polymer focuses on JavaScript modules that deal with specific markup, markup you can choose. (It can still work with those programs, of course!)
While I love that Polymer is a surprisingly sudden implementation of ideas I suggested in Stop Standardizing HTML, the part I like better is that this approach to problem-solving makes it easier to include the designers I talked with at Artifact. New markup offering new capabilities is great, especially when it can be styled with familiar tools. Though it’s early, the Polymer approach promises a much easier conversation between designers, programmers, and the developers combining aspects of both.
Does this new markup extensibility mean that JavaScript developers will have less to do as modularization simplifies sharing? I don’t think so. Yehuda Katz, in Extend the Web Forward, suggests that there is a lot more extending to do:
When the browser has good extension points (or any extension points, really), we live in a virtuous cycle…
If things are working well, JavaScript library authors write new declarative APIs that the browser can roll in. Nobody wants to write everything using low-level calls to canvas, but we’re happy that canvas lets us express low-level things that we can evolve and refine.
Katz doesn’t claim it will be easy—he worries about “extension points that can be performance footguns”—but he does see the constant flow from imperative JavaScript APIs to more declarative approaches as the path forward. To me, that seems like the right way to balance flexibility with usability.
I’m hoping to hear a lot more of this kind of conversation at Fluent next week!
[adrotate banner=”3″]