There are two opposing schools of thought when building applications or any other significant ‘things’ with web technologies. I’m of the opinion that most of us are best served somewhere in the middle of those two schools.

The ‘web continuum’ camp believes that all browsers and platforms should be supported to some degree. By addressing the lowest possible watermark of capabilities, a base experience provides core functionality for all. Experience is then layered on in enhancements.

When I hear people talk about this. Especially when as passionately and eloquently argued as Andy Budd on episode 173 of the Shop Talk Show, I’m pretty convinced by the argument. That’s been my default mindset and philosophical approach for as long as I can remember.

However, day to day, working on a large application built on web technologies, I am struck by how unrealistic and stifling that approach can be in practice.

The flip side, approach-wise is an aggressive ‘last x’ approach where you might insist users are running one of the latest versions of a couple of browsers. This limits testing overhead and consequently speeds development but it’s just not a place most of us can (or would want) to exist in.

However swallowing the continuum approach wholesale can be problematic. If 40% of development effort is being expended to service 1–2% of the user base that just doesn’t make sense, practically or fiscally. Before I come to my proposal, I’d like to reiterate the inherent issues when trying to ‘support’ everything.

Old platforms and browser versions hold product development back

Forgive me for stating the obvious but ‘New’ means something has new features. If it’s not new or current, then it’s old, and consequently lacks features that ‘new’ or ‘current’ has.

These days, it’s rarely a question of if we can work around the limitations of old platforms, it’s whether it is prudent to do so when doing so adversely impacts the vast majority of users.

…logic clearly dictates that the needs of the many outweigh the needs of the few
Spock

An example

On the surface it seems trivial to provide a fallback graphic and associated CSS for when Android < 4 (which doesn’t support SVG) requires support. We would create two assets: one a PNG spritesheet and the other an SVG spritesheet. Then in the style sheets we could do this, using Modernizr to provide the fork:

.our-Image {
    background-image: url("$(path)/image.png");
    .svg & {
        background-image: url("$(path)/image.svg"); 
    }
}

Or, using feature queries:

.our-Image {
    background-image: url("$(path)/image.png");
    @supports (fill: red) {
        background-image: url("$(path)/image.svg"); 
    }
}

Either way, providing a fallback like this is no big deal. Except when this pattern is repeated across an application a hundred or so times. Sure, gzip will generally gobble up this kind of duplication and we have tools to automate the creation of fallback assets but it all adds up to a slower product. This ‘support all at all costs’ mindset carries a cost. We need to be grown up enough to understand that sometimes it’s not worth it. It can result in what the Chinese would term ‘Lingchi’ or in my parlance, death by a thousand cuts.

Anyway, the point of this preamble is to tell you I’m coming around to the idea of ‘minimum system requirements’.

This problem has been solved before

Back in the late 1990s/early 2000s I enjoyed a fair bit of PC gaming. Half Life, Ghost Recon, Quake etc. I could happily while away a few hours on the latest first-person shooter. Hand in hand with this hobby was an obsession with performance.

You see, PC hardware was a continuum. It was possible to have incredibly low powered PCs and it was possible to have incredibly high powered PCs, plus everything in-between. The highest performing PC system got you the best possible gaming experience. If your PC was lower powered you could often still play the game in question, it just didn’t perform quite as well. This was quite a different model than consoles where there was a single ‘locked down’ hardware platform. As a corollary to this situation, I got quite proficient at building my own PC rig to eek the best performance out of the games I way playing.

Suppose you were the manufacturer of a game. How can you possibly cater for all?

There is an ever widening continuum.

You want to support the widest possible user base.

It’s not practical to provide and support an experience for the entire gamut of the continuum.

The solution that was widely adopted in the PC gaming industry was minimum system requirements.

A ‘minimum’ set of system requirements was documented on the side of the game, often alongside a ‘recommended’. It might be that something below that threshold of the continuum would play the game, it’s just that the game manufacturers were drawing a line in the sand to say “we can’t make any guarantees here”. 

Dear web professional, does this situation sound familiar?

Here is the typical rub for a web application:

• All users generate money. Wilfully removing support for those older browsers can be a hard sell.
• Old browsers cost an inordinate amount of time and money to support.
• Factoring in older browsers certainly stifles the speed at which new features can be built and deployed.

Summary

There can be clear fiscal reasons to support ‘ailing’ browsers, just as there was fiscal reasons for game manufacturers to support all PC hardware. However, as lovely as that sounds, the reality is perhaps that any sufficiently complicated application, served to a continuum and that requires constant support and continuous iteration needs to become comfortable with the notion of minimum system requirements. It’s not that we aren’t doing this already; few of us could say, hand-on-heart we develop with a completely lowest to highest progressive enhancement approach. However, perhaps phrasing this approach in this manner can help define the mindset.

The web app might run in environments below the ‘minimum system requirements’ threshold, but in order to keep pushing a product forward for the majority, it just can’t, or rather won’t be fully supported there.