The Web Platform as a Limitless Pool of Innovation, with Andreas Gal

1. Would you like to tell us why you think developers should be interested in the open web platform? What are its benefits compared to the traditional single-vendor stack for application development?

If you look at the Web, it has key differences to other technologies stack that could come against it and we could use an alternative. And even business has shown that there’s a really big risk if your Web technology is controlled by a single vendor. Take Adobe Flash, for example, a couple of days ago, Adobe announced that they will be winding down the mobile site for Adobe Flash and if you’re a programmer and you’ve developed platform application for technology stack, if you complete it, you’re at the mercy of the single vendor. And if that vendor decides to walk away from their stack, you’re left with activities with no environment to port and use it for server.

But even beyond that, this is just not limited to Adobe; other platforms like WebOS, for example, WebOS in theory HP and Palms, specifically. So, it was not really running on Web applications, it was running in HP and Palms applications. And it seems that happens basically that a vendor puts a piece of platform and if you’re targeting the platform as your applications and the vendor walks away, as HP did, then I think with your platform standing there. And these are certainly extreme cases and vendors do not all that often be completely walk away from their platform but you’re certainly exposing yourself to that risk. And it doesn’t have to be as extreme as like Adobe or HP even in a platform that’s working and vibrant, sounds like Android or iOS it’s like unlike that Google or Apple just tomorrow walk away from those platforms.

But at the very least, you have the risk of single vendor is controlling the direction of the platform. So, in case of Google, for example, they call Android as open source stack, right? But in reality, it’s neither open nor is there is open source around. So, on the source side, I think a day or two ago Google did will finally release the source code of latest installation of Android but that’s not really open.

So even if you, at some point, take the source and kind of through it over the fence so people can see it after you’ve shipped the device, it’s not really open in the sense that the technology behind Android is still driven by a single vendor, Google. And all the API, all the direction of the platform, the technologies, features available are solely driven by a single vendor. So, if you have used that, this kind of platform for an application, you’re at the mercy of a single vendor to drive the direction of the stack. And this is really where the marketing is different. That is an existing environment where we agree between browser vendors and the interested parties on public specification and standards and they are open and the entire standards processing process leading to that is open.

And then standard implement the multiple parties and this is where immediately there is some redundancy build-in so if some reason, some browser maker fails to decide to no longer make browsers for a certain device, there’s many other competing implementations that can jump in and this is exactly where it is not the case this Flash, for example, so is Adobe walking away from Flash and mobile, nobody can be easily jumped in and provide implementation.

There’s a couple of reasons for that. In the case of Flash, actually if you stand out Flash, it’s somewhat open. So, Adobe needs a piece of technology and at least document it how it works but nobody really ends up jumped in and made any competing stacks for that because, again, Adobe’s controlling direction of that stack, so you would never compete fairly on that stack. Adobe will lead and you would always lag. So, there’s no competitive market. And the Web is very different in the Web there’s very harsh competition for users which process they would like to use and often they compete with implementation-quality of features and innovative features. We’ll be discussing as in feature standard and browser implement.

So in essence Web offers you much security because the platform itself will never go away. Individual players in an ecosystem might go back but you have always other implementations and as direct result of that there is a lot of competition and that moves very, very quickly. If you look at JavaScript for example, if you look back three years, JavaScript was mostly interpreted language although substantially slower than native code execution. Today, by now JavaScript has gotten something 10x faster than average or so. There is a tremendous pressure to make JavaScript perform and they’re approaching the performance of native C++ code and this is only possible because a lot of parties are competing on the same feature set on the same language and we all have to compete on implemetation-quality. So, it really gets a lot of benefit to people who would like to use a platform - open platform, it’s guaranteed, it’s available, and the quality is guaranteed to improve over time.

2. Is there a minimum set of technologies that make up what we call the Web platform or more specifically, open Web platform or is it more a set of principles ?

I can just give you my personal view on it. Some people say that the HTML5 specification, that’s the open Web, I think it’s a little more general than that. HTML5 is specifically a collaborative effort between browser vendors and sometimes the competitive pressure between browser vendors causes certain piece of technology, I think, generally interesting, and should be needed to be identified not really end up in HTML5.

So, some parts what I consider open web stack such as WebGL, for example, are not really officially part of HTML5 even the language itself JavaScript is not an HTML5 standard. It is in the committee called TC39 run by ECMA. So, what the Web is, it’s kind of hard to describe, you just look at it what is being used today and what’s available across a number of platforms and that’s the Web and I think we will include HTML5, WebGL and JavaScript and other related technologies that are emerging and have broad consensus to use them.

3. I get the feeling that you are more favorable for growing technologies from the market like the model that HTML5 grows or the browsers grow instead of a model that JavaScript grows from a committee from TC39, am I correct about this? Because, I mean, basically HTML5 is driven practically by the browser-vendor; whereas Ecmascript is a bunch of wise people designing it?

I think it’s a little bit of both. Let’s talk about TC39 first. In some answers to the committee, I have done some work for the committee, I have worked on some features that they came with and implementation side. So, I’m familiar with some of the players and I’m familiar with people with the people that represent Mozilla, for example, in that committee. But I can’t speak very well for TC39, but this is my general observation: the same players really that push HTML5 standard also represent TC39.

