The Changing Web Platform Landscape: More Fragmentation?

The Web is an ever changing place and the first half of the year has been rich in surprises, big announcements and industry shifts! A diversity of implementations is good for many reasons we will discuss. But a more fragmented web could be the price to pay. Will it be the case?

About Implementation diversity

A few weeks ago Opera announced they were stopping work on their Presto rendering engine and switching to Chromium. They have already started contributing code to the project. Then, earlier this month, Google announced the Blink project, essentially a new fork of WebKit. And now Opera announced they will contribute to Blink!

Reactions were interesting as we went from WebKit monopoly concerns to worries about web platform fragmentation in a matter of weeks. Quite a 180 degrees turn!

At Adobe, we actively contribute to Web standards and browser implementations (historically mostly WebKit and Chromium, even though we also make some contributions to Gecko). As such we are delighted to see Opera join one of the projects we contribute to. Their considerable web expertise will undoubtedly be an asset.

There was some debate before the Blink announcement about whether or not we were heading for a WebKit monoculture: a web where content can be written with the assumption a WebKit-based engine is most likely to render it. While WebKit browsers share much core layout code they also differ in many ways at runtime: different JavaScript engines and graphics libraries, even different sets of features enabled by default. This makes it difficult in practice to write once for WebKit and run everywhere.

So we were not too concerned about a WebKit monoculture. But…

… there was a but in that view. The web is bigger than any one of its leading browser implementations and too important to be limited to a single code base even if that implementation has variations. The web is even growing to be an OS platform (e.g., ChromeOS, FirefoxOS, the new Windows Runtime), the core technology behind packaged applications (like PhoneGap applications). And ongoing innovation across HTML, JavaScript (in the TC-39 group at ECMA) and CSS needs validation, testing, consolidation.

As Brendan Eich says in his blog about “why Mozilla matters”:

“The web needs multiple implementations of its evolving standards to keep them interoperable.”

I believe this tenet to be central to delivering on the promise of the Open Web. A single implementation does not establish a standard. The W3C process even recommends two implementations in order for a specification to reach completion.

The Web needs Mozilla’s Gecko and Microsoft’s Trident engines to nurture an open, innovative environment. Historically, both companies have done a lot for the Web  – think of XHR which Microsoft invented (among other key contributions) or WOFF from Mozilla –  and they continue to innovate:  Microsoft and Mozilla co-edit the CSS Grid specification, which provides much needed and improved layout flexibility to CSS.

I trust that the addition of Blink will strengthen an already healthy browser competition. Over time, the Blink code base will diverge from WebKit’s but no harm to the web occurs if both engines implement the same features in different ways. Only significantly different feature sets could result in harmful fragmentation. Making sure that WebKit, Blink and other browser engines interoperate is more important than it has ever been.

About testing, fragmentation and experimental features

As the founders of Test the Web Forward, we have come to appreciate the mutually reinforcing benefits multiple independent implementations bring to standards. Historically, testing has been key to the success of web standards. For example, the focused testing effort on CSS 2.1 has shaped that specification and its implementations in the corner stone CSS has become. A single implementation would leave a lot of stones unturned.

It should also be noted that the Blink policy regarding prefixes is really good for standards and compatibility across browsers:  draft standard features can become truly experimental features that will not be used (and abused) in production. This should help avoid browser compatibility headaches down the line and I hope this example will be followed by all browsers.

About fragmentation and Adobe’s contributions

In this new web platform landscape, what about Adobe’s contributions to open source browsers? What impact does additional browser fragmentation has on Adobe’s efforts?

Adobe contributes to standards in open browser implementations for many reasons.

One of them is that our new generation Edge tools use a ‘web design surface’. For well over a year now, we have chosen to use the Chromium Embeded Framework (CEF) to provide this ‘web design surface’. So naturally, we will contribute to Blink since it is now the core engine that powers CEF.

