On July 25, 2011 Chris Jones and I, with help from Mike Shaver and Brendan Eich, for the first time publicly talked about our vision to build a smartphone based on the Web. The announcement didn’t come out of nowhere, and didn’t happen in isolation. Chris and I had been working together for Mozilla for a few years, but we didn’t get to spend a lot of time talking to each other since Chris doesn’t work in the same office. On a trip to Asia as part of the Firefox 4 launch campaign, we finally had the opportunity to catch up and we ended up talking a lot about what later became the guiding question and principle for Mozilla’s research group:

What can the Web NOT do? And if so, WHY NOT?

We identified a couple of use cases where the Web is intentionally not used today. We are both platform engineers at heart. We wrestle with bits and bytes and CPU and GPU cycles for a living and we understand the Web platform and the implementation thereof (in Mozilla’s case: Gecko) pretty well. For the life of us, we couldn’t figure out why in a few key areas the Web hasn’t progressed as much as elsewhere. Two particular areas we homed in on were plugins and mobile.

Plugins

If you ever had to work on a rendering engine, you probably hate plugins just as much as we do. Plugins are like a thorn in the Web’s side. They are difficult to render efficiently, binary compatibility requirements make the browser-side support code super ugly and hard to maintain, plugins leak memory, plugins can cause all sorts of security issues, and they generally hold back the development of the Web’s native capabilities. A good example of this is Flash: because the Web relied for over a decade on Flash to play back video, the VIDEO element didn’t really take off until pretty recently and some essential capabilities such as adaptive streaming are still missing from the Web stack. Chris and I both worked on the plugin support code in the Firefox, and we agreed that for the better of the Web, we really would like to DELETE that code. There is a large number of plugins out there, but realistically, only a handful matter, including Flash, Acrobat Reader (PDF), and maybe Silverlight (we included Silverlight back then, but by now Microsoft has totally given up on it, so I guess we can as well drop Silverlight from the list). We wondered why Flash and Acrobat Reader are implemented as native code plugins, instead of building the same functionality with HTML5/CSS and JavaScript, and since we didn’t have an answer for that question, we decided we should just build it and see what happens. We started with PDF first, because it seemed like less code to write until we can see whether performance and quality are comparable. A year later, Firefox is about to ship with the JavaScript-based PDF reader we started, so I think it’s safe to say that we found the answer to the question: the Web is ready to render PDF. We didn’t forget about Flash either. A few month later we started the Shumway project, which is still evolving, but might at least partially replace the role of Adobe’s native Flash player in Firefox eventually.

On Canvas and Dashed Lines

A lesser known part of the PDF.js project’s history is that the Web was actually NOT ready to render PDF when we started. We are using the CANVAS element to render PDF documents. We ran across a few loose ends and missing features. Infamously, we pretty quickly discovered that the CANVAS element couldn’t render dashed lines. It seems the spec authors just forgot to include this feature. We ran into this problem 4 days into implementing PDF.js because the first document we chose to render had some dashed lines in it. As it happens, Chris and I are both committers to the Mozilla code base, so Chris whipped up a prototype implementation in Firefox and we posted a proposed spec to the W3C mailing list. Two weeks later Firefox trunk (Nightly) could display dashed lines in the CANVAS element, and pretty soon thereafter a bug was filed for WebKit to add support as well (WebKit is used by Safari and Chrome, amongst others). This approach is the third part of the research group’s mission: Find out what the web can’t do, figure out why not, and FIX IT.

Standards vs Prototypes

The Web is so powerful because it’s not governed by committees and standards bodies. Instead, standards bodies like W3C merely help the Web avoid fragmentation by giving browser vendors a forum to coordinate and collaborate on jointly developed technology. To add dashed lines support, we didn’t have to convince a standards body. Instead, we added a prefixed prototype implementation to Firefox, and within a few months hundreds of millions of Firefox users could start using this feature. This was also the reason WebKit quickly decided to implement dashed lines support: competitive pressure. Firefox could do something WebKit-based browsers couldn’t. This is how the Web evolves. Someone finds a missing feature and implements a prototype for it, and if it’s a good feature, the rest of the browser vendors have little choice than to add support as well. The W3C’s role is to help browser vendors implement the feature in a compatible fashion across the different browser engines. The result is a pace of innovation that is unparalleled in technology history. Hundreds of millions of users had access to a feature after a few months of two engineers realizing that it was missing, and the rest of the Web adopted the same feature another few months later. Compare this to traditional governance by committee approaches such as the Java Community Process and the C++ standards committee where the pace of progress is measured in decades.

Beyond the Desktop