In the end, in both HTML5 and TC39, it is impossible to examine the committee and TC39 does not really try to do that. So, there’s a bunch of browser-vendor, other parties interested in the Web -such as Yahoo and Facebook who might not have a direct stake in the browser game but there might be other parties that have an interest on being in that committee.

So a bunch of tech companies have sent additional representatives fromTC39 and there’s also university representatives, I believe.

In this environment, there are a lot of creative ideas coming up but it’s very, very difficult to create an idea on paper and put it into a standard. You will end up at something that is not implementable.

So, first on with this cycle, there was an excellent proposal for a meta object protocol for JavaScript called Proxies and an academic from Belgium, I think at that time working for Google as a postdoc propose that, and it was an excellent proposal, that was immediately interesting to everyone and I have been working with him in implementing that with F.

In that process, we ended up making quite a few changes to the original proposal which was just natural. As an implementer, going to the practical side of implementation, I discovered problems that are not easily detectable just on the specification level.

So I think it’s fair to say that everything in TC39 which was really successful has to start this prototyping very early. If you wait implementing up to the standards, that is often a good way to get into a corner instead of it not being implemented. And in some cases, you do see that in W3C. So, W3C has a group called DAP and they did give us device APIs and that group usually not had a strong representation for browser-vendor. I believe Opera was the only browser-vendor in that committee for a long time. Even Opera did not implement most of the standards and it’s part of the Boot to Gecko project which, I’m sure, we’ll get some more time to talk about, we start looking very intensively at device APIs and we start obviously with the existing standards and it turns out that many standards are simply not practical. They do not work well in a web context. There’s lot of implementation details that were not considered because again, they were not obviously visible on paper.

So I think that is really a living entity and it’s an ever evolving standard and my personal take and I think a lot of people in Mozilla support me in this idea is that we should not do research and new ideas and standards bodies. Browser-vendors are the interested parties should go and prototype things and propose ideas and provide a full implementation, give a certain system of prefixing these things to make sure we don’t collide with future standards but based on this prefixing and early experiments, we should iterate on this: we should put things out there, we should let them use device APIs, we should very early on start discussing these APIs and as more browsers become get interested, they will be going on, like pick up this implementation as part of that and begin to standardize them.

4. Do you see any side effects or negative results from having the actual vendors drive the specs?

That depends on who you ask. Mozilla is a vendor; so, for us driving aspect is obviously very useful since Mozilla has this unusual set up where Mozilla is a non-profit foundation and it’s not a traditional software company. We do have a corporation that a foundation owns and that corporation used to employ developers and the revenue the corporation generates is used to re-invest into making the Web better but really, our mission is to help our users and provide browsers our users like to use and to drive that technology in the direction that serves the foundation’s mission.

So, for us we definitely use the influence we gain as a browser-vendor, being basically the gateway of new technology into the browser stack. We definitely use that. So, for us it’s a very good perspective to have other parties that are interested in pushing on new things in the browser. And in the past, maybe we have not been very successful in serving those communities. An example is the entire cellphone space. For many of these mobile devices, the Web is not well equipped today. On desktop, almost everything you want to do with the desktop or that browser or the web stack we can handle very well. We can push pixels to the screen, we have audio, video, input, text display, storage, network. So, all works great.

If you look at the mobile device, if you write a Web application, almost all the features of the mobile device that are interesting - telephony, SMS, USB, Bluetooth, NFC-all of these interesting things on phone you can’t do these with the web stack yet and, of course, it has been a concern to those people having invested in that.

So, OEMS and carriers, for example, having for quite a while trying to establish standards for us, so they ctually created a separate working groups, independent of the W3C because they didn’t see browser-vendor paying a lot of attention this space and instead tried to create independent standards for that. And that did not work very well. They have implemented these standards on cellphones where they control their goal on the cellphone but these things never really found their way back into the web stack.

So, we have now things that are wireless applications, that run maybe on a cellphone and there are advanced capabilities on your cellphone you can run on specific phones. But in the end, we didn’t move the entire web forward and this is something we are very interested as browser-vendor. We have to make this better. We have to serve the entire community of developers and users of the Web because that is moving from desktop to mobile. So, there’s a lot of collaborative effort trying to move this early APIs back to W3C browser-vendors will pay a lot more attention to these mobile APIs, we’ll try to capture the entire API space for the future.

5. Talking about mobile devices, would you like to tell us a little about the Boot to Gecko project? What are the motivations behind it and what’s your actually planning on delivering?

So, Boot to Gecko was borne maybe four or five months ago on the vision that on desktop Mozilla was a big part of the new ecosystem you see on desktops. It’s the choice between multiple browsers implementing interoperable standards and the user can choose which browser implements the web stack more efficiently or more innovative usee on how to use it and it offers developers a way to really develop against public standards and open technology that they have a future path that is not dominated by one vendor.

So we took the desktop ten years ago was dominated by a single vendor, Microsoft, all the way down to what language we can use and what technology you can use and what APIs you have to use which in turn in an environment for most software today has shifted using to. So you completely revolutionize the way the desk computing works and I see really that the future of desk computing being the Web and even other major players in this field if you can look at Microsoft’s strategy with windows, you can see that even Microsoft is especially not really leading on many of these technologies and very much embracing the Web as seen where this is all headed.

