A Web for the Next Century

The Web Platform
Chapter 1.

1. In the beginning, Tim created the Web.
2: And the platform was without form, and void; and confusion was upon the face of the Internet. And the mind of Tim moved upon the face of the problem.
3: And Tim said, Let there be a new protocol: and there was HTTP.
4: And Tim saw the protocol, that it was good: and he divided the network by domains and subdomains.
5: And he called the network the World Wide Web.
6: And Tim said, Let there be a browser for viewing pages delivered by this Web that they might be viewed.
7. And it was so.
8: And Tim separated the structure of the content from its style.
9: And the structured content he called HTML and the means of styling he called CSS. And he saw that it was good.
10. And Tim said, let us describe this structured content in the form of a tree and make it scriptable, and it was so.
11. And from the dust of the Interwebs were created developers, whom he gave dominion over the platform.

If you’ve read any of the numerous articles about The Extensible Web or heard about it in conference presentations, or seen The Extensible Web Manifesto you’ve likely seen (or heard) three phrases repeated: “Explain the magic,” “fundamental primitives” and “evolution of the platform”. I thought it might be worth (another) piece explaining why I think these are at the heart of it all…

For thousands of years the commonly accepted answer to the question ”where did dolphins come from” (or sharks or giraffes or people) was essentially that they were specially created in their current form, by a deity as part of a complex and perfect plan.  Almost all cultures had some kind of creation myth to explain the complex, high level things they couldn’t understand.

Turns out that this very simplified view was wrong (as is much of the cute creation myth I’ve created for the Web Platform) and I’d like to use this metaphor a bit to explain…

Creation and Evolution: Concrete and Abstract

It’s certainly clear that Sir Tim’s particular mix of ideas became the dominant paradigm:  We don’t spend a lot of time talking about SGML or Gopher.

It seems straightforward enough to think of the mix of ideas that made up the original Web as being evolutionary raw materials and to think of users as providing some kind of fitness function in which it became the dominant species/paradigm, but that is is a pretty abstract thing and misses a subtle, but I think important distinction.

The Web Platform/Web browsers are not an idea, they are now a concrete thing.  The initial creation of the Web was act of special creation – engineering that introduced not just new ideas, but new software and infrastructure.  The Web is probably the most grand effort in the history of mankind – browsers as a technology outstrip any operating system or virtual machine in terms of ubiquity and they  are increasingly capable systems.  There are many new systems with concrete ideas to supplant the Web browser and replace it with something new.  People are asking themselves:  Is it even possible  for the Web to hang on?  Replacing it is no easy task: technically or socially – This is a huge advantage to the Web.  So how do we make it thrive?  Not just today, but years from now?

Some more history…

In Tim’s original creation, HTTP supported only GET; In HTML there were no forms, no images, no separate idea of style.  There was no DOM or async requests – as – indeed there was no script. Style was a pretty loosely defined thing – there wasn’t much of it – and CSS wasn’t a thing.  There was just GET me that very simple HTML document markup which is mediocre at displaying text – and display it – when I give you a URL and make sure there is this special concept of a “link”.

This is at the heart of what we have today, but it is not nearly all of it:  What we have today has become an advanced Platform – so how did we get here?  Interestingly, there are two roads we’ve followed at different times – and it is worth contrasting them.

In some cases, we’ve gone off and created entirely new high level ideas like CSS or AppCache which were, well, magic.  That is, they did very, very complex things and provided a high-level, declarative API which was highly designed to solve very specific use-cases.  And at other times (like DOM, XMLHttpRequest and CSSOM) we have explained some of the underlying magic by taking some of those high-level APIs and providing some imperative APIs.

Looking at those lists, it seems to me that were it not for those small efforts to explain some of the magic, the Web would already be lost by now.

Creating a Platform for the Next 100 Years

The real strength of life itself is derived from the fact that it is not specifically designed to perfectly fill a very niche, but because complex pressures a high level judge relatively minor variance at a low level and this simple process inevitably yields the spread of things that are highly adaptive and able to survive changes in the complex pressures.

Sir Tim Berners-Lee couldn’t have forseen iPhones and Retina displays, and had he been able to account for them in his original designs, the environment itself (that is, users who choose to use or author for the Web) would likely have rejected it.   Such are the complex pressures changing our system and we could learn something from nature and from the history of technology here:  Perfectly designed things are often not the same as “really widely used” things and either can be really inflexible to change.   

Explaining the magic means digging away at the capabilities that underly this amazing system and describing their relationships to one another to add adaptability (extensibility).   At the bottom are a number of necessary and fundamental primitives that only the platform (the browser, generally) can provide.  When we think about adding something new, let’s try to explain it “all the way down” until we reach a fundamental primitive and then work up.

