permalink

5

The Web’s Declarative, Composable Future.

The way that languages in the web platform evolve are in direct response to the pain caused by complexity. Pain is generally a bad thing and so it’s with better patterns and platform primitives that we can ease some of this complexity in the browser. Complexity on its own can take lots of forms, but when we look at the landscape of how developers have been building for the web over the last few years, common patterns can be one the most obvious things worth considering baking in solutions for. Layering the platform as part of the extensible web manifesto has been hugely helpful in making this possible.

This year, the platform is getting Web Components, bringing forward a way to make the relationships between markup and behaviour a lot less vague when you’re looking at the HTML. In one word, a future with Web Components is declarative. JavaScript still exists in this future, but is relegated back to a role where it acts as a glue holding the other bits of a component together. Web Apps in the near future will be composed almost entirely from elements (tags). Some of these elements (like the <audio> tag) will be given to you by the browser but others like <slide-show> will be custom elements provided by UI libraries or you can write it yourself. As the layer we’re using for composability is the DOM using attributes for our APIs, our elements will be significantly more interoperable than they’ve been in the past.

Imagine a future where elements or components written with different libraries can be used together with a level of ease.

Elements will (ideally) be created with a minimal amount of script and will try to reuse the functionality of other sub-elements where possible. Some apps are of course going to require more complexity than this, but this will not be the norm. Shadow DOM gives us an isolation boundary for CSS, HTML and JavaScript which make it fundamentally easier to build something in isolation. This world allows us to easily stitch together (compose) pre-made elements that are well engineered so we can focus on the logic in our apps and build better applications with ease. In Web Component circles, this whole movement is known as the declarative renaissance and it’s going to change things for the better.

One of the opportunities Web Components introduce is a chance to re-think and re-purpose existing best practices. If you’ve read my large-scale JS patterns write-ups of old, you may have gone on to craft systems using a componentization model for re-use, an event bus for inter-component communication and facades for abstracting away implementation detail behind an API. These ideas are still very much relevant today and I see them being evolved for a Web Component world through solutions like Polymer – polyfills and sugaring for this world and X-Tag. Polymer already has good support for message passing between elements and an API driven by element attributes is technically already a facade. We will also see much evolve through existing MVC libraries like Ember and Angular, as they look to embrace custom elements. Keep in mind, Web Components are not a silver bullet and the engineering best practices we as a community have strived for over the past few years will continue to be necessary:


In addition to the changes we’re going to see in Web Components, the rest of the platform is also evolving. JavaScript (through ES6 and ES7) is getting a true module system, data observation (Object.observe()), better language constructs (arrow functions, rest parameters, destructuring assignment) and native promises after years of client-side libraries coalescing around an idiom for async behavior. Our future is going to be more modular, more focused and more composable. Elements and JavaScript modules will work together in harmony (pun intended) for managing complexity. CSS is also growing up, slowly getting better primitives for containment, saying ‘this is a view, it’s something likely to change’ (via the will-change property). We may even finally fix the broken mess that is offline through Service Workers, giving us a way to build always-available applications in a sane and layered way.

HTTP 2.0 is also going to be important for the future, bringing the promise of a decreasing need for concatenation, inlined images or styles. With push support, the server could know about dependencies being requested and smartly push dependencies when you require a specific element to be imported.

The web is slowly growing up and each step we take towards lowering complexity is ultimately a good thing. Even if rebuilding your application using the new and shiny isn’t an option just yet, at minimum continue to design your current path using reusability and composability in mind. This will make a transition in the future, when you are ready, a more pleasant experience.

Where to go from here

Eric Bidelman, Rob Dodson and other pioneers have authored some fantastic 101 articles about the underlying technologies that form Web Components worth reading. The community have also begun fleshing out best practice ideas around element authorship which serve as a good sanity check for components written with and without Web Components.

With special thanks to Dimitri Glazkov, Dominic Cooney, Alex Russell, Dave Herman, Yehuda Katz and the countless others who are helping us get a saner platform for tomorrow. Thanks also go to Sindre and Pascal for their reviews of this article.

5 Comments

  1. Great points in here. Http 2 will heavily impact the performance tools we use today as well. Spriting techniques and concatenated files will not be needed except in rare cases. Let the revolution begin!

  2. Your checklist for writing proper web components is great. I’m going to keep this as a checklist for my team to keep in mind when writing web components. What are your thoughts on using Polymer with Angular? Is it necessary since Angular supports somewhat of a feature of Web Components with Directives.

  3. I think Addy put it well in his tweet featured in the article, we really do need to think about balancing the scales of what we use on each project and get the optimum in all the mentioned points whilst still making an awesome site for the user base and client.

Leave a Reply

Required fields are marked *.