So on desktop Mozilla has been fantastically successful establishing the Web as the platform. On Mobile really the opposite is happening. We have Mobile platform they are silos - there’s the Apple-iOS, silo, there’s the Android-Google silo and there’s even Windows 7 silo and not only are these completely segregated and separate, but others getting into the lock-in of this silos getting worse.

So today on iOS, if you buy Angry Birds from the Apple store, if your device and paid money for that application it’s made by the same company but you keep easily take it over to Android because it is programmed against Apple’s proprietary APIs. So, we are locking users in at the same time, we’re locking developers in. Developers develop for iOS and start over for Android and start over again for Windows phone 7.

There are new technologies and kind of triple their investment there. But even if you step away for a moment from this established user-developer relationship, there’s actually other carriers and OEMs who are pretty much locked into this.

So the carrier would like to customize the form, and it’s an iOS phone, there’s very little that a carrier can do and even if they do, it’d specific to that device and that stack. So with every player and the ecosystem except the one company owning the stack really does not benefit from it.

And that’s where the idea of Boot to Gecko was born from is that people used and the Web was successful in taking the desktop out of the grip of Microsoft and turning it into open platform and we believe that Mobile is the future here people will be going with their information needs and as a natural consequence, that should go to Mobile.

Now we’ll talk about the differences between API coverage and desktop and Mobile. So desktop -there are so many APIs which we like to add but at least the key things we’re covering more of there not yet; so, a big part of Boot to Gecko project is to very quickly close this gap. In essence, we have come to the realization that everything you can do with a native API on the cellphone today - like making outgoing phonecalls or accessing USB capabilities or Bluetooth capabilities. If you can do it with native APIs and you cannot do it with the Web, there’s a bug in the Web, and we’ll file a bug on it and we’re gonna find out how the API should look like and in order of implementation, we’re gonna fix it.

We’re gonna put a prototype implementation and start specifying it and this will enable programmers to take advantage of all the capabilities of the device using the Web and we consider this a very critical short-term goals.

When we set out in this endeavor, we basically decided about three or four months ago, that in six to nine months, we will get to close them- the gap, the feature gap between the Web and native APIs and we already fairly far along on the path.

So, we’ve proposed a number of APIs for telephony, for messaging on the device, APIs like settings and device vibration and in many of these cases, we’ve actually gone ahead and also started some standartisation process already and it’s different APIs on different stages for the process but the device vibration API, for example, you put out a prototype it’s already and you’ll be able in a future version of Firefox and at the same time you propose a standard based on that and there’s immediately for a lot of parties to provide input to that and there are gaming companies who would like to use device vibration to make more immersive games for mobile and there’s other browser makers who are interested in the same technology, same standard.

So, just this morning I read that someone posted in the internet that Samsung actually went ahead and implement the same APIs for the WebKit. So, if you manage to actually get this into the WebKit stack, then in a few months, we should be able to see the same API not just on our codebase but on Webkit and this is really the part of the Web’s been driven.

We put out standards on these prototypes, and there is interest around them and people feed back on the standard and reiterate on them and the moment you arrive at something, that most people can agree with, it starts spreading to other process as well.

So this is a very big part of Boot to Gecko project and if we assume that we can do this and I think the kind of pass of Mozilla and other browser vendors drive in it that that stack has proven that it is very possible to add a lot new capabilities to the Web. If you assume we can succeed with this, the next natural question is, if you have a mobile device, or you have a Web stack on and anything the device can do, you can do with the Web. Why will you need other parts of it? Why will you need a native Android stack using some dull Google proprietary technology and Google proprietary APIs, or in the case of Windows phone 7 some C# VM and what other very specific technology on these stacks? You can do everything with the Web.

So, it’s a very natural stack from there, from this initial step to make sure the Web has all the capabilities it needs to stay longer and move all these proprietary stuff from the platform, let’s take the traditional devices and the device stack and some low-level kernel and device drivers and put the web stack on top of that and build the entire phone experience using the Web - and that’s what Boot to Gecko is all about.

So, Boot to Gecko currently is a project. It’s not really a product yet in that sense but basically it’s a technology project, it’s run by the research group and we’re trying to show that first of all, we have all the capabilities, so we add all the capabilities we need and at the same time, we are building a developer phone using a prototype phone and the entire phone experience is based on the Web.

And we are not far long in that process - so we have a developer phone, we use some official hardware and software custom hardware so we can openly develop it and other people can reproduce our experiment and help us with the project. And it’s that hardware basically we went ahead and removed parts of the stack proprietary and we took existing Linux kernel and existing phone device driver stack and put on top of that our rendering engine Gecko- that’s what I mean with Boot to Gecko as it really comes about.

And on top of that, we develop a kind of prototype early phone experience using HTML5. So, what you’re left with is the device, the device boost straight into the Web and the homescreen is a web app and the dialer is a web app and SMS is a web app and ontop of that all pieces of it are built in this open technology and new standards for proposing and currently recommending as a prototype. So this really totally revolutionizes the way people can approach their devices. It is gives more control to every party which has a stake in this game.