All of this allows for small mutations – new things which can compete for a niche in the very real world – and unlike academic and closed committees can help create new, high-level abstractions based on real, verified shared need and acceptance and shared understanding.  In other words, we will have a Platform which, like life itself, is highly adaptive and able to survive complex changes in pressures and last beyond any of our lifetimes.

This is Hurting Us All: It’s time to stop…

The status quo with regard to how users receive browser upgrades has changed dramatically in the last few years – modern browsers are now evergreen, they are never significantly out of date with regard to standards support (generally a matter of weeks), and ones that are not (generally mobile) are statistically never more than a year or so back.  This means that in 2013 we can write software using standards and APIs created in, say, 2012 instead of 2000 – but by and large we don’t – and that is hurting us all.

It’s not about a specific version…

Historically, a large number of users of got their browser upgraded only as a side-effect of purchasing a new computer.  Internet Explorer 6 was released toward the end of 2001 – well over a decade ago – pre-9/11/2001.  It wasn’t fully compliant with the standards of the day – and for five years, nothing much happened in IE land, so anyone who bought a new machine until about 2007 was still getting IE6 for the first time.  This meant that until very recently many businesses and Web authors still supported IE6 – and it was only with active campaigning that we were finally able to put a nail in that coffin.

So, now we’re all good – right?  Wrong.

A great number of companies have followed their traditional policies and took this to mean that they must now offer support back to IE7, some have even jumped to IE8 which seems like a quantum leap in version progress, but…  If you write Web sites or run a company that does, this is now hurting us all: it’s time to stop.  

The problem is in the gaps not the versions…

A small chunk of what the gaps in support between IE.old and evergreen browsers Let me add some data and visuals to put this into perspective…   If you were to create a giant table of features/abilities in the Web Platform today in most evergreen and the vast majority of mobile browsers and compare them with the abilities of non-evergreen IE browsers, remove the features that have been in there for more than a decade and then zoom WAY out, you would see something like the image here (and then you’d have a lot of scrolling to do).  Rows represent features, the green columns on the left represent evergreen browsers and the red columns on the right represent IE10, 9, 8, 7, 6 (in that order).

If you want the actual dirty details and to see just how long my (incomplete) list of features really is, you can take a look at:

Now, if you really look at the data, both are slightly flawed, but the vast majority of the picture is crystal clear…

  • There are an ever increasing number of gaps in ability between evergreen browsers and old IE.  More importantly is where the gaps are: Many are some of the most powerful and important sorts of features to come to the Web in a really long time.
  •  We can’t wait years for these features because meanwhile the user/business expectations for features made possible by these APIs keep increasing.
  • Solutions/workarounds for missing features are non-standard.  They start getting bulky as you increase their number, they are less maintainable, require more code and testing (anecdotally, I have worked on a few small projects that spent almost as much time working out cross browser problems as the entire rest of the project).

How it hurts us all…

Directly, this is hurting you or your company because it means you spend a significant amount of time and money developing for and supporting browsers which are so far behind the curve – and the work you are doing is already out of date.

What’s more though, by supporting them you are effectively enabling these users to continue inadvertently bad behavior which is free to fix – and the longer they stay around, the more other companies follow suit.  You are creating a self-fulfilling prophecy:  My users won’t upgrade.

What can we do?

Luckily, this is actually a really solvable problem… All we have to do is get users to upgrade their silly browsers – and it’s free.

I propose that we set two dates as a community and do the following:

  • Try to get cooperation from major sites like we did for SOPA and make sections of the interwebs go semi-dark for those users (like we did for SOPA) on the first date – while we tell them about the second date (next bullet)
  • Upon the second date, we collectively stop serving them content and start serving them up 403’s (I’d propose July 4th – Independence Day in the US, but that doesn’t internationalize well).

I think there are a very small number of users who still don’t have high speed access, for those people, you could recommend them to Best-Buy where they can pick up a copy of Google Chrome on CD.  If you have other ideas, want to help coordinate a date, want to submit scripts that people can use to black out their site or even want to share another way that users can get disks by mail, leave a comment.

Clarification: I am not suggesting that the entire Web start serving 403 responses to anyone with an older version of IE here – I am suggesting that sites stop support/new development for those browsers.  Eventually, for some classes of sites, this will mean that their site is actually unusable (try using twitter or google plus with IE4, I haven’t, but I bet you won’t get far) – if that is the case, a 403 page asking users to upgrade is an entirely appropriate response which is actually better than a broken user experience.  This is about helping users to help us all. 

Our support of non-evergreen browsers is killing us all, let’s work together to spread the word and fix that pro-actively, as a community.

Thanks to Paul Irish and Cody Lindey for helping to hook me up with some data.