The (other) Web we lost
TL;DR; In the aftermath of the Browser Wars, the W3C and developer groups like the Web Standards Project worked long and hard to rebuild a unified, un-fragmented Web. But these last few years, we developers have gone and re-fragmented it all over again all by ourselves. Maybe we should think about what we are losing, before we lose this Web for good.
Just on a year ago, long time Web Industry figure Anil Dash wrote “The Web We Lost”, a lament for the earlier participatory, pre social-Web of blogging, before all our writing and photos and videos and thoughts and lives ended up in silos like Facebook and Twitter and Instagram and Youtube. It resonated with many, particularly those who had lived through those days (many of whom ironically went off to work at these very silos).
Particularly if this period of the Web, up until say the mid 2000s, predates your full-time Web use, you should take the time to read it (not just skim it). The Web really has changed in the last decade, and definitely not always for the best. Anil writes
We’ve lost key features that we used to rely on, and worse, we’ve abandoned core values that used to be fundamental to the web world
and observes that one reason he wrote the piece was
“for the people creating the next generation of social applications to learn a little bit of history, to know your shit”.
As it happens, for much of the last year, I too have been thinking about something I feel we’ve lost of an earlier web–though it’s something different, a much more constrained aspect of the Web. Something hidden from sight for almost all of the Web’s users. Its code. I think here too ‘we’ve abandoned core values that used to be fundamental to the web world’.
The Browser Wars
Anil speaks of the Web since around 2000, and how it has changed. But I am thinking back further, to the mid 1990s. The really early days of the Web. Now, almost all of us will have heard of the browser wars. When prodded as to what actually happened during these times, to explain what this war was about, most would reply that it was a time when Netscape and Microsoft fought to control the web, by making their browser dominant.
But how did they do try and do this? In a way,the browser wars really should be called the HTML wars, as in the earliest battles of this long war (initially fought more between Netscape, and its predecessor Mosaic, and numerous other browsers built by small teams, and individuals, both commercial and open source, before Internet Explorer even arrived) the battlefield (to really start straining the metaphor) was the language of HTML.
Back then there was no “standard” version of HTML. Instead, browsers introduced new language features with new browser versions. Features like
img and lists, and tables and frames, the
font tag, the
But, none of these features was initially standardized, none developed by a standards organization, and each of them was initially proprietary to the browser which first implemented them, before other browsers hurriedly reverse engineered them, and then implemented their own, typically at least somewhat incompatible version.
One thing we learned from this period is early often beats better (the
img ‘tag’, for example, proposed by Marc Andreesen, despite the concerns of Tim Berners-lee who favoured the more extensible embedding mechanism) won, and continues to haunt us in this responsive age. Decisions we make when it comes to the architecture of the Web can have a very long half-life, and so need to be made carefully.
It’s commonplace for Web developers today to lament the, let’s face it increasingly trivial, inconsistencies between browsers as a huge pain point in Web development. But imagine a landscape where developers rushed to implement sites using the very latest, just implemented, poorly documented features with every new browser release?
It was this chaotic environment which saw the formation of the W3C, whose role, still often misunderstood, was, and remains, to bring major stakeholders together, among these browser developers, to standardize these innovations. A little later, Web developers felt the need to advocate for the better adoption of these emerging standards, and so was born the Web Standards Project (which ironically earlier this year declared “Our Work Here is Done”. Why ironically? We’ll see in a moment.)
But, I think we’ve lost sight of what the Browser Wars, and the subsequent foundation of the W3C and Web Standards Project were about — avoiding the “Balkanization” of the Web. We knew that the importance of the Web was its universality, its interoperability. And we knew that was at risk, with the web fragmented by browsers.
And then, little by little, like the apocryphal frog boiling to death so slowly it didn’t notice until too late, we threw it away.
- We allowed, encouraged, embraced the fragmentation of the DOM with libraries and frameworks. Each with a slightly different way to access attributes, or add elements, or traverse the DOM.
- We fragmented HTML with any number of templating systems.
- We fragmented CSS with preprocessors like Sass and LESS.
Oh what have we done?
And along the way we’ve introduced dependencies on other languages and environments because for many of these technologies, we’ve also introduced a build stage in our workflow, something the Web previously didn’t have.
What have we gained?
Arguably developers are more productive now. Perhaps we’ve made our lives easier during the initial development phase of our projects. Though I doubt there’s any more than anecdotal evidence to support this belief. Trust me, it’s a common place argument for all new development technologies that they make developers more productive. You’ve read some of the literature on that haven’t you (remember Dash admonishing us to ‘know [our] shit’)? And Software Engineers learned long ago that only a relatively small percentage of the overall cost of a system is in its initial development. Maintenance, over years, and even decades is where a very sizeable percentage of all system costs occur (yes, there is a lot of literature on this too).
But what have we lost?
Once upon a time, what made developing for the Web different from most other development was that we all spoke a common language, a Koine, a lingua franca. Compare this with for example developing for Windows, the single largest platform for many years, where a myriad of languages, frameworks and development environments sit on top of the underlying Windows API. This commonality brought with it a number of distinct benefits, among them, making Web technologies easier to learn, and making what we build with them more maintainable. And it helped ensure the long term viability of your knowledge and expertise as a web developer.
Do we honestly want to diminish this network effect by fragmenting the technologies of the web, by creating silos of expertise, with little by way of a common language? We should at least be aware of this potential consequence of our choices. Aware of not just what we (typically as individuals) might gain from our choices, but what we collectively, what the Web, may lose.
Traditionally, more than half of the cost of a complex system has come during its maintenance phase, and while on the Web we’ve been more likely to throw out and start all over again than traditional software projects, as what we build for the Web becomes increasingly more complex, and mission critical, the maintenance phase of projects will become increasingly long and costly. And again, it’s pretty well understood that maintainability has a lot more to do with the ability of disparate developers to understand and reason about a code base over a long period of time than it does with ease of using find and replace.
One of the core principles of the Web is “interoperability”. While this specifically addresses the concern that “computer languages and protocols … avoid the market fragmentation of the past”, I’d argue that fragmentation should not only a concern when it comes to the systems our code runs on. We should also be concerned about fragmenting the community of Web developers. The fewer developers with a working knowledge of a technology, the less interoperable that technology ultimately is.
There’s also the issue of how interoperable these various technologies are with one another. Say you like the way Sass implements variables, but also want LESS’s @debug feature (to give one of potentially countless examples)? You need all of LESS, and all of Sass, and probably a mess of frigging around. The monolithic approach of so many Web ‘innovations’ has a significant impact on how interoperable they are with one another.
What’s to be done?
“we’ve abandoned core values that used to be fundamental to the web world”, and I think that’s true in terms of the code we write as well.
But just what might these core values be? That’s not hard to explain, they’re in fact explicitly outlined by the W3C (once again, Anil’s words
“learn a little bit of history, to know your shit”).
[The] W3C aims for technical excellence but is well aware that what we know and need today may be insufficient to solve tomorrow’s problems. We therefore strive to build a Web that can easily evolve into an even better Web, without disrupting what already works. The principles of simplicity, modularity, compatibility, and extensibility guide all of our designs
Are these principles of simplicity, modularity, compatibility, and extensibility guiding developers when they design and implement new languages? Frameworks? Preprocessors? Certainly in many cases they are. This is particularly true of pollyfills, and ‘prollyfills’. These don’t aim to ‘boil the ocean’ byproviding a huge array of functionality, but rather, follow the ‘small pieces loosely joined’ model. They do one thing, and do it well.
But in many cases, our solutions aren’t modular, or simple, or compatible (particularly with one another). In fact I’d argue this is the very heart of the issue. Rather than address a specific pain point in a simple, modular, interoperable way, our solutions often become increasingly complex, ad hoc agglomerations of solutions to all kinds of problems. Here for example is what the designers of the CSS pre-processor Sass have to say about the design principles for Sass
there’s no formal process for how we decide to add new features to Sass. Good ideas can come from anyone from anywhere and we’re happy to consider them from the mailing list, IRC, twitter, blog posts, other css compilers, or any other source
which rather calls to mind the Homer
Small pieces loosely joined
In 2002, one of the Web’s pioneers David Weinberger (among other things, co-author of the Cluetrain Manifesto) wrote “small pieces, loosely joined”, a way of thinking about what makes the Web different. I’ve long thought it applies well to the technologies of the Web, and should guide us as we build for the Web, whether it’s our own sites, those for our clients or employers, or the very technologies that move the Web forward.
If each time we came to solve a problem we thought “how small a problem can I solve”, or even “what really is the problem here”, and then solve that in a way that is as modular, compatible, and extensible as possible, we’d be going a long way toward taming the explosion of complexity we’ve seen over the last half a decade or so, and to returning at least in part to the other Web we lost.
Perhaps this Web simple had to grow up, to meet the challenges of the ever more complex artefacts we’re building. When the Web was about documents and sites, perhaps we could be simple, but in an age of Apps that’s a luxury we can’t afford. Perhaps the technical underpinnings of all platforms of necessity fragment over time.
But, before we lose this Web for good, I think we owe it to that Web to really understand it, what makes it tick. And when we make technical, architectural choices about what the Web looks like, we don’t just focus on what we (as individuals) gain, but what costs there are to this Web as well.