So, users obviously in this kind of environment, get a lot more choice because this is not the Mozilla phone stack- something like that would never succeed. Many others have tried to penetrate the market of mobile device stacks and the most recent failures are obvious when talking about HP and WebOS. There’s simply no room in that market anymore for someone to recommend a proprietary stack.

So, this is not HTMLplus Mozilla magic, this is really public standards and Mozilla is interested in using its momentum and market weight to take today’s Web and make sure it fits well in the mobile and you can build the phone experience with it. And at the same time we do supply the implementation for that platform but very much invite others to that as well.

So, for me the ideal outcome of Boot to Gecko is that after this initial developer phone stage, we are moving to more prototypization phase that would be approved next year and then move more closely towards something which can be productised by vendors and some carriers. But at the same time, midterm and open perspective, we definitely hope that other browser-vendors and other interested parties will implement competing stacks - that’s really the best way to drive progress.

So I very much encourage Microsoft to build a similar open stack or other parties to drive that Webkit like Apple and Google. They should build a stack like this; they should build a phone stack where every part of the system is open technology can compete with the quality of implementation.

What is needed for developers really is I do strongly believe that the Web will pre-empt other software stack out there. Tis so much part of momentum behind it and there is so much synergy you can build this other device classes as well. You can build web apps and on desktops and other mobile devices and on cellphones.

So, in the long run, the Web’s definitely gonna be on mobile. This would give an incentive multiple parties to implement these stacks on their own standards and developers have something in the environment where it doesn’t really matter which phone a user has as long you’re putting the web APIs and public standards, the application’s gonna run everywhere. But even the parties that are currently not really involved in the direction of smartphone technology the OEMs and the carrier, so this is locked out and we delegated to a network pipe essentially. Even they get in so much better position in this game to really drive innovation because suddently it’s open stack.

If a carrier will have to customize a home screen, they can use web technology; they can use web developers to change the way the home screen works and suddenly they get again the possibility to really build the phone where they can customize the user experience and provide a user experience between their customers and the services - they’re not locked into going through a single vendor that controls networks.

6. How do you see the Boot to Gecko project comparing to something like the Chromebook which, I mean, follows a similar paradigm of directly booting to the Web basically having a Web browser? On a mobile device, you don’t need the location bar and the buttons, you will need more screen real state? How do you see Boot to Gecko comparing to the Chromebook?

First of all, it’s very difficult for me to speak any, about any products that Google makes, they have people that speak for themselves and as a complete external observer, I have no inside information on how these things work inside Google.

As an external observer, it seems to me that there’s some sort of split inside Google - that there is the Chrome camp and there’s the Android camp. And they kind of both do mobile devices and again, from the outside, the best distinction I can give you is that it seems that everything with keyboard is ChromeOS and everything without a keyboard is Android.

I don’t think it‘s a good split. So, I would expect at some point this is somehow gonna work together since it doesn’t make sense that keeps these separate. And I would consider if I was the person in charge of Android at Google, I would certainly be concerned about that, that Chrome actually has a more compelling developer story - they have a platform, there’s much more ubiquitous and much more likely to be more portable and offer a wider developed platform.

That having said though, if you look at Chrome has, the way its direction is going is definitely very different from what Mozilla is trying to envision. So a lot of things in Chrome and ChromeOS they use of that technology, the way it revolutionizes the use of that technology but Google does not have the same incentives that Mozilla has. Mozilla is a non-profit entity and our main goal is to push the Web forward and make it as good as we can for users.

The main goal of Google is to make money which is fair. They are a corporation for profit and I think that shines through in all things that Google does. If you look at Chrome, Chrome as a store, for example, but the technology behind the store, it’s not a public standard, it’s a Chrome store and the chrome manifest and there’s Angry Birds for Chrome.

And if you go to that, with a Firefox browser. We implement all the technological pieces, it will tell you this is not gonna work, you need Chrome for this, now if you’re gonna put past the site and bypass initial dialogue, it works just fine because really deep down we use all the same technology.

But Google has a different incentive than Mozilla. Mozilla has interest in others implementing the same technology as we are pushing. And we want to create a market but we like to compete with others and we don’t have other services that will cover to that. So Google is trying to say you there’s search and research and emails and all these things which are just fair and natural. It definitely makes sense to do that. We don’t have this kind of secondary motives. "We just want you to have a great web experience."

It allows us to really think about standards in a different way. For us, it’s an advantage if others implement things right away with us. For vendors like Google or others, it might be very different.

So, I see Chrome as being not as strongly focused in interoperability. If they do individual standards that only like Google internally implements, at least initially, there’s a certain period of time where they can lead the market because nobody else knows how to implement that. And I think you can see this inside a little bit outside the actual Chrome space.

In other technologies, Google has been pushed recently, a couple of weeks ago, I think, Google announced Dart which is Google’s replacement language for JavaScript. And Google’s accounts said, "JavaScript is not fast enough, it’s not good enough, it’s not moving fast enough. We need something new." So, here’s Dart. And it’s driven my Google, it’s invented by Google, I’m not sure the sources I get it might be...

