Editor’s Note:
Michael did a great job jotting down notes at our developer event in London, and we appreciate him taking the time to do a writeup. Some of the notes have been taken out of context, so we wanted to clarify: We started with a talk on the the future of the mobile Web. This talked about the potential of the Web as the platform for devices, and why we were excited to join Palm.
We don’t comment on our specific SDK plans, and while we are personally excited about the Web gaining GPU acceleration via technologies like WebGL and CSS Transforms, and we would like to see webOS gain these capabilities to allow web developers to better leverage our fantastic hardware, we were answering a question about our personal opinion on what we’d like to see happen to the platform. We don’t believe the term “immediate” was even mentioned by us, and we are sorry that people have read too much into this particular topic.

Ben and Dion have just wrapped up a WebOS talk in London, in conjunction with O2 Litmus. They explained why Palm is using the web as an application platform (might be preaching to the converted on this website!) and covered some of the development issues.

Embracing The Web

Ben and Dion open by discussing a panel Ben was on some years ago with Dave Thomas. Ben answered rich UIs as the most important trend, but Dave held up his mobile and said this is the future of software. And (according to Ben) Dave has been vindicated. Today, we have many, many, devices, and it’s tricky for us to target them as both developers (technically) and businesses (commercially).

But what’s interesting is the web browsers that have snuck into many of these platforms. The Ajax revolution changed the game for the first time, where you could build real-world web apps. (screenshots: GMail, GMaps, GOffice, Bespin, 280slides.) It’s only happening just now, and pretty soon, the web will be a great place not just from portability of the code, but portability of the distribution mechanism.

Tools like Fluid, Mozilla Prism, give us a specialised browser for a web app. On the other end of the spectrum, we have tools like Adobe Air and Appcelerator Titanium that let developers build full-fledged desktop applications.

But why the web? How about other technologies like Silverlight and Flash? Well, the browser really hasn’t changed that much (Netscape screenshot). But underneath, the engine has changed dramatically. We’re going from the hacky world of the first browsers to one where developers will benefit greatly from the Javascript engines, renderers, and APIs available to us.

For example, with canvas, the ability to do dynamic graphics (nice demos). Likewise, SVGs. Custom typography; Firefox is rolling out support for even obscure features of fonts. Later in the presentation, Ben demonstrates further capabilities: OpenGL and 3D CSS transformations (more nice demos); what Ben calls “the final frontier” of visual interfaces.

Faster Javascript engines are more than just increased performance. As Steven Levy points out, when you increase something’s performance by an order of magnitude, you haven’t just increased the performance; you’ve created something new. So we have generational garbage collection, for example, which is a sign of the virtual machines maturing and becoming much faster.

Related to JavaScript speed is threading. We don’t have threads and given opinions of the creator of JavaScript, probably never will. But “browsers now have something that’s even better than threads”: web workers. It’s used in different ways; for example, Chrome extensions can run in their own process this way. Another example is running a database server like SQLite in a separate process.

So does the web have the capabilities for today’s and tomorrow’s applicatons? There’s a huge user base and a huge developer based – more developers than any other platform. Some people still think of JavaScript as a toy, but when they get into it, they often realize it’s actually quite good, and it’s not JavaScript they don’t like, but things like browser incompatibilities that are troublesome.

Development Details

Web developers can use the Mojo framework, which provides simple Prototype based APIs. Notifications are HTML controls themselves, so you can put whatever HTML you want inside it. Security-wise, applications can get different powers

Palm wants to sell phones, not proprietary APIs, so it’s involved with BONDI and W3C widgets standardisation efforts. One of the things they need to know from us (the developer community) “Palm pays us, but they didn’t pay us enough to sell out”; Ben and Dion are developers and they’re not going to tell other developers use “our funny proprietary API, you’ll love it”. However, they can’t say when all this will happen, as they’re evolving the platform pragmatically and they feel other things might have more immediate impact, e.g. OpenGL support.

The web distribution model is simple – user surfs to a URL! But many people actually want a catalogue, and in fact some app catalogues are becoming spam catalogues. Some even boast about how many apps there are in the catalogue, Ben notes with a wink at the big I. With Palm, developers pay $50 and it helps to avoid the problem. There will be one catalogue, but developers can control which markets they’re selling in, and get useful analytics and feeds about its usage. Wanting to reduce the friction for people to buy an app, so would consider (although nothing definite) carrier billing and affiliate links.

Q&A

The developer portal is currently being overhauled. Under consideration are ways to make things more transparent, e.g. bug tracking and planned features.

Ben and Dion anticipate that developers will probably be able to opt in to JavaScript obfuscation (or some other form of obfuscation). As Dion explains, View Source has been really important on the web, so there’s a tension and it’s likely multiple options will be available.

On ease of use, multitasking has been great; UI latency is still an issue even though the hardware is comparable to 3GS. The problem is the path to the GPU didn’t exist, but now with CSS transforms, that will be solved in the future. As far as screen size, where Pixi broke the mold 4 months after the Pre, this happy world of coding to the same screen size on mobiles is going. Ben says it would have been easier for Palm if it wasn’t the first phone to break the mould, but reality is the mobile space will break out to big screens, phones, etc etc, so it won’t be one fixed resolution or even aspect ratio.

There will be lots of new tools for developing with and they’ll be able to work with WebKit. Ben and Dion (not speaking for Palm, they’re sure to add) are open to the thought of embracing Flash for native apps and keen to hear people’s thoughts on it.

The open source question … will Palm open source WebOS. Ben says “we (Ben and Dion) would love to do it”, but it’s not Android working to thousands of phones and it still has to be considered.

3 Comments

AFAIK there are two different environment, the browser one, with its common sandboxed execution, and the application layer, which has almost same security model present for iPhone or Android applications, except the authorization could be incremental (as soon as it is used).

The event has been excellent under every point of view and Ben, Dion, and Michael are machines and I’ve met lots of different professionals, good stuff guys and thanks!!!

P.S. Off Topic Michael, I thought about the var $body stuff, you’ll never use that code in a global scope, will you? I am talking about functions, events, and the classic ready $(function(){/*code*/}) :P
But I agree I am a performances maniac :D