Web dev at the end of the world, from Hveragerði, Iceland

The new age of HTML:
the web is being torn apart

For web development to grow as a craft and as an industry, we have to follow the money. Without money the craft becomes a hobby and unmaintained software begins to rot.

But which money?

And still the little article memorializing the little 5K contest sat online, its lessons forgotten in an arms race wherein the average home page now weighs over 2MB. Put that in your Edge network and smoke it.

15 Years Ago in ALA: Much Ado About 5K by Jeffrey Zeldman (569 words).

A few years ago all websites functioned much in the same way. They often looked very different—sometimes disastrously so as Geocities was witness to—but they all worked pretty much the same way.

Scrolling, loading, link traversal, form submission, and history management was in the hands of the browser. The only thing the page contributed was a document, with styles, and a set of links to other network locations (anchors, both POST and GET forms, media objects to be included, etc.). What JavaScript contributed to the mix was the ability to modify the document in situ and, later, to submit forms without leaving the current document (AJAX).

This is hypertext: a structured document with meaningful links to other structured documents.

We did a lot with just hypertext. We still do a lot with just hypertext. Its architecture (i.e. links that do stuff) gives it a tremendous reach that goes beyond anything app or other media platforms have ever been able to provide. It’s the architecture that enables the reach, not the protocols or file formats.

That massive distribution and accessibility makes the web desirable. But as other industries glom onto the web in order to get its reach, their needs begin to skew the web as a platform.

We have a plurality of industries building on the web—needing the web—and we can’t solve all of their problems at the same time.

Instead of viewing the web as a single platform, it’s more productive to consider it to be a group of competing platforms with competing needs. The mix is becoming messy.

  1. Services (e.g. forms and ecommerce, requires accessibility, reach, and security)
  2. Web Publishing (requires typography, responsive design, and reach)
  3. Media (requires rich design, involved interactivity, and DRM)
  4. Apps (requires modularity in design, code, and data as well as heavy OS integration)

The first platform is ubiquitous. That’s its primary strength. It’s the platform you interact with whenever you use a service whose foundation is forms and HTTP (then possibly progressively enhanced): buying at Amazon, filling out a Council Tax form, etc.

The second is any media that has hypertext as its foundation—where meaning is transmitted primarily through text and links. It’s what we old-timers think of when somebody says ‘the web’.

The third platform belongs to the industries that before piggybacked on the web through the use of browser plugins like Flash or Silverlight. They benefit from the ubiquity of the web but aren’t beholden to it—are quite willing to sacrifice it for short-term business concerns like DRM. Beyond that, their needs should in theory be quite compatible with the document-with-links model of the web. The problem is that their advertising-driven business model drives them to a self-destructive need to control every detail of every aspect of the page as a media object. Flashy designs, basically.

The fourth platform is the burgeoning app platform that is growing within the web like a cancer [ed. biased much?]. App developers have no need of the web’s ubiquity—a marginal improvement over the reach of native platforms is all they need—and the very architecture of most apps is in direct conflict with the web’s architecture of independent but linked documents.

Until recently the first and second were the only platforms the web had to service. They coexisted symbiotically because their needs match the basic architecture of the web. They both require global reach. They both depend on accessibility and scalable designs. (E.g. don’t design for the device. Separate content and design. Semantic structure. Etc.)

These needs are economic ones that stem from the business models (or funding, in the case of public services) of the dominant institutions of each platform. In the case of the first two platforms, those needs are sympathetic.

Our problems really started when the other two platforms took root on the web with the death of Flash on the one hand and the rise of Gmail and similar apps on the other.

The economically driven needs of the last two platforms don’t match those of the first two. They don’t need the same accessibility or reach. (Why do you think Google finds it acceptable to roll out web apps that only support Chrome?) Their requirements lead to a complexity that in many ways harm accessibility and reach. Heavy and flashy design and DRM both directly make accessibility and reach harder. The platform integration that apps need is next to impossible to do usably in a OS-independent way. No matter what you do, the most usable APIs will reflect the quirks of the host platform. The introduction of modular and componentised features to the web platform itself is driven by a vaguely defined app architecture that increases the complexity to such a degree that it makes accessibility and flexible design harder and more costly.

