The Web could be heading for another dark age

Right now is a very exciting time for the Web as things are changing incredibly fast. Right now is also a very dangerous time for the Web as things are changing incredibly fast. We’re almost back to the early days of Netscape versus Internet Explorer. I’m not talking 4.0 here folks, I’m talking 3.0.

For the third generation of browsers, there was a lot going on, too. Netscape had recently invented the concept of cookies and JavaScript. Microsoft countered with VBScript. Both were fighting for control over the future of HTML, resulting in proprietary elements such as <blink/> and <marquee/> being implemented and several more like the <math/> and <ruby/> elements being suggested. Changes were being submitted to the HTML specification at a dizzying pace. Browsers then started implementing things that they assumed would be accepted and ultimately become part of the spec. Basically, they placed bets on what would happen as intellectuals argued the future of the Web.

When Internet Explorer finally pulled ahead and ultimately destroyed Netscape (which was still clinging to thoughts of JavaScript Style Sheets for styling pages among other missteps), we moaned and groaned about how horrible a Microsoft-dominated Web would be. But, as Crockford says, this was just the stabilizing force that the Web needed. This long period of inaction let developers become familiar with the development environment and led to the emergence of techniques such as Ajax. Then the browser market heated up again.

At present, we have several specs currently being worked on: Selectors API, HTML 5, and CSS 3. All of them show some level of promise, but all of them also show that we could be heading into another dark age. Browser vendors are well-represented on the working groups and dominate the discussion and decision phases of the draft process. The specifications are incomplete and some parts seem to have not been thought through completely. Recommendations for certain features are inserted without any background information as to the problem that the feature is solving. It sometimes makes me wonder if the people primarily responsible have done any serious web development recently.

Making matters worse, browsers are started to implement these ill-defined and unfinished specs, leaving room that their implementation will become incompatible. Look at what happened to Firefox and its key events implementation. DOM Level 2 originally had key events in an early draft, so Mozilla went ahead and implemented it. When the specification was finalized, key events were removed and only reintroduced in DOM Level 3, which leaves Firefox with an incompatible implementation. Already, browsers are implementing the Selectors API, whose method names seem not only unnecessarily verbose but nonsensical. Where did querySelector() come from? I could understand query(), but I don’t understand why “selector” is in there. All major browser vendors have already started implementing HTML 5, which is barely a newborn. There’s also some CSS 3 being implemented even though no progress has been made in years.

When browsers start implementing incomplete specifications, it’s the web developers that suffer. The market is flooded with incompatibilities because no one knows what a correct implementation is. Further, each browser tends to think that its proposal will be the accepted one and this stubborn view means that we’ll probably be left with incompatibilities for some time.

The best thing that can happen at this point is for browsers to stop implementing incomplete specs and for web developers to demand this. The Web was doing fine before the Selectors API, HTML 5, and CSS 3 started coming up in conversations. We can certainly wait a couple of years for things to solidify. I’d also like to see independent developers get called in for formal reviews of the specs as they’re being developed. I’m not talking about more people from Microsoft or Opera or Apple, I’m talking about people who will give unbiased opinions that are based on personal experience. Specs should be fulfilling developer needs more than corporate needs, and I’m really afraid that’s not the case now.

But hey, I could be wrong. Things may end up just fine. But I also could be right, and though I hope I’m not, there could be dark days ahead for the Web.


  1. Richard York

    Wow, I couldn't disagree more. The stagnation of the web was an awful period, and I personally still feel quite a bit of bitterness towards Microsoft for causing it.

    I'd rather browser maintainers implement an incomplete spec than no spec at all. I think what many people tend to forget is that specifications happen not just from bureaucracy of the W3C's committees, but from real-world implementation and use. If standards were never defined from actual use, we'd have no standards because there would always be some feature that needed to be added, or someone who disagreed.

    I don't pine for the days of IE vs. Netscape, by any stretch of the imagination, but then again I don't think it'll ever get that bad again.

    Ah, the naming of the Selectors API... I don't like the names either, but speaking as someone who followed the naming debate closely, no one could agree on them at any point in the process. If you read Anne van Kesteren's or Lachlan Hunt's blogs, or the relevant W3C mailing lists, you'll see that there was already a very large, ego-laden epic battle over the names used in the API with variations ranging from $() to getElementBySelector().

    In the end, personally, I'd rather have the spec implemented and it possibly change later, than no spec at all. Because now that we have querySelector()/querySelectorAll() in both WebKit and IE8, that's at least one more tool that we can use, even if you need a JavaScript library to support it in the others. In Webkit, at least, it makes that sort of querying loads faster, I'll reserve judgement of IE8, it's dog slow, but it's a beta.

    And I think it's even more important to note that since Microsoft and Apple have both implemented and de facto agreed on that particular API, that it's pretty likely Mozilla and Opera will follow suit. Of course, in IE8 we don't get CSS3 selectors in the selectors API.... but c'est la vie, a task for a library is born.

    But I fail to see why your outlook is so bleak. HTML5, for example, builds on and documents the web of today, Chris Wilson is the chair, the current draft came from Mozilla, Opera, and Apple's collaboration on the WHATWG... while I can see some temptation on the part of Microsoft to diverge, divide and conqueror like they did in the old days, I personally think it would only lead to them hemorrhaging more users and creating more angst against them in the development community. And I can't wait to see more CSS3 implemented! Multiple backgrounds, borders, etc. No longer will I have to create nine separate elements for some simple aesthetic effect.

    Think more positively man!

  2. Nicholas C. Zakas

    @Richard - I did say I could be wrong. :)

    I'm not sure you can argue that the stagnation of the Web was a bad thing...look at all the innovation that came out of it. Developers can't really start innovating until there's a stable platform upon which to build. Microsoft provided that (though perhaps not in the most friendly way).

    Your point about the Selectors API naming is exactly why I'm afraid for the future. When ego gets in the way of innovation, no one wins. And if you think that battle will only happen around that API, you're wrong. It continues on around almost all specs because it's just the same people going round and round.

    The parties involves in these specs scare me to death. Everyone has their own agenda for their own company. Just look at the ECMAScript 4 debacle. Too many cooks ruin the pot.

    Then again, I did say it could go either way. I hope it turns out well but it could also turn out badly.

  3. José Jeria

    Anne's van Kesteren blog entry on IE 8 is quite interesting:

    Especially the part where he writes that Microsoft has extended their HTML 5 implementations with extra functionality that has not even been communicated to the W3C Working Group.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.