Bio Dion Almaer has co-founded Ajaxian.com and has been a technologist and a developer writing Web applications since it took over from Gopher. He has been fortunate enough to speak around the world, has published many articles, a book, and of course covers life the universe and everything on his blog at almaer.com/blog.
The target audience for GOTO conferences are software developers, IT architects and project managers. GOTO Aarhus is an annual event in Denmark. The idea for GOTO (formerly known as JAOO) came about as the management at Trifork was dissatisfied with the conferences that existed and wanted to create a forum that would give the development staff inspiration, energy and desire to learn coupled with the chance to network with the IT community.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Absolutely. Thank you very much.
Subject is misleading