Apps don’t need the universal reach that regular hypertext services need because even a limited subsection of the web is a step up in distribution over regular app platforms. More importantly, what the various companies need from the web as an app platform diverges considerably.

Earlier this year I wrote the following about what I think is happening in web standards:

(This section was originally prompted by “Tired of Safari” and “Apple’s Web?”)

The drama surrounding touch events is a long-standing one and Apple has done a good job of playing the villain in this particular farce.

This is just one facet of the core problem with the web as an application platform: we will never have a unified web app platform.

What Apple, Google, Microsoft, and Mozilla want from web applications is simply too divergent for them to settle on one unified platform. That’s the reason why we’re always going to get Google apps that only work in Chrome, Apple Touch APIs that are modelled on iOS’s native touch model, and Microsoft Pointer APIs that reflect their need to support both touch and mouse events on a single device at the same time. There really isn’t an easy way to solve this because standardisation hinges on a common set of needs and use cases which these organisations just don’t share.

The web continues to work well as a platform for structured documents that are progressively enhanced with interactivity. Just hypertext and forms alone will get you a lot further than you think towards solving most of the ‘app’ problems that organisations are facing today. With a bit of progressive enhancement you can create really productive systems that work everywhere because they are just bog-standard websites.

Unlike structured, interactive documents, complex web applications that are built on a common set of APIs — APIs which work the same everywhere — are very unlikely to happen. You’ll have your Chrome APIs. You’ll have your Safari APIs. You’ll have your MS and Firefox APIs (because their needs are quite similar). And you’ll have cross-platform frameworks that bridge the gap by making compromises everywhere. But a universal web application platform? That’s just another spin on the ‘write once, run anywhere’ chimera.

Of course, Apple is still being very annoying in this particular case and their reasons for objecting seem spurious and political. I’m not trying to defend Apple.

What I’m trying to say is that we should expect the drama surrounding Pointer Events to repeat itself a lot over the next few years. It’s a taste of things to come.

It’s hard to get a picture of where the web is at as a platform just by randomly browsing Can I Use or following blog discussions.

But given how frequently both Google and Apple (like in the posts I linked to and commented on yesterday) are being compared to Microsoft it’s clear that something’s up.

The standardisation process has always been fraught with difficulties and tensions but I think it’s clear that the various tech behemoths that influence standardisation are finding less and less common ground and time passes.

If you’ll let me caricature the various companies’s attitudes a bit:

Google wants apps that look and work identically across Android, iOS, and web browsers and it wants them all to work like Android apps. Moreover, its various transpilers and cross-compilers indicate a desire for these apps to share a considerable amount of code and architecture.

Facebook, as evidenced by its React project and other opensource code, wants apps to share an architecture but not UI (i.e. do what’s the best UX for the platform).

Apple seems to like things like CSS Shapes and Regions and other design-oriented features but little interest in implementing app-related features. (Although, oddly enough, they don’t support OpenType font-feature-settings.)

Mozilla wants ‘webby things for the web’: APIs that conform to the principles and architecture of the web. (Google, in contrast, seems less fussed about that.) But they’re also eager to turn the web into a truly universal platform.

Opera seems to have ceded all strategic direction to Google.

And Microsoft… Microsoft’s seeming goals actually look well aligned with Mozilla’s goals, for good reason. They are both minority platforms locked out of the big platforms of the day: Android and iOS.

These companies want different things from the web and once you’ve covered the basics, agreeing on a common, standardised approach to things like app architecture, UIs, and UX is going to be progressively more difficult.

Once you’ve gotten these companies to agree on basic APIs like FilesCryptography, basic CSS design and layout features, Audio, and such standardising the rest is going to be harder because there is no one true solution to higher level platform problems like what architecture is best for any given app.

I don’t mind that, personally. I like the tactic that Facebook has been using of building on top of what’s available, transpiling from upcoming standards where available, and creating an architecture that seems to be a fairly sensible one, but I also like the fact that we aren’t all forced into the architecture they’ve chosen. Once you get up to the level of app architectures, standardisation becomes less and less desirable because architectures vary.

