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” .

Maybe there’s something in the water, as in the past couple of weeks, Faruk Ateş, and Jeremy Keith have both ruminated a little on this topic.

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 embed tag, and on and on. Whole languages like JavaScript, and complex architectures like the DOM. In many ways this was good. The Web increased in sophistication, and gained vital features quickly.

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 quite incredibly, if you’re familiar with the nature of the Web in the late 1990s with Netscape’s JSSS (JavaScript StyleSheets) versus CSS, incompatible undocumented DOMs, JavaScript versus JScript and VBScript, a bitter battle between Netscape Communications and Microsoft, we created a Web that wasn’t balkanized, by standardizing HTML, and CSS, and JavaScript, and the DOM, and selling far from enthusiastic developers on the benefits of this Web. It was a remarkable achievement, by so many people, working at companies like Microsoft, Apple and Mozilla and Google, by many who worked largely thanklessly to standardize these technologies, by those who advocated for, and educated their fellow developers about a standards-based web. Some have become well known, most worked hard for little outward reward. But all loosely connected by a sense that this was how the Web should be.

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 JavaScript with languages that compile to it.

We fragmented HTML with any number of templating systems.

We fragmented CSS with preprocessors like Sass and LESS.

Oh what have we done?

This is not to say each in and of themselves is totally bad. Far from it. Each of these technologies and innovations does address developer pain. Many point the way forward for future standard web technologies. But collectively, we’ve taken a relatively simple set of self contained technologies—HTML, CSS, JavaScript, the DOM—each with their own well defined roles, each relatively straight forward to learn, and start working with, and we’ve created a chaotic lanscape of competing technologies, many of which do exactly the same thing, in slightly different though incompatible ways.

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.

Learnability

Having a common set of technologies for front end development made learning to develop for the Web easier. Finding tutorials on, knowledgable experts in, and meetups dedicated to these technologies was relatively straightforward. The roadmap for acquiring skills and knowledge was relatively straightforward. You could pick up some HTML, and CSS, and build something useful. Over time you could increase your knowledge of these, and add an understanding of JavaScript and DOM to extend your capabilities. There was a network effect to having as large a group of developers sharing common languages and concepts.

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.

Maintainability

Having a common set of technologies makes maintaining existing code bases more straightforward. The underlying technologies of HTML, CSS, JavaScript and the DOM are stable over long periods of time, unlike most frameworks, libraries, languages and preprocessors (not to mention the toolsets and languages these often rely on). Will the framework your service relies on be maintained 5 years from now? And by relying on less widely used technologies, the number of developers available to maintain a codebase diminishes significantly.

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.

Interoperability

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.

Longevity

If you’ve spent years developing knowledge and expertise in Flash or Silverlight/WPF, this is increasingly useless. The same will happen for jQuery, as it has for other, once seemingly dominant JavaScript libraries and Frameworks such as Prototype. It will happen to all the libraries and frameworks we invest in so heavily today, AngularJS, Bootstrap, you name it. Very few technologies last years, let alone decades. As someone investing a reasonable amount of my time and effort in learning a technology, I’d be concerned that this effort was well placed.

What’s to be done?

jQuery, Backbone, AngularJS, CoffeeScript, Bootstrap, Sass, LESS (just to name some of the most popular frameworks, libraries, languages and preprocessors we’ve developed over the last few years to address challenges we’ve identified as we attempt to make the Web do more and more complex things, not to call out anyone in particular) are sophisticated, powerful technologies, well entrenched in a great many workflows, used by thousands, tens of thousands, or more. They aren’t going away. And following them will come others. Perhaps the slow submersion of the underlying technologies, HTML, CSS, DOM, JavaScript is inevitable. After all, few if any developers write assembler, let alone machine code any more. But, as Anil Dash wrote about the other Web we lost “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

W3C Goals and Operating Principles, their emphasis

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.