Another reason for contributing to open browsers is to accelerate the availability of new features on the web. This is why we collaborate with Mozilla on a number of standards and contribute code to Gecko (like this patch on masking for canvas). And this is why we will also contribute to WebKit, in addition to Blink, now that the two are separate projects.

An open, innovative and tested web!

So yes, I think it is good to have multiple browser engines and Blink is a welcome addition to the web platform landscape. It is bringing a healthy diversity that I hope will help keep the web open and foster innovation as long as all browsers strive to implement ‘the same web’.

And this is where testing efforts are key to achieving diversity without fragmentation. I hope testing activities (of browser code of course, but of standard test suites as well and major initiatives that the W3C is driving) will be a major focus for all the browser vendors going forward, in particular for Google with its new Blink implementation.

HTML 5 and Flash – A reality check

If you are reading this, you are probably a fairly technical person that understands the complexities of HTML, JavaScript, CSS, Flash, and other web technologies.  Like me, you probably have more than one web browser installed on your systems and enjoy the very latest technology every day.  I bet you have already viewed the latest [...]

Are you Bored With Adobe AIR?

Sarah Perez over at ReadWriteWeb has a post up titled Are you Over AIR Applications in which she talks about her change in perspective on the value of AIR and how much benefit desktop applications provide over browser applications. It’s a pretty good post, and one that I hope drives some traffic and conversation, especially as we’re hearing more about things like Chrome, Firefox 3.5, and the Chrome OS.

For much of the past couple of years web applications were trying to mimic basic aspects like functionality and look and feel of desktop applications. That drove the movement towards RIAs and the shift made it painfully obvious that the browser in its current form wasn’t up to snuff. So more and more energy went into improving the browser so that web applications could compete against their entrenched desktop counterparts. We’re finally seeing releases from all that work. Firefox 3.5 looks to incorporate HTML5’s support for offline mode. Chrome was written from scratch because Google felt, basically, that the current browsers weren’t powerful enough to run complex HTML/Javascript based web applications. So what benefits does AIR have in this world? I agree that desktop applications as we know them are falling by the wayside, but AIR still has a few areas I think make it shine.

Web Technologies
One of the best parts of AIR is that it uses web technologies like HTML/Javascript and Flash. Web developers are a creative and innovative bunch. I’d argue that one of the main reasons Web 2.0 exploded the way it did was because web developers took to their destiny as the drivers of technology. Web development is relatively easy to learn but complex enough to keep the challenges coming. It’s also more productive than traditional languages because it’s both faster and it’s cross-platform. The strength of web development is a strength of AIR. Look at the first wave of a game-changing technology like Twitter. Almost all AIR applications. That’s because web technologies are easy and AIR made it very simple to quickly create a new kind of experience for a new kind of service. Tweetdeck and Twhirl got a first mover advantage and reaped the rewards. The development speed that the web allows for shouldn’t be discounted.

Notifications and Files
I think notifications, or the “toast” windows that you can pop up in AIR are more and more important as the web gets more real time. People want the firehose and they want it as soon as they can get it. Another area that I think AIR hasn’t been used enough for are filetypes. It’s incredibly powerful to be able to not only create items on the file system but to associate those with your applications. So far there hasn’t been need to create things like a .twitter file extension, but the next generation of web services may see big benefits from users being able to create those extensions. And of course with the file system you get some inherent benefits like the ability to tie into Spotlight or other desktop searches.

Ultimately I think both the browser and a more web-centric approach to desktop applications will succeed. The cross platform benefits, the improved developer productivity, and the close integration with web services are going to be instrumental in driving adoption for web applications both inside and outside of the browser. I hope AIR continues to do well and help drive innovation for web applications on the desktop. Seeing technologies like Google Gears and Titanium’s Appcelerator prove to me that the space is still growing and that we’ve got a lot of demand for a blend of web and desktop. And we’ve got a lot of enhancements coming up in the next version of AIR, so we’re not standing still. Stay tuned.