And that’s without getting into the discussion of whether apps and their architectures are relevant to the web in the first place. As I wrote yesterday, we can get very far just by using hypertext, forms, and progressive enhancement.

What worries me more is the general question of quality. Apple’s issues with the quality of iOS8 and Yosemite have been much discussed (for good reason, they are substantially more buggy than their predecessors in my experience). But both Chrome and Firefox have their own quality and reliability issues as well that never seem to quite go away.

What hope do we have for standardising complex new app architectures when we don’t seem to be able to reliably implement the foundation they’re built on?

Even if we can address the divergences we are still hit hard by the emerging complexity of this multi-headed hydra of a platform.

It’s a problem to just change specs. But it’s an increasingly bigger problem not to clean and prune them. The intimidating complexity of web standard specs should precisely be a motivation, not a threat, to come up with a plan. It follows the populist version.

Web Standards: We’re F’ing It Up by Jens Oliver Meiert (754 words).

Now we’re seeing an increasing realisation that the interaction and design heavy approaches geared for app development directly harm the business needs of regular publishers and web service providers.

I quoted the following in my post on the rollout of Facebook’s Instant Articles.

There’s this thought in my head that, like a broken record, keeps repeating to me and everyone around: “Stop breaking the web.” And if I think about it more, I realize it’s related to this fundamental idea that I have, which makes me want to push the web forward and make it a better place. Because isn’t that what we, the designers and developers of this medium, should strive for and be proud of?

The Many Faces of The Web by Viljami Salminen (811 words).

There’s this sense that by ‘appifying’ the web we are directly compromising the capabilities that give us the most value, that by solving the problems of web app development we are creating problems for the other parts of the web platform. That what the ‘old’ web needs and its users expect isn’t really compatible with what the new web app platform is offering.

Especially the common disregard its proponents have for performance.

Akamai’s study shows us some very strong facts about percieved performance, like:

  • 47% of people expect a web page to load in 2 seconds or less.
  • 40% will abandon a web page if it takes more than 3 seconds to load.
  • 52% of online shoppers claim that quick page loads are important for their loyalty to a site.
  • 14% will start shopping at a different site if page loads are slow, 23% will simply stop shopping.
  • 64% of shoppers who are dissatisfied with their site visit will go somewhere else to shop next time.

In addition, it’s been proven there is a direct relationship between performance and conversion rates. No matter what your site is offering, users won’t get there if they have a slow experience. For example, Walmart.com found that for every 1 second of improvement, they experienced up to a 2% conversion increase.

Making a difference with performance by Jaime Caballero (1849 words).

The Akamai study referred to above makes for a useful read: [PDF] (4257 words, mostly preamble and appendices, it seems). As do the Walmart.com slides (715 words).

From the Walmart post:

  • For every 1 second of improvement they experienced up to a 2% increase in conversions
  • For every 100 ms of improvement, they grew incremental revenue by up to 1%

Let’s, for now, accept Facebook’s figure of 8 seconds on the average as well as Akamai’s study as both being in the general ballpark of being correct. If we decide to just let hardware improvements fix the problem then it’ll be at least four years until load times begin to match our users' expectations. That’s assuming hardware can solve the problem (e.g. instead of getting more powerful, average hardware might get cheaper instead, and the network might improve at a different rate). And that’s assuming we stop adding crap to the platform. And that’s assuming that hardware and infrastructure improvements will be evenly distributed.

Four years is a long time for us to keep losing business.

We also actually need the massive reach and accessibility that traditional web approaches provide.

What’s wonderful about email and the web is that they are both the widest common denominator… (@jasonfried)

Our services and ecommerce sites need to be much more robust than a complex app that only works in the latest browsers.

Progressive Enhancement is not about catering for those who disable JavaScript. It’s about enhancing the experience when certain JavaScript features are available. The application may offer a miserable interface when JavaScript is disabled but the user still gets something.

The JavaScript-Dependency Backlash: Myth-Busting Progressive Enhancement by Craig Buckler (2170 words).

We need to avoid digging ourselves into holes.


