Dion Almaer on the State of HTML5 and Javascript

1. We’re here at the JAOO Conference/GOTO Conference 2010 in Aarhus, Denmark and I’m sitting here with Dion Almaer. Dion, who are you?

Thanks for inviting me to chat here. My name is Dion Almaer. I work for Palm, which is recently a part of HP. [Editor's note: Dion has left Palm since this interview, http://almaer.com/blog/setting-our-own-direction] I work on the web OS side of things - I run the developer relations group with my comrade Ben Galbraith [Editor's note: Ben Galbraith has left Palm too.], who unfortunately couldn't be here at the event. So I’m giving my talk solo, even though we often do the 1-2 punch, so to speak. We run developer relations for webOS. That basically means anywhere where developers touch webOS, whether that’s on the app catalogue, the SDK itself developer support - we run that organization. Also, we founded Ajaxian.com, a community that talks about all the fun things that are going on in JavaScript and the web in general. Just before Palm we worked at Mozilla, where we ran the developer tools lab, which included products like Bespin which is now Skywriter.

2. Let’s jump right into Bespin. What’s Bespin or Skywriter? [Editor's note: the Skywriter project has gone through a big change recently and has dropped the Canvas editor component: http://mozillalabs.com/skywriter/2011/01/18/mozilla-skywriter-has-been-merged-into-ace/ ]

Bespin got renamed to Skywriter. I guess they’ve publicly talked about this recently, so Bespin is a planet in Star Wars and it’s the Cloud City in "The Empire Strikes Back". That was our fun code name for the project, but LucasArts are known to be fairly litigious, so there was always this fear that they’d come and try to sue Mozilla or something. They actually never did, to my knowledge, but now Bespin is kind of coming up on 1.0 and they are making it into a real product. This was the time to change the name because it’s now called Skywriter. But basically it’s a code editor for the web. One of the major use cases is it’s a fully embedded editor component. We’ve seen a lot of people were using it within their applications. For example BlueGriffon is this fantastic HTML editor run by Daniel Glazman, a long time Mozilla chap. For his editor component he uses Skywriter.

EtherCode just came out, which is a mash-up of Etherpad and Bespin. There are a bunch of people that are using it as an editor and we wanted to just give people the ability to have a fantastic code level text area that they can just swap in. that’s where Bespin came around.

3. Does HP/Palm use Bespin. I figure you have an IDE called Ares.

Exactly. We have an IDE called Ares and Ares focuses on being this mobile web design and coding tool. It allows you to go in and fully drag-and-drop your UI with all of the Web OS components, but then you can go in and click through and then write the handlers themselves using Bespin. So that product uses Bespin both the editor piece and it also actually uses the Bespin server as a way to store your projects and files. One really cool thing about Ares is the fact that it does tie into your local system. So it actually uses a Java applet to allow you to do full drag-and-drop projects and into the project to be able to connect to the device, so you can be in your browser developing an application and just send that right to your device or your local emulator to do testing on it. It’s a really fun kind of sexy project. That’s how we got to know the Palm team.

4. [WebOS applications] are written all in HTML JavaScript, so you can run them on any device essentially?

Applications written for Web OS are written in two tracks. Step back a little bit: there is the main SDK, which is an SDK that allows you to develop applications in HTML, JavaScript and CSS, just like you say. Basically Web OS is a Linux kernel with Webkit on top and V8 as the engine that’s running JavaScript in between. As a web developer it’s very familiar technology that you use to build web apps that happen to run natively, so you have to think about the architecture of building a client app vs. an app that’s running in the server, but it’s using exactly the same technologies that you mentioned.

We also have a piece of the SDK called the PDK, which is the plug-in development kit. That’s analogous to a browser has plug-ins and so within a browser you can take over a little rectangle and do something, like with Flash. We have the same kind of ability where you can have a plug-in in your Web OS application where you can run anything you want, native code. We see a lot of people using that for games. We’ve got a lot of games on our platform, such as the popular "Angry Birds" game on the iPhone. They are able in a matter of a few days to take that game, port it to the PDK because it uses the same low level runtime as the iPhone. For example OpenGL, SDL, C++, so the same kind of stuff. If that’s the technology you are used to, you can easily migrate an application or a game or what have you to use that.

One thing that’s pretty cool about these plug-ins is on the web, if you want to extend the browser with a plug-in, you have to force everyone to install a plug-in and that’s a lot of friction. But in Web OS, you package your application and you can have a plug-in that’s part of that app. Through the lifecycle of installing an application on Web OS, it will just naturally fit in to what’s going on. You can write whatever you want in a plug-in and the user doesn’t have to care about it or worry about it, so it’s slightly different.

5. Are PDK applications standalone applications or can they some small rectangle in a Mojo application?

You mentioned Mojo. Mojo is the JavaScript framework that we’ve built that’s a full MVC framework. So if you are used to things like Swing or larger UI toolkits, it’s analogous to that, on the JavaScript side. That’s the way that you can build these applications that look like traditional Web OS applications. All of our apps, email, calendar - all that stuff is written using the Web SDK, using Mojo. The PDK plug-ins that we’re talking about can be games, which are full standalone apps or they can be these hybrid applications where the UI is written in Mojo and the web and then use native code to do something else behind the scenes. Maybe you are talking binary sockets or something, talking to something on the native device that you need access to, so you can definitely mix them up.

We have applications that use that model, like Sprint, I believe has a navigator mapping directions application where the UI itself is written in the web, apart from a piece of the screen that shows you the mapping of what’s going on - "Turn left here" and that kind of stuff, is already using PDK-like technology.

6. Can the PDK code export objects to the JavaScript so that JavaScript code can access it in any way?

Exactly. Just like you have an object tag in the web that gives you access to speak through. In Flash you can use external interface to talk through. We have a very similar model: the PDK can expose things to the JavaScript layer, so that they can communicate to each other. There is another level of communication which leads into something else that’s cool: Web OS has what we call a service bus on the device. You speak and ask questions the service bus to get information about the device, so GPS or what have you. PDK plug-ins can sit on the other side of that service bus. One PDK plug-in could be accessed by multiple applications through this service bus interface. There is another technology called NodeJS, which is a JavaScript server framework that is known for an event-based framework that’s really taking off.

It’s similar to the early days with Rails (I used to be in that community) and people were just super-excited about it. We actually took that and put it on the device so you can write JavaScript services on the device that multiple applications can use. It’s fun to see people using that and see what happens when you open that up because now you can write a client app that can speak to a NodeJS service that’s running on the server and if it implements the same RESTful services what you have up in the Cloud, you could have something that seamlessly talks to the Cloud when you are offline, that talks to your local servers. You can do some interesting things there.

7. It’s interesting to see that for cross-platform mobile development there are two systems: it’s JavaScript and HTML and native code as we see in the PDK and in the iOS and Android NDK. What do you think of that? Essentially you have a very high-level system and a very low-level system?

I’m a big believer of the Web, of course, but I fully understand that there is a ton of C and C++ code out there and there are different communities and people like to program in different ways. I like the fact that there is multiple on-ramps onto what is going on here. Just like we meant, we came out with a PDK because we realized that these game companies like coding in C++. We’re not going to persuade them to switch to WebGL quite yet and so let’s embrace that fact and give them first class path onto the platform and as you say they can then get on to the NDK on the Android side and on iOS as well. We do think though there is a massive opportunity for the web to allow you on the general apps world to use that as a way to get your application into all of the different markets and stores that are out there.

Because we understand as a developer you don’t want to be limited in what stores you have access to, you want to be able to access as many as possible and to get your distribution out there. So, with products like Phone Gap, which allows you to take you web application on all platforms, Phone Gap’s not doing a lot for you because it’s already the web. But it allows you to build this application and then with Phone Gap you can wrap it up and have access to iPhone and Android and Blackberry, etc. Then, as a developer, you get the benefit of being there to access all of these ecosystems. We think that’s really important because otherwise, you’re in hell, which is porting your application to all of these different platforms.

We speak to developers and companies all the time and they are frustrated "OK, I build, say an iPhone app; now I know I need to go to Android app or WebOS app, I want to go to Blackberry. I spend all my time just porting the application between all these very different proprietary systems." So that’s why we’re really excited that the web has an opportunity if it steps up to be this way the uniform platform for developers and give them access to all of these different areas. Then C and C++ have another opportunity of the low level of doing that work, too.

8. You mentioned WebGL. How far along is that? Do you know something about the state of that?

WebGL is now turned on by default on Chrome, which is great. This is the kind of stuff that I think we need. I think it’s pretty well baked. It’s more getting it into the browsers themselves, so the developers feel like it’s worth their effort embracing it and working on it. OpenGL for JavaScript guys is a little bit kind of weird, because like the OpenGL guys are normally C guys and they think in that way and the JavaScript guys don’t normally think in the world of OpenGL and shaders. So I think there is going to be a little bit of a learning curve. I think there is going to be "a jQuery for WebGL" where people can build your frameworks on top of the low level WebGL stuff to give people a really nice way to get 3D effects.

I think there is still some maturing to be done at that level before people go in there, but I’m definitely very excited to get then to the web platform as a native citizen. We’re also seeing similar things happening in the CSS3 side where a lot of the implementations of CSS3 are hardware accelerated now. There are fantastic frameworks out there like Sencha and SproutCore and all these guys that are taking that to the next level. So you as the programmer write into this really nice API and then making sure that everything they are putting into the screen are tying it to a native GPU accelerated layer so you get these fantastic apps.

Charles Jolley has done a great job showing this off. He has an application, an NPR application out in the US for the iPad that’s a native Ojective-C app, and someone in the SproutCore community in a week ported that application to SproutCore. You sit there with these two iPads and it’s like "What’s the native one?" and you flip around and one seems a little bit faster than the other, but you can’t really tell very well and it actually turns out the web app is the one that a little bit faster. It’s not to say that the web is faster than native at all, it’s just how it was coded or what have you, but it was really fantastic to see a demo that shows that this isn’t just smoke and mirrors and the web can be decent. It’s like "Here it is, in front of you. Play with it and see how it feels." It gets all these effects by using CSS3 mapped onto the GPU.

9. Let’s continue talking about some more HTML5 goodies. Canvas - what do you think about it? You mentioned Bespin and Bespin is based on Canvas. It uses Canvas to paint everything. How well does that work?

With Bespin we used Canvas because we actually tried Canvas as a last resort. To begin with, we did a Pure DOM approach and the use case we were going after was we wanted to make sure if you opened a massive file that the editor would still scale. Even if you had 15,000 lines of code, you don’t believe in refactoring, or you write bad code, whatever it is, it’s still just works. In Pure DOM that didn’t work because the size of the DOM was too great, so it would sometimes the beachball would come up and it would just be bad. We then tried the Virtual DOM approach where we were swapping in and out what was actually in there and that at the time wasn’t fast enough for the browsers that we were trying to target.

So we tried the Canvas approach where we were painting everything and one of the reasons was this performance reason, but another one was when we’re doing the design of Bespin, we wanted to do all of these very rich effects in the editor itself. We’ve been stuck in these text editors for far too long and we wanted to be able to do things. For example you’ve got continuous integration going that’s checking your code for performance and you can turn on an overlay that would show you "This piece of code over here is red. So optimize this code, don’t optimize the code just above it." This is all that matters, and then richer UI effects on top of it. We thought with Canvas we’d have the ability to do whatever we want; we have full control of what’s going on.

There were a lot of challenges to using Canvas. One of them we talked about a lot is obviously we have to work with text and when you work with text and you’re a font guy or a typography guy and you know all about all the details - ascents, descents - all of these different things that are going on. In Canvas you can take some text and you can get a text metrics object back, that object only has one thing - it’s the width. That’s it! That’s not that great when you wanted to do rich layout. We had to do cheesy little hacks where we would take the "m" character, take the width of that and put it on this side and assume that’s the height and things like this, not ideal.

Then we ran into situations with Canvas you traditionally are just painting all the time, you are painting the screen, but a lot of the time you don’t want to just repaint everything on top of each other. So we had to do our own dirty detection, which is painful. The browser does that for you automatically in DOM. SVG is the same - you can make changes and then the system will take care of it for you. We were able though to get the performance we wanted and to have pixel-level control of what’s going on, but there is a new editor called Cloud9 that I got to see at the JSConf in Berlin. They did a new version of the Virtual DOM approach and I think it’s fantastic. It’s really great to see the modern browsers now.

Even in two years since we wrote the original Bespin, it’s totally changed the game. They have these different layers where they have a layer that has the text; they have a layer that then does syntax highlighting and then they have other layers. So when you are actually selecting something, you are selecting it on a blank layer, it’s own div that you are controlling. I’ve worked with Fabian, one of the lead committers to that project and was able to do a bunch of testing on that because all of the things that we ran into, they ran into those same things: like getting "copy" and "paste" working in all the different browsers and how do you handle text. Because they are not just putting into a div, they’ve got a hidden text area that captures all of the keyboard input, which is exactly what we did in Bespin.

So there are a lot of corner cases in browsers that are in there, so I’ve been able to file some bugs and get some code. The beauty of Bespin, being fully open source, is that they can reuse that code and that’s been great to see. It’s really exciting to see the work they’ve been doing.

10. One other area that is often mentioned with text editors in the browser is accessibility. What’s the state of that right now?

The state of accessibility is interesting. There is a big brouhaha on the W3 lists talking about this fact. There are a lot of people that were kind of cheesed off about Bespin and then we’re just using Canvas and it’s not accessible, but I totally understand that. We thought we had interesting ways to give better accessibility. For example we had a framework called Thunderhead that was a Canvas-based framework where you would put in high-level semantic components that looked like XML or HTML and then Canvas would read that and be able to do drawing operations. So it allowed you to put things into place in a semantic layer, something that was able to read these things for you to be able to access. You can even put all of the ARIA roles and all that kind of stuff into it.

We wanted to spur on a conversation in the community about what it means to do this kind of stuff in an accessible manner, but there is still infighting over how you should do this and how you shouldn’t. We should make it as easy as possible to make accessibility be default because people are pragmatic and they’ve got limited time to code, so a lot of people are just going to do what they need to do to get it out there. I’m personally interested to see what comes out of this massive thread on the HTML5 working group.

11. HTML5 brings us many new capabilities, but recently there has been talk about problems with security and new approaches, new cross-site scripting, new vulnerabilities. Where do you think we'll be in a few years with that? Are we going to fix these things? Are we going to suffer from these things? What do you think?

Douglas Crockford likes to talk about security and how we should stop the world and go back and fix all of these security exploits. He was successful in the ECMAScript world of stopping JavaScript 4.0 of what it would have probably become and going back and just incrementing ECMAScript a little bit. Now we have this notion of ECMAScript Harmony and ES 5 and what’s going on. The big difference there though is no one had really shipped ECMAScript 4. It’s hard to go to all the browsers that have shipped HTML5 stuff and be like "Can you roll back all of those commits?" It’s just not going to happen! The web is an evolving entity; it’s changing all the time. I think it’s really hard to pause time and "fix" everything on the fly.

I empathize with Brendan. He talks a lot about this and now we’re constantly evolving the system and security is a very important part of the system and we’re going to be fixing things as things come up. As soon as you plug something into the network, there are security issues, so there is not going to be any kind of black box solution like "Finally! We fixed all of the security issues in the world forever!" It’s never going to happen. What we can do is learn about what’s being used and fix those things and use capability-based architectures and all of this great stuff and fix the areas in the glue. We found a lot of the attacks happen between the layers of HTML and JavaScript and CSS is in those little cracks that a lot of the security [attacks] always happen.

It’s obviously up to the entire community to come in and fix these things. But this is an ongoing race; it’s not something that we say "Now we’re going to fix security." We have to have all of the major browser manufacturers, the development community constantly vigilant and on top of this stuff. It’s great to see that these days browsers can auto-update in a much better fashion and it’s putting in that kind of infrastructure that’s going to help us long term.

12. We are talking about using HTML5 and JavaScript in web apps that are served by a server and we are also talking about local web apps like the WebOS applications. Is there a better word for "locally running web apps", like Phone Gap apps or WebOS apps? How do you call them?

I’m not sure. We often talk about cross-platform web applications as a way to say that you can build your web app once and deploy it across multiple platforms including iOS, Android, Blackberry, etc. using PhoneGap or another library that’s out there. At JSConf there was announced a project called "Unify". There was another kind of PhoneGap-like solution; it actually uses Phone Gap and builds things on top of it. We’ve seen a lot of these coming out into the world now as people realize the fact that there is a diverse ecosystem out there - Windows Phone 7 is coming out, all this stuff is coming out. And they don’t want to have to learn a new SDK every time a new platform comes out then, so a lot of people are rallying around the web and building all these toolkits. But it gets confusing because for example for Web OS, native is web, but other people think of native as C code. I definitely agree that they can get confusing.

13. You mentioned that current to the next Web OS version we’ll have NodeJS for services. Have you used NodeJS on the server? What do you think of NodeJS? What’s so great about NodeJS?

I’m definitely a big fan of NodeJS. I think that JavaScript has been tried on the server many times. Netscape came out with JavaScript on the server in 1998 and it never got traction. Aptana came out with Jaxer fairly recently, where they took Mozilla and took Firefox, chopped off the head and put it back on the server. I think that people are excited about NodeJS because it’s not just the promise of JavaScript to people like "What would it be like if you had the same language that’s everywhere?" You could take a bit of code and run it on the server or the client and be smart about it. There is interest in Smalltalky-like things that will happen there, but also it’s an event-based system on top of a fantastically fast runtime.

It’s V8 and it’s event I/O and the chap that kicked this off, Ryan Dahl, is a C++ hacker, he’s not a JavaScript hacker and he married these worlds together and by doing that he gives you a fantastically easy way to use JavaScript to build server apps that are going to scale very well out of the box. Again, I was part of the Rails community and I absolutely adored Rails and loved it. The thing that I didn’t like back in the day was deployment. Deployment was a pain, it kept changing all the time as people working out how to deploy this thing in a way that it scales. It was really painful. The developer ergonomics on building apps was phenomenal and changed the way people thought about how easy it is to develop web apps.

But with NodeJS, it’s kind of the other way: it’s built in a way that deployment is fantastic and it’s going to scale very well if you follow a few simple patterns and it’s going to really help you out. In building that now people working on the developer ergonomics around the fact that you got this event-based system, it’s callback based. How do you write code that’s not spaghetti code of callbacks and callbacks. We’re getting these high-level frameworks on top of it. But in the Ruby community I started to find there have been a lot of small services using things like Sinatra with very simple little applications.

That, for me, has migrated very nicely into the world of NodeJS, where I try and keep it very simple: RESTful services that my clients then access. NodeJS gives you that, totally out of the box in a fantastic way. The community is a lot of fun and I think it’s going to do fantastically well.

14. JavaScript performance has come a long way the last two years, since the V8 watershed. How much performance can we squeeze out of the language still in the next two years? What do you think?

With V8, with Nitro and the Safari guys and the Monkeys from Mozilla, they're doing phenomenally well. There is a website that Mozilla put up called Arewefastyet.com that shows you the different performance on what’s going on. I think we’re still relatively in the early days. I think there is a ton of stuff that can be done. If you look at the garbage collection schemes, they are fairly primitive compared to Java. Java’s got this amazing concurrent collectors and state-of-the-art stuff and we don’t have that yet in the VMs and as you get these longer running server side applications, you start to have these different needs, so I think there is a lot of room on the VM side.

We’re here in Aarhus where the V8 team is and they’ve got a lot of great things that they are working on. I think we can squeeze a lot out of it, but I also think it’s time to keep that train going and have those guys keep finding it out. That competition is fantastic for us all. But there are a lot of other areas that we need to focus on: we need to focus on getting the DOM in a place where it’s not in a ridiculously underperforming state. Then there is the networking side of things itself. HTTP wasn’t built for applications and it can be relatively painful. Google has this effort called SPDY; it’s a new way to get more out of the transport layer and I think it’s a lot more we could do about that layer that would really help us out on the performance side.

There are a lot of things when you look at the overall performance of an application. Having the VM in the place that it is now, is fantastic, but the bottleneck is being shifted to other areas. It would be great to see what happens there. One big thing has been hardware accelerating all of the graphic layers. IE 9 blew that one out with the fact that they accelerate everything and now we’re quickly seeing that Firefox has acceleration, Chrome just added acceleration, Safari has added acceleration inside there and we just got massive win out of all of these browsers accelerating all of the graphical stuff. That’s the kind of thing that people weren’t thinking about.

They were thinking about V8 and the VM layer stuff, but now we have a new way to do all of these amazing things. Some of the Canvas stuff that we were doing just screams now it’s hardware accelerated compared to what it was like before, so it’s an exciting time.

15. Lots of to look forward to. Thanks Dion Almaer.

Absolutely. Thank you very much.