Google I/O 2010, Keynote 1 Impressions

The first Keynote of Google I/O 2010 had a few highlights:

  1. HTML5 my Lord - Kumbaya

  2. Native Client Underplayed

  3. The announcement of the Chrome Web Store

  4. Adobe focusing on HTML5 tooling

  5. The Open Sourcing and permissive use licensing of the VP8 codec

  6. The partnership of VMWare/SpringSource and Google to allow developers to create portable Cloud Apps

HTML5 my Lord - Kumbaya

Rightly so, Google is heavily pushing its weight behind HTML5 as a way to expose greater client-side functionality to web-developers whilst still remaining in a secure environment.

Development team after development team were rolled out onto stage to wax lyrical about how great HTML5 is and how it allows them to create richer web experiences.

Very true, the demos all highlighted functionality that was not possible in HTML4, yet, something was off. HTML5 allows the server to send the client JavaScript code to run locally and also allows for the code and resources to be locally cached so that an application can be ran offline (the server can create a client-side database cache). All this is great and a definate step forward.

BUT, HTML5 still sits on top of the DOM and JavaScript. That makes them slow. I assume that the PC used in the demos was capable, and even if not, you would have to go back 10 years to re-create the same sort of sluggishness in a desktop application that was demonstrated in these HTML5 applications.

For the majority of apps, it simply will not make a difference. If you are dealing with text and forms with the occasional diagram on your page, HTML5 will solve all your needs, as-is.

But, I think that it is a fundamental mistake to think that web-apps can compete with desktop apps with the current iteration of HTML5.

Desktop apps need real bindings to the environment on which they sit. They require access to the USB ports, the microphone, the webcam, the displayport. Desktop apps need to run at native speeds and not through a layer of JavaScript, that needs to be contantly runtime evaluated for optimisation due to the language being designed for maximum flexibility, not speed.

Desktop apps need to be able to control screen refresh and to be able to synchronize on vertical refresh. Desktop apps need to be able to run full-screen if required. They need to be power-efficient and to be able to perform their task with in the smallest amount of time.

Some HTML5 apps will not be subject to performance considerations nor the considerations of file-system or hardware access. For these apps, HTML5 represents a huge leap forward, but if the intent of Google is to move all apps onto the cloud as a combination of server and client-side scripting, then HTML5 needs to be updated to allow for native-execution-speed and better bindings to the host device capabilities.

Native Client Underplayed

As if to acknowledge that JavaScript will not meet the performance expectations of web-users accustomed to desktop applications that run at native speed, the keynote mentioned in passing the 'Native Client' project but downplayed it at this time as it undermined the main theme of HTML5 being the Alpha and the Omega.

The Native Client project allows for Web authors (via a browser plugin) to write code in C++ to run natively for some web applications. The source-code is compiled and made safe via the pre-processor (making sure that code cannot overwrite or jump to code outside its designated memory area). The code is then executed via the browser in a sandboxed environment. The code is said to run at 97% of native speed (likely due to the limited amounts of addressing modes accessible within the sandbox).

Whilst this is currently not part of the HTML5 specification, I hope that it is added sometime in the next year as native code execution is the missing link in HTML5. Of course, native code execution means nothing unless it is portable, so I would not support this development unless there were a virtual machine option to ensure portability whilst allowing for an order of magnitude greater performance than JavaScript. I understand that Google is investigating using the LLVM for this purpose.

The announcement of the Chrome Web Store

The Chrome Web Store was rolled out and several apps were highlighted. This was the biggest mis-step in the presentation for none of the apps seemed to equal a desktop app, and the best web 'app' demod was 'Plants versus Zombies' which made me sit up and take notice for a few seconds. It seemed to be running at a good speed and to have the sound working in the game (something I have not seen done with any degree of success in HTML5 so far). Then, it was revealed that this web 'app' is was actually running in Flash. So much for the theme of the keynote (HTML5 is great). We all know that Flash is supposed to be evil and bad, but it still provides functionality that HTML5 can only dream of for-now.

Someone came out and showed an offline demo of a web-based Photoshop-a-like application. The performance looked fine for the simple use-cases he detailed but I couldn't help but wonder how many users would pay $5 for essentially a web-page experience.

Adobe focusing on HTML5 tooling

Adobe's CTO, Kevin Lynch came on stage to 'focus on HTML5'. He showed off some really nice tools for developing HTML5 web pages and tooling based around the new CSS elements. It worked nicely, but it was a simple use-case. Its obvious that Flash remains a necessary evil until HTML5 pulls its act together and its nice to see Adobe transitioning to the open standard whilst still supporting the closed standard.

The Open Sourcing and permissive use licensing of the VP8 codec

As predicted for some time, Google took this opportunity to announce the open-sourcing of the VP8 codec. This is a very efficient codec in the same league as H264 without the patent issues (maybe).

FireFox has long been in a predicament with regards to how to implement the open HTML5 standard that allows websites to embed proprietory codec encoded videos within <video /> tags. The browser must be responsible for rendering the video but a truly open browser does not and cannot ever afford a license for a proprietory codec. FireFox publically flailed and supported Ogg/Vorbis as the best Open-Source alternative although it was obvious that H264 was a much better implementation. Google itself had a conundrum, how can it move its videos to HTML5 when different browsers support different codecs. Would it have to re-encode all the YouTube videos for every combination of browser supported codec?

It looks like in the end there will be 2 codecs for youtube, H264 and VP8. H264 has to stick around because current-gen mobile devices have hardware acceleration for H264 wheras VP8 has to be decoded in software (for now) leading to potentially sluggish performance and/or poor battery life. This should change in the next few years as hardware support for VP8 should be added to most SoC solutions.

Personally speaking, I hope my Atom 330 ION based net-top has enough CPU/GPU power to software decode VP8 720P streams (1080P is probably out of the question).

It also remains to be seen how the MPEG LA group respond to Google attacking their cash-cow. Its obvious that there are enough devices out in the wild and enough support of H264 (Blu-Ray, Mobile devices, etc.) that H264s continued survival is ensured. They may respond with litigation, or opening their own codec, or perhaps just mine the existing licencees whilst developing a follow-up 3D optimised codec. Who knows?

The partnership of VMWare/SpringSource and Google to allow developers to create portable Cloud Apps

This part was interesting to me. Google App Engine is cool, GWT is cool, but building on Google App Engine always felt like vendor lock-in to me. Glad to see that there will be competition in the cloud for hosting. Google could have tried to tie in app developers to using their hosting, but it seems that an App developed using App Engine will be deployable to a number of different targets.

The Roo demo was nice but I'd seen it before on youtube and I really hate remembering command line commands so was a little disappointed that the presentation never detailed the GUI tools.

I like the idea of GWT 2.1 supporting multiple profiles and it being able to detect devices and adjust the look and feel accordingly. I'll be using 2.1 myself in the near future I'm sure.