Tag Archives: web

The Open Web, the Closed Web and the Live Web

So back in March, Brendan Eich of Mozilla wrote post titled “The Open Web and its Adversaries“. His definition of open seems to rest on this:

a web whose major content formats are not controlled by a single vendor

A goal which I agree with, and the basis for my series of Flex posts, which he also referenced. So far, so good. As he continued, I got confused. He asks us to:

Consider just the open standards that make up the major web content languages: HTML, CSS, DOM, JS. These mix in powerful ways that do not have correspondences in something like a Flash SWF.

I agree with his assessment of the powerful ways in which these technologies combine. But much of what he finds laudable are technical properties — they don’t derive from the fact that these are open standards. It’s just a fortunate (or perhaps, designed) outcome that those are the technologies that are combined in a browser. After all Java, C#, and even C++ have been standardized (well at least if you believe that the JCP is standards body), so being an open standard technology is not a guarantee that you’ll have the properties that make the web “alive” according to Brendan. It seemed like what was really being discussed was the “live web”, not the “open web”.

The place where I really got lost was when he started discussing the future of the open web,

Implicit in my writing is the assumption (conclusion, really) that browsers can adopt the necessary advanced rendering and faster virtual-machine programming language support that the “rich client platforms” boast (or promise in version 2.0). … There’s no technical reason this can’t be interoperably supported by other browsers in the near term.

There’s no technical reason, but there are plenty of political/business reasons. Every browser implements each of the open standards to a varying degree. They implement different versions of the specs. They implement each spec imperfectly. That translates into lots of debugging and testing when building an application atop the open web. I like the improvements that are likely to come in Firefox. The problem is that until many of those improvements appear (if ever) in Safari and IE, it will be hard to justify using those improvements, because it means writing multiple versions of the same code and then qualifying those versions. Contrary to Brendan’s assertion, big companies with armies of developers might have the resources to devote to all that additional work, but small development houses are the least able to tolerate that additional labor. Since Microsoft has an interest in advancing WPF/E, part of the Closed web, it’s hard to imagine that they will be motivated to improve IE quickly enough for innovative Live web features in Firefox and Safari to make a difference to application developers versus something like WPF/E or Flex. The risk to Microsoft is that instead of collecting those developers themselves, they lose them to Adobe.