Elusive Markup Abstractions

As a long-time proponent of progressive enhancement, I’m very much on board with HTML Web Components: Core functionality can and should typically be expressed in HTML, delivered fully-assembled to the client, where it can then be augmented with additional functionality.

This approach has plenty of benefits for users, but also tends to produce simpler architectures – ergo: It’s superior engineering.

Yet many templating systems are insufficiently powerful to enable composable abstractions for recurring markup patterns.1 Frustratingly, that’s a major factor in the proliferation of client-side rendering2: Client-side frameworks, for all their faults, do provide reasonable mechanisms for encapsulating markup definitions. Such client-side abstractions additionally have the advantage of appearing to be portable and thus reusable, as JavaScript is (somewhat naively) perceived as a universal runtime – in contrast to server-side scenarios, where different systems might employ a variety of technologies for generating markup.

Thus templating remains the Achilles’ heel of HTML-first advocacy: A structural disadvantage that I rarely see being addressed by fellow proponents of progressive enhancement. In my experience, this seemingly mundane aspect frequently lures people into architecturally unsound decisions.

After years of trying to grapple with this – sometimes going to absurd lengths – I can only resort to advising folks that templating should be a deciding factor in their technology choices from the start.