Phil Leggetter: The state of the componentised web

Published: August 14th 2014by Orde Saunders

Phil Leggetter (@leggetter) was speaking about the componetised web at EdinburghJS, these are my notes from his talk.

What are components?

We tend to use the same term too often to mean differnt things.

Smaller piece of a larger app
UI
Logical units of functionality

Things like jQuery mobile, Bootstrap, Gmail etc. We're already using this.

Components are composable. The compose window in Gmail is a good example: buttons, text fields.

Service components

It's not just UI.

AJAX
Data sync
Logging
In-app messaging
Contacts, email, chat

They should be modular, they should be inherently modular. They should give you some advantages, it should make things easier to maintain.

Cohesion: things that belong together should be grouped together. Assets for each module should be grouped together - HTML, CSS & JS.

They should be re-usable. However, don't over-engineer to achieve reusability - if it's only going to be used once then don't make it into a full library.

Because they have a defined API they should be interchangeable. You can change the code behind it without affecting other modules that use it.

If components are to be used together they need a way to communicate - e.g. a service bus.

Example

<my-avatar service="twitter" username="leggetter"/>

Can be created with Ember, Angular, React -> Reactive Elements, Backbone and others.

The future

Web components will be a native way of building new elements using the shadow DOM which provides a method of encapsulation. HTML imports and templates will make building them easier.

There is a Platform.js polyfill that is being used by Mozilla and Chromium whilst working on this. Can create a new custom element and/or extend an existing element.

X-Tag and Brick are Mozilla extensions to custom elements.

Polymer from Google: An opinionated way to work with Web Components.

We might not agree with how web components are implemented but if there is a standard way of doing it we can move on to how we use them rather than how we implement then.