But at the very least, it is not an open process to arrive at Dart and even if at some point Google opens that and even makes it a public standard for that is an open document for it, it’s still a Google driven technology that all the experts in Google and Google has all the momentum and developers behind it.

So really Dart is a play to take people from the open standard to draw its side and win them on something that’s Google specific and it puts Google in advantage because now Google probably is the best able to implement the Dart spec.

There’s other piece of the Chrome stack that Google has started building. They are very much focused only in a single vendor technology so that there is NaCl for example, and Google’s mode to execute native code on the web, so you can use C++ compilers or other compile languages, new compiler machine codes that runs in a safe sandbox.

And this is a Google technology. It’s not even a WebKit technology, it’s really a Google only technology. And I’m a little bit concerned that Google’s drive Chrome direction whether the use of tremendous financial and mind share momentum they have to drive the Web into an environment where there is the Web and there’s the Google Web and for some beautiful things, the Google offers a technology Web, the HTML5 that is not good enough anymore.

So, that’s really where I see the key distinction. I’m not building a system Boot to Gecko that I want to exclude others, rather the contrary. I don’t think I can succeed if I cannot convince others to implement the same APIs.

7. You talked about various APIs for mobile devices, how do you see these APIs getting standardized in the future, I mean, will W3C be enough? Some people will say it has failed on numerous occasions?

I think it’s fair to say that WCC has its fair share of problems. I think we should all know that. It’s a process. In the end, browser-vendors must collaborate. It’s a very key distinction, it’s a little bit hard to understand but once you kind of have your head into it, you can understand that browser-vendors have no interest or should have no interest in proprietary technology. I can make a couple of examples, based on from our stack.

Basically if we put an extension as a browser, if it gets widely picked up afterwards and turns into public standards, then we have a market advantage, if you’re early, you have more time to implement- we get more quality, we get mind share, developers like us because if it’s new feature they can use. So, something if we put in a browser, turning it into a standard is a great success for Mozilla.

Now, the flip side to that is if you put something into the browser that turns up to be not picked up by others and so it doesn’t become a standard de facto or official standard, then suddenly it’s a compatibility problem because you might have additional APIs or properties that would conflict these things or at the very least, you have to maintain the API surface. You have the invest engineering time to keep it alive, to keep it safe and you can’t either remove it because there might be some outsiders that you can actually use it.

So, non-extensions are usually not to your advantage. Except in certain elevated market position, so, Microsoft, for example, for a long time in the IE times, had the possibility to still handle and put something in the browser and it was de facto standard.

So, W3C is really an effort by browser-vendors to have a more polite way of interoperating with each other. Now, there have been problems in the past, obviously, and some of them, actually some technical part of it, some not, we’ve talked about them but I can talk about my experience recently with W3C.

W3C in general is not an entity. It’s just a browser maker as other parties are interested. So, this is an argument in mind, at the base level, every browser-vendor is interested in some sort of relation or should be in the end-process to collaborate.

And, for a while, W3C didn’t work very well and we have this web WG group, we collaborated now I think it’s gonna shift to what W3C had been able to collaborate there. In the end, this is all to be driven by browser-vendors and people have a stake on this game. So, we look for prototypes out there, we will describe how they work and we will engage other browser-vendors as early as we can to get their input, what do they think and other stakeholders, OMs and carriers and developers in the mobile space and different public standards. And if W3C is a good avenue for that and accelerates that, we will use them.

And I think right on that is the case. So, the device vibrations for example, was recently picked up by W3C and has worked very well. If we ever run into something and W3C is not a good tool form, we’ll find some other tool. In the end, what comes down is we have to incorporate and different vendors have to go the same standards and whatever path you’ll find to that is appropriate.

8. How do you see these APIs being adopted by manufacturers? Do you have an idea what the path will be, do you predict that the higher folks will come out with solid implementation and this will be picked up by some others and they’ll tinker with that? How do you see the road map?

There’s to be a differ from API to API.

9. I’m talking about the Boot to Gecko because you have some APIs that will come with mobile version of Firefox, I mean, adoption of it will be much easier, but then you have a full stack. How do you see this being adopted by vendors?

The first important note here is you’re not really building a mobile web stack, kind of class into that into mobile lap and desktop web? It’s probably not really debated into the future. So, we’re building APIs into the Web and capabilities into the Web. As an example, telephony is really a critical part of the Web on mobile if you would like to build powerful experiences for mobile phone experiences since telephony is a critical part of the cellphone; but you’re not building a mobile API for the Web on mobile at API for that. Instead what we’re doing is we’re building a phone API for the Web on mobile devices and also the radio if you have a radio if you have a radio both in it like a smartphone. On desktop, there will be other APIs where other related services can hook into. So, Skype, for example, could hook into itself using an API; into the browser phone API and Web pages can make phone calls to Skype as long as the user authorizes that.

So, it’s important that all the APIs we’re working on; some of them might make more sense than some devices but in the end you’ve got to target the entire web, device vibration for example, most desktop and laptop class devices don’t have the ability to like, modify use of vibration, that’s fine; the API will be present and in that case, in that device, a web app can call it but that’s not gonna have the same kind of desired effects.