Build for modern browsers. Test your work in those and make sure the experience for an up to date browsers is as you want it. Then look at the problems you have, alongside your policy in terms of what you are delivering to older browsers, and see what you need to fix those issues.

Stop solving problems you don’t yet have by Rachel Andrew (1052 words).

We need to accept that JavaScript merely adds to and enhances the web and isn’t a replacement for the web.

I am very much a fan of JavaScript and its capabilities. However, I am also on the side that because you can do it, does not mean you should.

The JavaScript Framework Bandwagonism by Teylor Feliz (1407 words).

The discussion surrounding Facebook Instant Articles bring to light two different solutions to the problem.

The first is the path that Instant Articles suggest: stripping the web down to what matters. Build on HTML and HTTP and ditch (or massively cut back) the browser as a rendering platform. We can do this without locking ourselves into the Facebook silo.

I’m genuinely really intrigued by Facebook’s Instant Articles tech: It’s HTML under the hood, but mapped to a native, non-CSS layout system. It’s the next step up from the @Readability bookmarklet and its ilk: An opinionated way to present raw HTML. To that end others could build new, open, opinionated HTML Renderers that also ignore CSS and JS. (But also respect publisher ads/analytics.) (@benward, 2, 3)

It may come as a surprise to some out there but there is already a well-tested platform that behaves exactly like that: feeds. Namely RSS and Atom.

It’s time to look at feeds and syndication again. Feeds are not a mainstream platform, but they have proven to be resilient and have a substantial niche following. Whatever people choose to use doesn’t have to be the Atom or RSS formats but their behaviour—only transmit meaningful structure and leave rendering entirely in the hands of the client—may be exactly what we need.

The second approach is to build on existing web development practice and opt out of the app race altogether: focus on progressive enhancement, perceived performance, and responsive design. Stick to the basic architecture of the web, that of documents, with styles, that link to each other, and are enhanced by JavaScript.

It’s time to again take a look at what we can do with markup (the simpler the better) and HTTP as the foundation and thinking of everything else as optional enhancements.

A few weeks ago I wrote the following:

I’m packing my stuff into boxes. At the last minute, of course, since the truck arrives early tomorrow morning.

While I’m packing, I’ve been listening to a variety of podcasts on web development. I don’t listen to these podcasts for their information. In between the casual banter and chat that surrounds the usual talking points, a sense of a cohesive and mature craft starts to form. The conversations surrounding the craft bring out the art in it.

Progressive enhancement. The indie web. Microformats 2. Responsive design. Adaptive content. Isomorphic or progressive javascript.

These are all of a kind. They are a part of the art of developing for a fluid platform with wide-ranging capabilities—capabilities that can change on the same device from one extreme to another, within minutes, just by walking down into the basement seating area of your local coffee shop.

There is an art to making things that not only tolerate this quixotic foundation, but thrive. It’s obvious that a large and influential contingent in the web development community is driven by a strong sense of what works and what doesn’t work in this environment.

It’s also obvious that a just as large contingent doesn’t.

Client side rendered web apps with no fallbacks for when the javascript fails to load or stalls mid-load—which happens all the time on slow connections. Sites that assume everybody is running the latest browsers on a fast connection and are completely useless and inaccessible anywhere else. Web apps that only work in a single browser. The way almost everybody seems to use Angular, Ember, and React.

Treating the web like another app platform makes sense if app platforms are all you’re used to. But doing so means losing the reach, adaptability, and flexibility that makes the web peerless in both the modern media and software industries.

Even if you do pull it off, you can only succeed by sacrificing the very qualities that justify the web’s existence.

Or, at least that’s what I’m thinking as I’m packing my boxes well into the night, hoping to finish in time for me to get a few hours of sleep before the movers arrive in the morning.

These two approaches are complementary. They both take HTML as the foundation for a meaningful structure and HTTP as the transport to get it from here to there.

We have a very useful platform in the web, as long as we avoid the sandpits. There is a whole host of projects, publications, and services that not only function well on the ‘limited’ web but thrive. By embracing the ‘Wabi Sabi’ of simple markup I firmly believe we can make great things.

You can also find me on Mastodon and Bluesky