Thanks for watching. I'm Dylan Schiemann, I'm the co-founder of an Ajax toolkit, called the Dojo Toolkit. I'm also the founder of a company called SitePen. SitePen helps people build great Web Applications often using Dojo. I'm a big proponent of Comet and the Open Web and related technologies.
The main problem I see with the WML days was that WML sucked and it was a bad version of HTML, but it wasn't actually HTML. Then, they decided to come out with a version that was actually based on HTML, but still the user experience on this little tiny screen in black and white with a few characteristics at that time, was not an experience. Using the keyboard to navigate in weird ways and the whole experience was wrong. Also, at that time, the browsers on the web were not actually that performant for building applications and the technology that was used on the desktop could not possibly run on a mobile device.
Flash forward half a decade, just a few generations in web time, and you have platforms that you can pretty much be deployed anywhere. You've got WebKit , you've got Mozilla's mobile browser or you've got Opera's mobile browser or you've got Microsoft's new efforts. What you see is you can basically build applications that work, with the same technology, the same Open Web standards on multiple platforms. It's not that you write code once and it just works everywhere, but in a lot of cases it does work well enough and then you can optimize from there.
Then, you can start to think "How do I take advantages of this smaller form factor" rather than "Oh, I've got to learn something completely new from scratch!" We've seen some fragmentation now, in the form of app stores versus web devices, but what's cool is I see the app stores as useful for a couple of things. One is distribution and another one is access to native capabilities. Really, both of those I think are short term problems, that will go away as we see the web part of mobile devices become much more powerful.
From a Dojo perspective we thought about this a lot. If everyone is running Webkit, which may be the case - or may be not - but if a lot of platforms run web kit, yet they are all different. It's almost like having a whole bunch of different browsers. You don't want to have detection code that's 500 lines long for all the mobile devices, so you have to start thinking about things again from a feature detection perspective - "Does this device all me to have access to the camera? Does this device have SVG? Does it have canvas? Does it have this CSS animation?"
We have to start thinking about optimizing for capabilities. Historically, we've said "OK, here is our JavaScript assembled for this devices. Here is JavaScript that works on Firefox or we've got branches in our code that was based on browser version. Today what we would have to do was do that dynamically on the fly from a server or simple JavaScript that complies with those various conditions, otherwise we're sending down too many files or it's taking way too long to do this. The good thing is that we do have work in progress that makes this much easier to accomplish.
Actually, a lot of the CSS experimentations that have made their way into HTML 5 animation, transformations, etc. were done because Apple needed them for the iPhone - so, that's already the obvious case. The less obvious case is Web Sockets or Comet implementations because anything you can do to reduce the latency and conserve the number of requests between the device and the network the better. Having access to a raw socket that's understood and easy to use and fast is much better than having to pull the server every 10 or 5 seconds in the case of a chat client or something like that.
In terms of semantics I think that it's an improvement that's equally valuable to the web and the mobile web. Those are probably the major things that I think are directly relevant. Some of the audio and video, of course, it goes without saying, I think the devices still has to support a codec to make that work, whether it's a Flash codec or H264 raw or Ogg Theora, etc. you still have to have that available on the device.
It does. Functional testing few years ago wasn't even possible and now it's dreadful and it's still pretty dreadful on mobile devices, but fortunately people start with emulators. They start with emulators because if an emulator is good, it solves 90% of your issues without having to have each mobile device working. There are people who write basically Firebug light that works in the browser and you can put in on a mobile device and then report back all the data and information to the server. Don't try to use the mobile device to see the results.
What would be really interesting is a way to automate testing on a mobile phone and in the case of a jail-broken iPhone or in the case of an Android device there are attempts and works in progress to do just that to basically set up functional tests or run something multiple times in your browser and then send the results to a server that you can use to record it.
If you actually think about it, it's a really powerful use case for having a web server that works locally on a mobile device, because that server could communicate with a remote server and then use that to spawn a process or to a batch job tested on a device without someone having to sit there running each test and seeing if they work. I think there is a lot of possibility if you start to think about a mobile device as a lot like a computer, where you can start to add those different layers of tooling to do those tasks, but there is a lot of work to be done to make that ideal.
I wouldn’t say so specific to HTML 5. I'm almost concerned that HTML 5 is the new Ajax in terms of buzzword bingo because both describe everything that's new and promising about the web. Ajax started as a definition of how to communicate between a client and a server more efficiently than a full page reload. Eventually, it came to mean everything involving JavaScript.
HTML 5 now, is a very large spec and basically it's an attempt to standardize or improve all the things that have been done in the web browser for the past 10 years. Because HTML hasn't really evolved much standards-wise in the last 10 years. It's just this effort to say "OK, breathe for a second. Let's standardize and let's rebuild on these standards." Of course, tools of all kinds are going to need to support that, because that's the next generation and current generation in some cases, language being used to develop stuff on the web.
It depends on which part of HTML 5 we're talking about. If we're talking about forms and raw semantics, you actually already define every HTML 5 element in every web browser on the market today. You just have to give it a style definition of display block. It may not look the way the HTML 5 world intends it, but then you could use JavaScript, like Ajax, Toolkits, Dojo or Dean Edwards work on HTML 5 .js, etc.
There are a lot of different efforts out there, but basically it's a lot like using Dojo right now, where you take some HTML and your upgrade it to the HTML 5 features. Say you've got a calender widget, like a little date box you want to pop up. Right now, the way you do it is you've got a little icon that looks like a calendar and you click on it and it pops open or you start typing some text that pops up in the calendar. But if you have a browser that doesn't support that version of JavaScript, you still can type in a date.
It's the same kind of thing: we would use JavaScript to upgrade the non-HTML 5 experience to the HTML 5 experience. Yes, for those things there is of course a need for compatibility layer. Other things - you have to rely on Flash, for example native audio and video. Without the HTML 5 capability you have to fall back to Flash or Silverlight or something else.
It's funny you mentioned this because I just published a blog post about "Can Flash thrive?" And my answer is "Yes, if they drastically change". What's happened is, for a long time, they were able to innovate faster than browsers because browsers were Netscape and IE and they were slow. Flash came out every 3 or 6 months with a new version that was faster and did more cool things. But it was separate.
For example, why is Flex our language? Why is it not HTML enhanced? What they've done is they've created their own ecosystem where is "Yes, you can use HTML with Flash, but really it's about starting with the Flash studio and maybe you pull in some HTML or maybe Dreamweaver will generate some HTML for you, but it's really about living in their stack. To thrive in a world where the browsers are moving faster than the plug-ins, they have to find a way to coexist.
For example, maybe a browser that doesn't have a nice grid control could include some HTML and maybe the Flash component for a grid could be used and could be faster. Or maybe they move towards a Flex 5, it is HTML based. That way, anyone who writes HTML could also take advantage of Flex semantics and then of the Flash plug-ins installed. It just auto-upgrades that part. You can almost think this as what Google Chrome is doing, but Google Chrome is doing it in a very open way. The browser is open, the technologies are open and it only upgrades when the user has it and the developer requests it.
You could see something similar with Flash and their rendering engine or Silverlight and theirs as well. I actually think the world of plug-ins is not necessarily dead, but where it becomes less interesting is on mobile devices. Mobile devices kind of killed the plug-in model, because mobile devices get upgraded much faster traditionally than browsers do on the desktop, because people get a new phone every year. Phones die, you loose them and you are always getting the latest and greatest so the need to support really old browsers on a mobile device goes away.
The advantage of a plug-in was to be able to upgrade the web faster than the device could or the browser could and that edge is gone. I would actually say that the average mobile device now has a better browser than the average desktop device. I say that because there is no IE 6 or 7. The average web kit version is much better than the average IE version.
Yes. Or 3D accelerated graphics. If you need to do a game on the web and the browser doesn't support native hardware acceleration. You can also see it for experimental things. Google Gears was created as a way to experiment on the web. It's become less relevant now that most of that's been pulled into HTML 5. Gears is being at the end of life because all the new browsers support all the key functionality natively.
There is no reason that people are working on and others are working on a 3D graphics acceleration plug-in, there is no reason that they won’t to be eventually pulled into browsers themselves. But the assumption that you are going to create an entire ecosystem that's separate from the open web and succeed, the cost is just too great. The cost to get people to develop for it, the cost to market it, the cost to actually invest in it in a way that's greater then the entire Open Web, just doesn't make sense.
That's a big question - maybe we'll split it up. The first thing I would recommend is you need to decide if this is an application that can build on the web or not. You may still want to deploy it as application in stores for distribution, but is it something that's inherently a web application or is it like a 3D game? Right now, 3D games and such need to be native. Even the work Palm has done is towards native APIs for games.
Assuming we're talking about web applications, because that's my expertise, you are going to focus on these in web technologies, but there are a lot of things you want to do that may be native capabilities - camera access, GPS, local file system, contact information, etc. There are a few options out there, one is called PhoneGap. PhoneGap let's you basically wrap up your application with a thin shim, using JavaScript two native APIs and then they help you deploy it to the iPhone to Android, to Palm, etc. without having to learn any of those platforms specific devices.
Because you don't want to have to learn Objective C and C and Java and Windows or whatever they are using on and on. Another option like that is Appcelerator titanium. They've taken a very similar model to Phone Gap, except the way they compile it is a little bit different and they do a few other things that are quite interesting. Both are open source, which is nice, because you have a choice. PhoneGap might be appropriate for one thing, Appcelerator Titanium might be appropriate for another.
Appcelerator Titanium is almost like AIR combined with Phone Gap with some developer tools.
From the Dojo Foundation perspective we're also working on a version of Dojo that is more optimal for mobile devices. Basically, we try building the same raw APIs, but re-engineering them for mobile devices. For example, the animation engine, perhaps replacing CSS animation wherever possible or things that just don't make sense, like Drag-n-Drop doesn't really make sense to their mobile devices, just don't support it.
You strip out the APIs that aren't usable any way, add in support for a mobile stuff, so add in support for camera access, etc.
There is a proof of concept of this from the guys at Uxebu, called EventNinja and it's an app that is deployed on 15 or 20 different mobile devices already on app stores for all of them. Basically it uses this light version of Dojo that's under development plus Phone Gap where appropriate and they deploy it to all these stores and it works and that's pretty neat. As far as pitfalls and best practices, I would say that there are a lot of things to take into consideration.
One is user experience is often very different under constraint environments, it's much like developing for users that are using their applications during a conference, so they are using hotel WiFi, expect lots of drops and intermittency. For example, I love the application for traveling, which is TripIt, except the mobile device. I don't like one thing about it, which is when it first launches you see your list of trips, but if you try to click one it says "I'm checking for updates. Wait." I understand the need for that, but why are you showing me the options, yet blocking me for 30 seconds to do that check.
Why not just let me into it and then if there are updates, find a way to update me then. You have to consider this experience may be a lot different than it might be on you emulator where that changes instantaneous. Going down the proprietary wrap or relying on technologies that are open is probably a bad choice, relying on cookie cutter tools. You wouldn't use FrontPage for you applications so why would you use a cookie cutter tool to create 50 iPhone apps? Think about the longevity of your technology stack and how it fits into your entire process. Those are the approaches I would take.
11. Dylan, what is the road map for HTML 5 and for the Dojo Toolkit?
HTML 5 is obviously a very big specification. If we first look at the semantic markup and the components, Dojo's digit in many ways already implements many of these features just using different semantics. For Dojo 2.0 we would likely take the HTML 5 semantics as the foundation and build and improve on top of that.
With the 1.X Road Map we guarantee backwards compatibility so we would make such a drastic change, but the cool thing is right now you can use Dojo and get pretty much all the functionality you would get on that layer of HTML 5. On things like animations and transitions we have work already in progress in our extension system to support that in Dojo or to make that easier for Dojo developers to take advantage of. For things like web socket we have supported our DojoX Cometd implementation for that.
Basically we've always been very pragmatic. We take advantage of whatever is there, extend upon it, build upon it and we'll just continue to integrate it into Dojo until it's everywhere and we're building on top of it. For anything that's redundant, we drop code for that. We wouldn't re-implement it just to re-implement it, we would build on top of that because that's the logical place to start.
12. Would you like to tell us a few things about the Dojo Foundation?
Sure. We started the Dojo Foundation so that it wasn't copyright Dylan and Alex 2004, which we thought would be silly. We really respect intellectual property and freedom. Dojo was designed for adoption and not control. We used the BSD license scheme, so that basically anyone can use it however they want and people can easily contribute. You don't have to get back, but you can. The Foundation was established pretty much the same way - for adoption and not control.
It's very minimal, it's very well processed, just work on your code and there is place that holds the copyright and there is a place that receives donations and can give out T-shirts. We probably spend more time talking about T-shirts on the Foundation level than actually foundational structure. We invite projects that have those same values on the open web. Other projects include the very exciting Persevere, which is a non-relational database combined with really nice JSON semantics and Comet and other implementations that can build on top of all the exciting servers like JavaScript implementations that are coming out like Node.js and Rhino and Narwhal and Jack and all of those.
We invite projects like that are interesting. DWR is part of the Dojo Foundation, Sizzle which is the selector engine that's part of jQuery and optional build for Dojo is also part of the Foundation. I chose how we'd like to work with others because "that's the guy that started jQuery started out and why would you do that for Dojo Foundation?" To show that we get along and we'd like to work together. We have 2 or 3 projects that we're working on right now that will improve the mobile landscape very soon that are going to be part of the Foundation as well, probably in the next month or two. Maybe by the time this interview airs actually.