So, you’ve got to load APIs like device vibration, a very fine way to control vibration so you can do immerse games in mobile and then start more level APIs such as notify the user. And that’s something you might do differently on a mobile phone and do differently on a desktop.

Now, much of the APIs identify themselves prototyping them, maybe the next question is: how do we get wide distribution? When we talk about this, it’s not of interest to Mozilla with this APIs because they don’t scale. You would not get developers to use them. So, I think the biggest tool we have there is again competition. So, I can go ahead and get it back because we are building these APIs not just to Boot to Gecko we’re also building into them Android, Firefox offering and desktop offering and between those two, we have half a billion users using them. It makes sense these APIs available very broadly to a lot of people so that a lot of us will start using them and they’re really very compelling applications.

And once you make really compelling use case and can demonstrate the use form of these APIs, then I think other browser-vendors will be pressured to add them as well. And in the case of device vibration I think you will see that. So we add the device vibration to Firefox if we use the Web on Firefox on Mobile and Android. Soon, we will be able to have more and more in this device vibration.

Samsung, one of the OMs out there that collaborates on W3C on the device vibration list, recognize that this will be a competitive disadvantage for their phones. I’m referring to the fact that they already announced that they started to engineer it, working on implementing the API for WebKit which I believe is the browser most often used in their Samsung devices.

So, this is exactly the example of how you see that happen. If we leap ahead and make new APIs and as long as we make sure that we implement about others with good standards and maybe we get some early buy-in from others, who are still in this game, then these APIs will gonna spread very quickly just based on market pressure.

10. We talked about earlier on JavaScript being an integral part of what we consider to be the HTML5 platform. What’s your opinion on the current state of JavaScript VMs and the special things like memory management about which you talked a lot in the past?

JavaScript is very dear to my heart because really at the core I’m a compiler builder, that’s my background. So, my PhD was in computer science and should be a special emphasis on compilation and I actually joined Mozilla to work on the JavaScript engine and together with Brendan Eich and Mike Shaver, the three of us built the first just in time compiler that was publicly available for the Web for JavaScript. So, JavaScript performance and compiling JavaScript and making it faster is a topic that very much interests me.

I think it’s really amazing what we have seen over the last 3 ½ years or so since I have been at Mozilla. So, I joined Mozilla and started building a first compiler for JavaScript that was publicly visible and available and back then JavaScript was an interpreted language that was nicely tuned and really fast for an interpreter but it was really in the order of magnitude of any compiler code. And where we have gotten from that point to today is really amazing. Most of my academic research before going to Mozilla and also in Java and during the entire time like three or four years, I worked in Java compilation, I think it’s the state of art of Java improved and you’ve got 10% total so , basically that’s a space completely explored more or less.

JavaScript, in the last three years or so has probably improved by an order of magnitude in performance, maybe more, just the first compiler of it in some cases and improved performance for 20X were interpreted.

So, there’s a lot of pressure on JavaScript these days, to be efficient. And again, this goes back to the same principle we discussed earlier that the value and system where everything is based on specifications and different vendors compete with quality not about what APIs are available. Thus, as a result I value what Google that tries to market its browser like being fast and efficient and using the V8 engine highlights the benchmarks all of the various performance benefits and other browsers reflect us on a pressure to match them on the benchmark.

So, this set off a vicious performance benchmarking game where everyone puts in best engineers they have into performing JavaScript.

So, what you can do with JavaScript today is really astonishing and even I have to admit, I wish I didn’t experiment in the research group with other researchers but even I was surprised by the outcome. So, JavaScript has gotten to a point where we recently released a project called Broadway where we do H264 video encoding in JavaScript in the browser and we’re talking about the decent-sized full frame video of that plays purely in the browser. And that’s really amazing. We have gotten from the JavaScript to the point where it’s from a slow interpreterd language, to the point where it’s really competitive to C++ and other native languages.

Even beyond that, the JavaScript has additional features that can help make it more efficient. So, this Broadway project, some of the decoding work where we actually pushed - the WebGL and the GPU some of the recording work we used hardware acceleration in the GPU for that. That only shows that JavaScript is not really getting really fast and competitive in performance sense but also can leverage other technologies that are closely related to begin more performant.

So I’m very positive on the performance of JavaScript. I really don’t think that there are many applications left in a short period of time for JavaScript is not suitable from a performance perspective.

Now, memory is a concern that has become more of a central issue over the last maybe year or two from Mozilla because it tries to take our desktop stack, it was very successful on desktop and makes it’s equally more successful on mobile, we often deal with devices and have a significant less memory and operating in a more constrained environment.

So, it’s interesting to see. I remember when I started working on JavaScript JIT and everything was top performance. If you have to use memory to be faster, use my memory. And now you can think back and all the equation is more complicated. You try to use as much memory as necessary to be fast but as little as possible. So, we can be competitive in small devices as often and in many, many times less memory than on larger devices.

So, I think the browser is becoming more competitive. It has certainly rough edges but I think they are very close in some of the applications than the Web has been able these days. You control that.

11. Do you agree that nowadays JavaScript is not the bottleneck and the bottleneck is performance bottleneck you can find that performance bottleneck on WebGL implementation or canvas things?

