The web is a living, breathing, ever-changing, interlinked, and evolving mass of documents, data, and applications. By its very nature, it is decentralised and immediate. The web, in all its chaotic beauty, is – and has always been – versionless. What version is Gmail at? Or Facebook? Do you know? Do you care? Does it matter? No.
Furthermore, any mechanism used to access a versionless resource like the web should itself be similarly versionless. Otherwise, you will get an impedance mismatch between the resource itself and its means of consumption. This simple truism led me to tweet the #oneversion #manifesto:
"#oneversion #manifesto My websites will only support the latest versions of browsers. It's the browser makers' duty to get users to upgrade."
So the web is versionless and yet we seem determined to scar it with the branding irons of numeric order for our own petty conveniences.
When Tim O'Reilly coined the term Web 2.0, for example, it worked as a rallying cry for developers to focus on web standards, open data, and APIs. That snapshot – however artificial it may have been – helped to define the ideological and practical shift away from the equally stereotypical snapshot that was the Wild West of Web 1.0: a post-apocalyptic wasteland littered with the casualties of the browser wars and riddled with the abuses of table-based layouts and the unfortunate spaghetti-soup tragedies of Perl/HTML/JavaScript code. But Web 2.0 never described the true state of the web at any given time. It was simply a convenient fiction that gave us a starting point to discuss where the web had been, where we thought it was, and where we thought it should be. But what did Web 2.0 really mean? There were as many definitions as there were marketers trying to sell you Web 2.0 solutions.
And that's the crux of the issue here: applying version numbers to something that is inherently versionless is meaningless beyond being a marketing exercise aimed at selling you the latest and greatest upgrade. As we are finally embracing the realisation that software is a service, even that use today is of dubious utility.
Version numbers, like milestones on highways that tell you how much longer you have to a destination, are useful when they occur at wide-enough apart intervals so as to present us with a gentle rhythm of progress. Software development today, however, comprises continuous improvements measured in inches not miles (or, ideally, in centimetres, not kilometres, like the rest of the civilised world). Version numbers are a relic from the dark ages of computing when software upgrade cycles spanned months (if not years) instead of days (if not hours) and distribution and upgrades meant shipping flimsy physical objects with data on them – not a seamless upgrade through the internet that the user need not even notice occurred.
Overwhelming users
Bombarding users with version number changes on a daily basis is a surefire way to overwhelm them (as evidenced by the version number overload experienced by Firefox users lately). Instead, since software evolves continuously, we can safely hide the version from the user – it is simply an implementation detail that has benefits to us as developers (for correlating bug reports to source code commits, for example). Hiding the version number gives users one less thing they have to worry about. And, whether we like it or not, this is how software will be understood in the future – as a constantly up-to-date (or else out-of-date) thing.
Web technologies – and the web itself – are in a constant (and accelerating) state of evolution. This is a difficult thing for humans to deal with. It's inherently chaotic, inherently unsafe, inherently volatile whereas we crave order, simplicity, and predictability to make sense of things. Our primitive noodles are more accustomed to things evolving slowly over decades than they are to a relentless onslaught of change. It is much easier to remunerate on the details of a photograph of a moving stream – however out of date the snapshot may be – than to adapt our discourse based on the current state of the ever-changing stream itself.
So it is understandable that the desire to version the unversionable is such a common one. Whether we append a numeric postfix to HTML or pontificate about what exactly Web 3.0 is/was/will be, we are simply trying to bring order to chaos. Our desire to version things is understandable, but it nonetheless remains a nonsensical and impractical effort given that the fluid, mutable, and malleable nature of the web – and software in general today – is at odds with the static nature of such way-markers.
Evolution
Given that web technologies evolve constantly and relentlessly, it is of utmost importance that the gateways to the web – the applications that we use to access the web – be equally versionless and evolve in a consistent manner. Any browser that cannot (or will not) keep pace, becomes not a gateway but a *gatekeeper*, artificially limiting access to the latest and greatest (and only) web. Such browsers are Harmful™ .
The last thing we, as developers, should do is reward such harmful behaviour on behalf of browser manufacturers. If we support such behaviour with our time, effort, and budgets, we are sending a dangerous message that the sort of business-as-usual attitude that resulted in the IE 6 fiasco is acceptable. We should instead be telling browser manufacturers, loudly and clearly, that such harmful behaviour is not acceptable and will not be tolerated.
The only major browser today that groks the versionless state of the web and conforms to its nature is Google Chrome. Look at the Chrome download page, do you see mention of a version number? Do you know which version of Chrome you're running? When was the last time you remember updating Chrome (it updates seamlessly without bothering you). Chrome has set the bar and it's up to the other browser manufacturers to follow suit or be left behind.
But why, exactly, is it harmful for browsers to be out of touch with the versionless character of the web? Surely, it has worked out all right so far. The web is doing better than ever before. Yes, but the times, they are a-changin'. The web does not exist in a vacuum – it has competition from both native platforms and other cross-platform technologies. Historically, the web has had key user experience advantages when compared to native platforms in three key areas: deployment/distribution, seamless upgrades, and universal access.
Publishing a website is as easy as pushing a "publish" button in your web authoring tool of choice and updating it is just as easy. Compare this with the complexity of publishing and distributing traditional software, which required factories to burn the software onto CDs, boxes to house them in, trucks to distribute them to retailers, and shelves to host them on (and although the process is easier with electronic distribution, it is still not as simple as pressing a single button).
Consuming a website is equally as easy (just type in a URL) when compared to the process involved in finding and consuming native software: the hassle of locating the software, downloading it, finding where you downloaded it, installing it, possibly having to install dependencies, finding where you installed it, and then running it, only to be told that there's a new upgrade to download and install. What a nightmare. And what a huge user experience advantage for the web. Not to mention that you can access a web application from practically any device and still have access to your data. You don't have to worry about copying your data over, carrying it with you on easily-lost peripherals, or syncing it.
However, these days, native apps are catching up.
Apps
App Stores are well on their way to making it effortless to find and install software and seamless updates (like the mechanism implemented in Chrome) make it effortless to always have the latest version of an app. At the same time, cloud-based solutions like iCloud give you seamless access to your data from different devices without making you worry about syncing. We always talk about the web catching up to native when the real symbol of our times is native catching up to the web. In order for the web to remain competitive, it must offer a better user experience for both end users and developers.
The web has also traditionally held a user experience advantage for developers when it comes to ease of authoring. But we have to temper that statement by qualifying it with "for certain types of web projects." What kind of web projects? The document-centric kind. We can think of web projects as lying on a wide continuum ranging from document-centric websites to behaviour-centric web applications. The web, from its earliest days, has made authoring document-centric websites easy. Heck, the "Hello, world!" example for the web is, simply, "Hello, world!" Simples. (Of course it's not valid HTML but you pop that baby into a text file with the .html suffix and shoot it up to a web server and it'll render in a user's browser when they access it.) The forgiving nature of the web was a key element in its success and one of the main reasons why it is so prevalent today. Any Jo with notepad could be, and probably has been at some point, a web developer. And that's a Good Thing™
But the web's user experience advantage for developers doesn't extend into the creation of behaviour-centric web applications. Authoring web applications that are heavily behaviour-centric is a whole different ballgame and involve orders of magnitude more complexity. Instead of mostly non-interactive documents, we are talking about massively non-linear, heavily-interactive applications. Applications that must go beyond maintaining presentational consistency across browsers and platforms to guaranteeing behavioural consistency also. If you think that implementing responsive design – which currently focuses mainly on presentational issues – is hard, try maintaining behavioural consistency across platforms and devices for a heavily behaviour-centric web app.
Now multiply the complexity involved in that task with having to support quirks in previous versions of multiple browsers and it suddenly becomes clear that the web, with the combined complexities of multiple platforms and multiple runtime (browser) versions, puts developers at a disadvantage when compared to certain native platforms. If we can remove some of that complexity, we can give the web a competitive leg up. Making sure that browser manufacturers make updates seamless in an effort to eliminate version fragmentation is a big part of helping make this happen. And this is why browser manufacturers who – either though incompetence or malice – do not implement seamless upgrades in their browsers are harming the web.
This is also why my websites will support only the latest versions of the major web browsers and why yours should do so too.
This does not mean to say, as some have interpreted it, "do not use progressive enhancement". By all means, if you have a document-centric website (eg a newspaper site as opposed to a behaviour-centric web application like a Photoshop-clone) and your budget permits it, implement progressive enhancement. Your budget and timescales permitting, go beyond that and implement a responsive design that works across a variety of devices. Then exceed even that and optimise your site to better support features like touch-based input.
Heck, if you really want to make your site shine, go beyond even that and (as a last step) optimise for specific devices to add that crucial final 5 per cent of polish to your user experience. But don't worry if your site doesn't run in all its whizz-bang-glory on IE 8. Or Firefox 7. Or Chrome 14. That's not your job. It's the browser manufacturers' jobs to build their software so that updates are seamless. And it's up to all of us to educate mere mortals to leave behind the ball-and-chain of a version numbers.
In this day and age, the concept of version numbers is, itself, outdated. A thing is either the latest version or it is out of date. The web is versionless. Browsers must be versionless too if they are to remain gateways to the web, instead of becoming gatekeepers that limit our access to web experiences and harm the web in relation to competing platforms.
Progress doesn't happen by wasting time today on supporting the things of yesterday when we could be spending that time making the things of tomorrow even more awesome.
Developer and conference organiser John Allsopp doesn't quite agree with Aral. Read his response, Develop for as many users as possible, and let us know what you think below, in the comments.