The second area we were interested in was Mobile. How come the Web is so ubiquitous on the desktop, but Mobile content (Apps) is implemented with proprietary native technology such as Java/Dalvik (Android) and ObjectiveC/Cocoa (iOS)? As with plugins, we didn’t have a technical explanation, and as with plugins, we did the same thing to find an answer: build it.

At the time of our first post about Boot 2 Gecko, which later became Firefox OS, Mozilla already had a Mobile product: Firefox for Android. It wasn’t particularly popular because it was pretty slow and memory hungry. We proposed a couple architectural changes to Firefox for Android, in particular abandoning our established XUL frontend toolkit in favor of a native Android UI. Mozilla’s mobile team did a heroic effort to turn the prototype we created into a full product within 6 months. Today, Firefox for Android is one of the most popular third party browsers for Android, and is faster and uses less memory than the native browser on most devices. In contrast to the often crappy browsing experience with the built-in browser, Firefox for Android is actually a pretty decent way to surf the Web on mobile. Yet most people still spend most of their time in native Apps. Why?

Mobile, the neglected red-headed stepchild

If you want to understand why the Web isn’t as popular on Mobile as on Desktop, just surf the Web on a phone: The Web totally blows on Mobile! Almost none of the device capabilities of a modern smartphone were available to the Web around the time we started talking about Boot 2 Gecko: making a phone call, SMS, bluetooth, NFC, proximity sensors, streaming camera access, etc. Name a device capability, and the Web didn’t support it back then. Browser vendors neglected to evolve the Web on Mobile with the same vigor as we did on the Desktop. No wonder content authors choose powerful native APIs instead of writing applications in HTML5!

The solution is pretty trivial and obvious: fix it. Mozilla started the WebAPI campaign as one of the first steps of the Boot 2 Gecko project. We have added dozens of new APIs to HTML5 to support mobile device capabilities, and many of these APIs have already been proposed as new W3C standards in various stages of progress, ranging from prototype specs all the way to final specs implemented across multiple browsers.

Why Mozilla matters

Our existing user-base of hundreds of millions of users gives Mozilla a tremendous amount of influence over Web technology, and this user-base is what enables us to push out new APIs and technologies. Any new device capability we add, we tend to add across all implementations of our browsers, ranging from Firefox OS devices (which are not in market yet), to Firefox Android (which has a ton of users) and Firefox Desktop (which a third of Internet-connected humans use). This gives us a loud voice in standards bodies, and we use that voice to aggressively push the boundaries of what can be done with the Web. Today, HTML5 is as powerful as native APIs, and within a year we have essentially closed the gap between the Web and native APIs when it comes to device capabilities.

Mozilla’s role in helping the Web succeed on Mobile is so critical, because we are driven by very different motives as the other three large browser vendors: Google, Apple and Microsoft. Mozilla is a public benefit non-profit foundation. Our goal is to promote innovation and choice on the Internet. We have no profit motive, and no services or products to sell. We want users to use our products, because they are better than the competition’s. And we want this choice to drive other vendors to advance their products to compete with us. This keeps us honest, and constantly pushes the envelope on Web technology.

Why the Web is going to win Mobile

Today, Firefox on Android is a powerful Web Browser and Web Runtime for Mobile applications. The Firefox Marketplace on Android offers a way for content authors to package HTML5 applications in an easily accessible marketplace that users can download applications from.

In 2013, jointly with our partners we will bring the first Firefox OS devices to market. These devices are completely built with the Web, and as Chris and I suspected a year and a half ago: there is really no technical reason why native technology should prevail on Mobile. In fact, Firefox OS and HTML5 apps are actually often much more CPU and memory efficient than proprietary alternatives such as Android and iOS. We are capitalizing on this fact and we are targeting in particular emerging markets such as Brazil with the first set of Firefox OS devices. The Web will bring smartphones to parts of the world where people can’t afford the expensive high-end smartphones Google, Apple and Microsoft like to compete over.

Only one question remains at this point: Is the Web really going to take off on Mobile? I think the best way to answer this is as follows: picture yourself being an executive at a company such as Facebook and someone pitches a new product to you: Facebook for Windows–a product designed for users to access Facebook from Windows desktops. In all likelihood, you would laugh that person out of the room. Obviously the Web is the way users access content such as Facebook on Desktop. Just the thought of using a native application for this purpose seems surreal and nonsensical. Now replace the word “Windows” with “iOS”, and suddenly everything is different. Obviously there is native Facebook for iOS.

In reality, in a world where the Mobile Web is as powerful as the Desktop Web, Facebook for iOS is just as surreal and nonsensical as Facebook for Windows is for the Desktop. Mozilla has been working tirelessly to create that world, and I think we are getting pretty close. Once we are there, native Mobile apps will be all but forgotten, just as Win32 applications are headed for extinction today.