I think I agree to that last part. I think there’s still a lot of pressure on JavaScript, Mozilla has been trying to be very innovative in this space. So, we recently started shipping type inference which is a very new mechanism where we analyze code very deeply as the JavaScript loads it, we try to find out type information through that and it significantly enhance performance and expect the browser vendor to quickly adopt same technology just so they can match the performance we get in certain kinds of code.

But I think in JavaScript, you’re right. We’re approaching in JavaScript the kind of like plateau that we have seen in Java maybe five or ten years already that at some point all browser-vendors will get so close in performance and we get so close to native performance so it’s not all that much can be done. Some things in JavaScript have to be more expensive, something in JavaScript is more high level in native languages and they offer more memory safety and they are a little bit more expensive but in the end it’s getting to a point where if you can write code like a video codre on pure JavaScript and it runs on like hardware, you can make it faster, you can make it more battery efficient to make it a little bit faster but it’s simply not the bottleneck.

So I definitely agree that lots of benchmark has been done over the last like two years or so; it was a very solid focus on JavaScript performance and that’s not really where the future promise is, and there is even research to back this, Microsoft research did some early work on this roughly a year ago or so together with Purdueuniversity. But this show that if you look at the way we got fastd on benchmarks comparison on how we got fast and we get in user experience, it’s very different.

So on benchmarks, everything works massively faster, whereas average like performance and speed of a page flow has improved somewhat but nowhere in the same pace. So, we have to shift the game from just like JavaScript performance to whole performance of things like WebGL, the DOM, the display - so it’s a complex stack. If you’re going to look at the entire stack, you want to make it fast in performant.

12. You talked about same complete stack and analyzing poor performance and the first thing that popped into my mind is debugging. So I wanted to ask you how do you see that developer tool stack evolving as the whole platform is evolving?

Actually I admit that this is probably one of the weakest points of the Web stack, at least the way I see it today. If you compare some of the other stacks and the kind of deep tool embedding they have, the Web often does not look as good in that comparison, at least today. This is certainly a weakness and Mozilla has its own developer tools team and they did some amazing work. In general, I think, at least for a while, we were rather behind. So if we look at the development tool, for example, that came as Chrome last year and the tools that Firefox came last year, I don’t think we were 100% on par with some of the competition. Definitely, that is an area of concern to us because we invested heavily on that.

13. So, to be fair you should probably be comparing with the tools that are available on Firefox 11 probably?

Yes, so I think we’ve made a lot of progress in the meantime. So, again this is a competitive market. It’s kind of hard to predict sometimes how things are going and provide a new focus and experience and traditionally Firefox was very, very good about that the developer experience and we had a very, very broad mind shares, developers and firebug was a very popular extension to Firefox and then you start focusing very much on the user to get it grow and maintain that market share as it is very important for us to have an impact on that technology.

And at some point of competition was not as fast as the development tools. And, this of course, we’ve noticed from the feedback and since that we’ve invested heavily on development tools. So you’re actually right on Firefox 11 is coming on as a very broad features and we work on debuggers and integrate debuggers on the browser and profiling, and also not just profile JavaScript, but the entire stack and look at CSS and manipulate CSS, to understand CSS rules better, to understand HTML5 structure better.

In general, the Web is really very open and vibrant. It’s kind of like deep embedding of tools into the browser, I think it makes a lot of sense but makes a browser different.

For example, the Boot to Gecko developer points we have right now, on the Android phone, as a user, you have no idea of what’s going on there but while the features we implement on our developer form is if you press for two seconds on this thing on, performance, I’ll actually do a pop up and view source star log and you view from desktop. So, you can literally see how the homescreen is built and dialer for SMS applications are built and these, I think, is part of the power of the Web is that it’s transparent the developers, if you see something cool in the Web site and you can see these works. This is what makes it more powerful that competing platform. So, that really requires even more so good tool support and I think tool support is coming.

In general, it’s fair to say that most browser-vendors have not been as good as they should be. Even with the other competing stacks like, the tool support is moving near the level that some of the proprietary stacks have, Microsoft, for example, is the definition of leading tool support on their platform. I think we have to reach that degree of efficiency with tool support. We will provide some part of that - we have our own tool support but as we leave room for others to provide these tools and we’ve already seen some of it.

Companies actually identify on platform like Adobe, the basically realize that Web is on its platform and the tools are not really on par. So, Adobe has announced they’re shifting their flash tools or to target that the web more and I expect many other companies to take this opportunity and to offer in great development value to the platform.

What is nice there is that you can use the Web to build these things. So, if you look at the way Firefox implements all its developer tools, they deeply get into the Web, we can open up that page and we can open like an editor and in the browser you can say, "I’m going to change this CSS property and then increases the font on the page." So you can do these even deep integration of the platform which is a natural applications and it’s a very, like, quick turn around development experience.

So, I’ve great hopes for the development tools. I think you have to wait a little bit just to see how great it can be but right now it’s certainly not what it should be.

14. What are the most innovating things you’ve been seeing people building nowadays with HTML5? Also can you talk a little bit about pdf.js, which, for me, looking at it seemed pretty innovative and different?

I will focus to the degree to the work that I’m doing my research like research done in a group because that’s what I’m most familiar with. I will also try to mention a couple of things that others have done just to make sure it’s clear that there’s a lot of innovative work happening outside Mozilla too but, just like the kind of things that we do in our group. I believe pdf.js and that was, in essence, a platform experiment. So, many people perceive pdf.js when we were first talking about that as Mozilla was building an Acrobat Reader like thing into the browser.

And that is our headline we are headed that way. So we definitely have the goal to eventually put this in the browser but it was not really the key message behind it. The key message behind pdf.js and the motivation for the other engineers, Chris Jones and I who started this project, we were really interested on the web stack.

We were together on a business trip in Taipei, I believe, and we were just discussing the various aspects of the stack just the same and we were wondering why do people render pdf instead of code everyone does. Acrobat readers may need this code. Google starts shipping our pdf reader in Chrome and it’s native code especially in non-open source of code, I think it’s pdf reader company Foxit it but it’s native code they ship and we were just wondering why like, " Why does nobody use the Web stack to the pdf?" And looking around for other projects and people started little like a pdf reader and implemented some minimum functionality so we were just curious from a research perspective, there must be a reason, right? Maybe something doesn’t work, maybe something is missing. So, we sat down and say, "We did the pdf reader," the approach we took, we need kind of reflect the question we were asking like, "Can you do really pdf reading in JavaScript and HTML5?" And we built for one specific, pdf document; we built the pdf reader in JavaScript and HTML5 which does pizel-accurate, maximum fidelity, maximum quality pdf rendering. And we were able to work maybe like two or three weeks to get to the point where we had very faithful pdf in pure JavaScript and it turned out to be actually very performant.

By now, we have invested a lot of our work in this. Mozilla actually has just hired a crew of full-time employees to continue this work until we get to the point where we need a large fraction of Web’s pdf and greater quality, very quickly. So I think now it’s moving closer to a product path.

But initially back then thrust must really for us is to Web there yet, now can we do this pdf?. I think the answer is ‘yes’ there’s a little asterisk because we also identify the extra something were missing in the Web stack.

For example, identify the canvas which we use to render the actual pdf pixel can now draw dash lines and pdf dash lines in some documents use them and as we’re building this, we at some point are trying to map the pdf dash line operation to canvas and go like, "Well, this is missing," and I think this is why I like to discuss experiments with our research group. This is where we can identify what’s missing in the Web. We have to go and build things. And it’s very hard to predict. The people made canvas, I know a couple of them. Some of them work for Mozilla, they’re very, very smart. It was just hard to predict that dash lines were so important. And they are. So, if we propose an extension and implement it as a part of Firefox, then that’s what we’re using pdf.js now and I would expect that this would propagate to other browsers quickly because it’s a very obvious feature.

Beyond pdf.js there’s a bunch of other interesting things we do in the group. I talked about Broadway areas -H.264 decoder and they’re basically trying to answer the same question really: why I need video recorders to be written in native co, can a video recording with JavaScript and the Web stack itself?

And I think it opens up our new range of opportunities, in particular, if you manage to leverage technologies like WebGL, you can get to an environment where you can do a CPU-based recording but also GPU based configuration and proper power efficient video recording using the web platform.

And obviously the advantages are that if you take a browser today, the browser has to be shipped to video recorder and this creates a whole bunch of patent issues. Mozilla is not shipping H264 recorders amongst others because its patent had not opened technology. And this kind of limits to the degree of content providers can really provide because you have to deal with ever recorders with choosing the browsers.

If you create a platform instead, the kind of provider in his download some WebGL code and some JavaScript code and the videos, then they can choose whatever they would like and they have to deal as patent side of this.

And expectation beyond that even is that if content providers would like to do additional processing, a kind of video experience they control the codec and integrate much better with the web, so that they can do overlays or something like that very easily or do additional video processing on the fly.

So, we really think it’s important that we go and look at all the parts of the Web. We currently use not the Web to extend it but next time, you could use maybe the Web instead. And of course, there’s a lot of innovative work putting outside Mozilla. I was recently at JSConf.eu and there I saw a presentation on mp3 decoder and JavaScript, I think it’s called JSMAD and there’s been a sort of show like performances there and they’re getting to the point where it’s truly competitive.

Another project we do on our group to enable this kind of like crazy experimental work is Emscripten. Emscripten is done by a research in group who took an LLVM which is basically a C++ kind of back-end and he changed the LLVM to target JavaScript. So, actually the Broadway project that we publicly showed a couple of weeks ago, we didn’t actually hand coded all the JavaScript. We took an existing H264 recorder that was written in C++ and with Emscripten we were able to compiled it to the JavaScript and Emscripten this as really efficient.

So we basically we’re able to record the video in good quality of over 60 frames per second on a desktop using C++ code really but it was compliled using this Emscripten construct.

So I think the Web is a limitless pool of innovation and my voice is a little bit biased because these people around me are doing these great things but there is unlimited pool of innovation beyond it and it’s so accessible. I think that’s what really spurs people’s imagination that when we showed Broadway, the press was talking about it because anyone can see it. You can pull up yourself on your desktop, you can see what it does. You don’t have to install anything, Mac or Windows, this works everywhere!