Guten Morgen. Anyway, buona sera. Beg your pardon? Guten tag, of course. Ja, voll. Thanks for coming and waking up so early. I hope you're enjoying Fosdum.

And... There's my remote. I'm Dylan. I work on a project called the Dojo Toolkit. And I also am the founder of a company called SitePen, and I travel a lot, and I love what I do. Today, I want to talk to you about high-performance web applications with Dojo, and how many of you are familiar with JavaScript?

Alright, how about Dojo? Okay, awesome. And another toolkit besides Dojo. Alright, great. So I'm going to blaze through the Dojo stuff and get onto the app stuff. I don't really practice or prepare my talks. I just talk about whatever seems interesting at the moment.

The one thing I would hope you take away from this talk and any other talk is that it's all about choice and freedom with your code. So Dojo and projects like MooTools and jQuery and whatnot, pick what you like, pick what works for you, and go with it. And I'm just going to expose you to a bunch of different approaches.

Even when you're using Dojo, you could build an application a million different ways. So I'm just going to talk about some of the things we do that work for us in various projects and various applications we've built, and give you some ideas. So, very quick history lesson. You know, how many of you were DHTML developers?

Very few, right? I'm proud to say I was a DHTML guy. But browsers sucked, and you know browsers suck less today than they did back then. But the problem was people just didn't take JavaScript very seriously as a language. And then Google Mail and Google Maps came out, and people woke up, and you know the buzzword called Ajax was coined.

And it suddenly became a real platform with real goals for building products, right? So when we're thinking about you know, toolkits, we're actually thinking about how do I give my users the experience they want in an application that matters, right? So I want something that's web-delivered. Why? Well, so everyone can get to it without having to install a bunch of software.

I want something that I can build cheaply, right? The whole point of open source software is to build on the collective knowledge of everyone else rather than having to reinvent everything from scratch. At least, you know, that's one goal. You want your application to be useful and engaging, of course. Otherwise, you have great technology and a terrible interface and a pointless application.

Well, great. Open source the technology and do something else with your career because the application you're building sucks. You want, you know, some people have tried to basically create toolkits where they take the entire desktop and bring it to the web. That's kind of not the point, right? Because the web gives you so many other things like linking and remixing and

searchability and all of these features, and it's not, and you know, not pixel precise precision, but a layout in an application that works in any size screen, you know, within reason. Obviously, if your screen's 10 pixels wide, you can't do much with it. But the idea is give your users the best of both worlds, not just, you know, cloning Outlook and putting it on the web.

So, when we set out to build Dojo, we said, all right, what's wrong with the world, right? And at the time, this is 2004, and a number of us had worked on other toolkits. They still supported Netscape 4. Fortunately, we could say Netscape 4 is dead. We're done with it. Hopefully, version 2 of Dojo can make the same decision about IE 6 and 7, because that would be really nice, right?

So, I have my own unofficial math, and I say we waste billions of dollars a year developing and supporting for IE 6 and 7. So, it pays a lot of our paychecks, but at the same time, we could be doing a lot more interesting stuff with our money and time. So, we had, we have a bunch of gaps in the browser, right? If we look at the things we have to build with,

they're actually pretty basic. You've got an HTML DOM that has, until now with HTML5, very boring, rudimentary form controls, you know, like submit buttons that look terrible, and a file upload button that you can't style, and you just, you get really ugly, crufty interfaces.

So, but beyond that, like Ajax, right? XML HTTP request was a complete hack that was shoved into IE at the last minute, because the beta code freedoms had passed for IE 5, but XML was cool and a buzzword, so they could call it an XML HTTP request and stick it in and shove it in. But the API was terrible and not well thought through, so you look at it, and it's just, it's ugly.

So, you know, all the toolkits try and make it really clean and simple. CSS, whether you're manipulating classes or, you know, trying to just get your page to start out at the same point and look the same in browsers, you know, within reason, so, you know, setting default rules, or whether you're trying to manipulate the CSS object model, so add or removing styles from your CSS style sheet.

It's just hard to do. DOM manipulation, I mean, W3C guys mean well, but dude, what the fuck is up with your APIs? Just, like, get element by ID, get elements by class name, but then all the things that are missing, like, give me a query, and I mean, querySelector all is there now, but why wasn't that there 10 years ago when people were asking for it every month?

JavaScript doesn't have a concept natively of packaging, right? So require this module, it depends on this other module. Why not? You know, browser vendors have moved at very different rates of speed, right? So Mozilla and WebKit have moved very fast, and Opera as well, relative to IE,

which doesn't support a lot of things that we expect. Awkwardness, you know, the language is sometimes too flexible, so you have just so many different ways of doing so many different things, and some of them are just slightly subtle, and if you're not a JavaScript expert, you can easily go down the wrong path using those. So just clean those up a bit. And then thinking about the future, right?

So Dojo has been doing vector graphics for a long time natively using, oddly enough, we support SVG, Canvas, VML, Flash, or Silverlight. And we do that because we want you to have fallback options for drawing vector graphics, but not be stuck in any one particular environment. So browser gaps, right? Browsers have problems. Development gaps, right?

So tools for browsers and development are way better than they were five years ago. Imagine building an application without Firebug today, right? Or without Web Inspector. It's like coding in the dark, which is what we used to do, right? Or, you know, just having higher level constructs, like give me a chart, or give me a grid, right?

And an HTML table, while it is grid-like, doesn't give you, you know, column resorting, or drag and drop, or editing of tables. It doesn't, you know, there's a spectrum between HTML table and spreadsheet, right? And we all want some subset of features in the middle that we would call a grid. And finally, I say real development platform, right?

So we are real developers. We're JavaScript people. We can build real applications. So give us the tools and the code and the environment that we need. JavaScript is so flexible, yet so incomplete, that we need tools and better options to make it what we need it to be. So Dojo just started out as a project where we said,

we want to get the most out of the web. And we started writing code in 2004. In 2005, we started a foundation to host that code, because we didn't want it to be copyright Dylan and Alex, 2005. We thought that was kind of lame. When we came out with 0.1 and 0.2, IBM and AOL and Sun became very interested in Dojo, which is cool.

So they've contributed time and effort over the years. And we did a complete rewrite in 2007, because prior to that, Dojo was really slow. And it was called 0.4 for a reason. It wasn't ready for primetime production. It was us still figuring out what we wanted to build. And Dojo became really popular at 0.4, which is too soon for it to become popular, in my opinion.

Regardless, I mean, the Apple store still uses Dojo 0.4 on their website, which is, I mean, it works for them, so it's fast enough for what they're using it for. But I wouldn't use 0.4 for anything today. And so our goal is basically two dot releases a year. The forward's compatible, they fix bugs, they add features, etc.

And then we're working on a 2.0 release sometime, probably in 2011, is my guess. So Dojo has goals, right? It fixed those things I was just describing about the browser gaps, development gaps. Be fast and efficient, right? Performance is what everyone cares about. If your application's slow, you're going to move on to another toolkit.

Or someone's going to tell you to choose Silverlight or Flex, which is not necessarily faster, of course. We want to be professional and sophisticated and powerful. And those are interesting words that I'm choosing. Power, meaning give developers the power to get every last ounce out of the browser.

Not just give me the parts that only work in every single browser on the market. Let me push the limits and get the most out of this platform that's really exciting, right? Professional, meaning we don't want corporations to have any reason to not choose Dojo. And we don't want any of our users to get sued for ever using Dojo. So we have a fairly conservative IP approach.

It's much like the Apache Foundation, where basically you have to sign a license agreement that says the code you're giving Dojo is yours to give, and you're not going to sue for it if someone else uses it. And it's important because it protects your rights. But a lot of people just don't care. And maybe we shouldn't care, but we do. And so certain companies love that, and other people just don't care at all.

Obviously, we are licensed for adoption. We're BSD and academic-free licensed. We intentionally did not choose the GPL because it blocks some companies from using it. And GPL is great for certain types of projects. For Ajax toolkits, we just want everyone to use it in whatever way they want. If they don't want to contribute back code, we don't care.

But most companies and most people do contribute code anyway. So that's great. Dojo today is split up into a few levels. We're actually kind of reworking that, and the names and distinctions really aren't all that important. But the idea is that Dojo and Digit are stable APIs. They're not going to change from major releases except for additions and bug fixes,

which will be noted in the release notes. And DojoX is the official extensions of the Dojo toolkit. So dojo.js gzipped will give you pretty much everything you need to build a basic application in 26k. And then you can add on any other libraries that you want. I'll show you how in a minute. Digit is both a widget system and a collection of widgets,

and I'll go through that in a bit as well. If you were to work on a Dojo application today, you probably in your first day would use what's on this screen. And basically it's just a simple set of APIs. You'll notice if you've used jQuery before, it's structured very differently. This is more traditional.

Yet APIs in our toolkit are fairly flat. So you don't see a lot of foo.bar.baz.zizzy.zizzix.whatever because that's really expensive in JavaScript, especially in IE, to have object structures that are nested that deeply. But you can see we've got packaging stuff. We've got stuff to handle loading. We've got stuff to grab nodes, set attributes and styles and behaviors,

creation of nodes, Ajax, effects, caching and hashing. So for back button type stuff. Declare for creating classes. The next talk you'll see new tools. It's the same thing as dojo.clare is basically equal to new class in new tools.

dojo.data, which I'll get into in a bit as an advanced topic for application development. Charting, vector graphics, you may or may not care about that. DTL, that's the Django templating language re-implemented on the client side so you can use the same template server side and client side. And of course accessing the grid. The grid is by far the most popular widget and it's not actually an official widget yet

because it's so in demand and so under development still. So I said JavaScript applications or JavaScript in browsers in general don't have packaging, right? So we provide a very simple mechanism. And what's cool about JavaScript the language is all it actually is is calling a function with a string name.

You put it at the top of a file and you say this is what I'm giving you and this is what I'm requiring of those modules. And then dojo behind the scenes just reads that from the file and goes and makes sure you have all the dependencies in place in the right order. Now when it comes time to ship your application rather than loading in 50 scripts that you need there's a quick build step or a compilation step that will go through

and based on how you define how you want your code optimized it'll grab all the files, optimize them, strip comments out you know, stick them into a single file or multiple files and make it really easy to use. Probably the biggest thing that people run into when they start getting into JavaScript and are just enough to be dangerous is timing bugs.

So for example the classic problem in IE6 is trying to manipulate the DOM before it's actually loaded and so dojo and other toolkits handle that problem as well. DOM manipulation, you know, like I've said the normal API sucks so dojo of course gives you a lot of stuff to work with that.

There's also a little project on Google code called PlugD and it actually basically takes most of the jQuery API and wraps it around dojo so if you like jQuery and you want to experiment with dojo grab PlugD, use it with that and you get most of your familiar APIs as well. There's also a dojox.jq experimental module in 1.4.

Events. So most people when they first start building applications see that, you know, there's onClick and there's onMouseOver and onMouseOut and your simple DOM events. We take events to a different level. We think of DOM events and function-to-function calls as basically the same thing. So basically you connect one source object and source function to another target object and a target function

and we do that because then we can just simply think of it all as the same thing. One thing you'll notice if you're not familiar with JavaScript is that the name of the function is actually in quotes and that's because while JavaScript is a very dynamic language in a dot dot dot dot dot syntax the last thing in your list has to be the actual name.

It can't be a variable representation unless you put it in brackets. If you put it in brackets then it can be a variable name. So if we pass a string in, so we couldn't just pass in object1.foo because it would be looking for something that was actually named object1.foo when we call it inside our private method. So that's what we do.

Dojo also supports a PubSub model. So if you want to publish or subscribe to a collection of topics, they're just named topics. Most people follow a sort of URL style pathing mechanism much like ModPubSub or Jetty, CometD, that model. So if you use some, well, how many of you know what Comet is? Okay, a few of you.

Comet is Ajax but faster and actually the ape guys are back there and they have a Comet server or an Ajax push engine or an async push engine, whatever you want to call it. But there's a number of different approaches you can take to that. One of them is PubSub model and Dojo supports that. Ajax is much simpler. I'm just going to leave it at that.

I've got too many slides as always. We have a nice effect system. Those weren't actual Dojo effects, but I'm just trying to illustrate the point. Drag and drop support. Of course, some newer browsers are starting to support it in certain ways. Drag and drop is actually a really hard problem to solve because everyone wants it to behave differently. So in addition to providing some good defaults,

we provide very nice extension points throughout the drag and drop process so you can rewrite how you handle drag events and how you actually display what happens when someone's dragging, that sort of thing. We, a lot of toolkits, of course, followed this, but IBM was a big contributor to Dojo. And IBM works with a lot of large agencies

where accessibility and internationalization are key. So Dojo has made a huge investment in making sure all of our widgets are fully accessible through keyboard, blindness, color blindness, just inverted screen colors, all that sort of stuff, as well as very localizable. So we have translations in a bunch of different languages,

a very simple way to provide your own translations for your own widgets, et cetera. Dojo.declare. So JavaScript has classes, sort of. It's a prototypal inheritance-based language with some class constructs bolted on top. But the syntax to do that is actually pretty ugly.

So toolkits try to make it really easy. So you just say Dojo.declare, the name of the class you want to define, the things that it inherits from, the first one being the one that it strictly inherits from, and all the subsequent ones being things that are mixed in. So mixed in, meaning you basically copy the methods and properties and push them on,

imprint them on top of your existing function. And then you can have a constructor and then just a number of parameters as variables or objects in the form of functions. So Digit, why a widget system, right? So a lot of people use Dojo for its widget system.

In fact, in my recent survey of why people use Dojo based on what people use Dojo for on the public web, every site I could find uses Digit as well as Dojo. So the cool thing about Digit compared to like, EXT's widget system per se, is that Dojo has always really been about

a system to build your own widgets easily, and we give you a bunch of nice ones out of the box, but we're more concerned with actually giving you a platform for easily building your own widgets or extending the existing ones. So they're very themable, it's very consistent in the API across all the widgets. That wasn't the case three years ago, but that's the case now. And the thing is, we want people to be able to think,

okay, I've got a tree and I've got a grid. Well, don't use trees, because I hate them. But if you like trees, you got a tree, you got a grid, you got a chart, right? But still under the hood, it's still just DOM nodes, some HTML code to put those into the page, some CSS to style them, and some JavaScript to define the basic behaviors of that.

So all of our widgets are basically an HTML file, CSS file, and a JavaScript file. And we do a lot of nice things to encapsulate the behavior so that you can have multiple widgets instances on a page and not worry about ID collisions or naming collisions and that sort of thing. I think I already talked about that, so I'll skip that.

Lots of features, lots of themes. We're actually working on two new themes right now for the 1.5 release. One of them is actually a port of the Cappuccino Project's open-sourced Aristo theme, so we'll call it AristoJoe, because everything has to have that Joe at the end. We actually have a Jojo project that's a spoof of jQuery and a Mojo project that's a spoof of MooTools and whatnot.

Anyway, that version, because I like to just stray. You can classify our widgets in a number of ways. We've got things to do, layout. So you can do desktop-style layout. You want the app to take up 100% of the screen, have this much to take 30%, include a splitter, that sort of thing. Form controls that replace the default ones

and give you things that are much better, like calendar controls, that sort of thing. How many of you have ever tried to build a WYSIWYG editor on your own? How many of you wanted to shoot yourself in the head after you were done? Keep them up. It's an exercise in futility, because it's one of the few things where Internet Explorer for a while,

and maybe even today, has the best API, but I will say that it was probably created with the intent of making it possible to think you could recreate Word, but not quite. So every boss wants you to say, well, this doesn't behave like Microsoft Word. What's wrong with this editor? And everyone else copied the API to basically make it also not possible to recreate Word in the browser.

And so it's this terrible exercise in futility, and there's good projects out there. The Digit Editor is pretty good, and there's other editors out there. I think there's actually two editors in Dojo, because one is iframe-based, and one's not iframe-based, and it has impact on back button events and other things, and it's interesting. There's a lot of widgets. I got interested in Dojo,

because I was very interested in vector graphics. I actually got interested in JavaScript, because I was a physical chemist, graduate student at UCLA, and I was studying the topology and rheology of quasi-two-dimensional foam. So if you're sitting looking at your beer tonight, and you've got bubbles moving around, I was studying the physics of that, which is really cool. And I wanted to put that on the web. I wanted to be able to draw that

and show people what that meant, why would I care? And it's actually a really interesting science that I won't go into, because I don't want you to fall asleep, and it makes me fall asleep pretty quickly too. But I got hooked. This is like 97, and of course you couldn't do anything like that in the browser, not with anything except maybe an applet, which was just terrible. But I got hooked on JavaScript. So for me,

native vector graphics support is key. And the way I really got into open source was Adobe killed the SVG Viewer project when they bought Macromedia. So I had a nice SVG Viewer that would let me do this stuff, and then they killed the project. And it took years before native browser capabilities caught up. So at Dojo, that's been a major driving force

for me and my interest in Dojo early on. Again, we just try and do stuff that people say can't be done, and we try and find a way to do it. And what's cool is within a couple years, we've got it done, and it works well, and other people do as well. And it's not like we're the only people that experiment, but it's a big driving force for Dojo.

So Dojo also includes a lot of tools. And most people don't know about these, but they work with any JavaScript code. And in fact, there's a lot of overlap between our tools and other projects' tools. Of course, everyone has to write their own tools because they don't know about other people's tools. You know, we just kind of sit tunnel vision and just think about our own stuff, which is what's great coming to conferences and talking to people from other projects.

I keep pointing to Mr. Mootoolz over here, not the founder, and of course the founder, Valerio, somewhere in the audience. I don't know where he is. But anyway, lots of cool tools to do things better, to generate documentation on the fly for your source code and Dojo source code, to do unit testing, run thousands of unit tests in the browser, do continuous integration testing,

functional testing by writing your own tests and pulling Selenium or Windmill into the fixture, that sort of thing. So applications with Dojo, right? So we have a lot of goals related to performance to get our applications working fast enough in browsers. HTTP request simplification, no timing bugs,

small code size, optimize, optimize, optimize. People come to us all the time saying, how do I make my app as fast in IE6 as it is in Safari? We chuckle. We say, what do you really want to do? What's a reasonable amount of time? We look at the code. We find the bugs and we fix them. But sometimes the most benign things can cause a second delay in IE6 or IE7 or even Firefox.

And so you just have to use the tools, look at the data, find the bugs, fix them. But there are things you can do to structure your application to make it easier, right? So people often make a decision, OK, I'm going to do a single page app because I want everything there and I want to pull stuff in. And then the app becomes so large that it takes 10 seconds for the page to load. Well, it kind of defeats the purpose

of giving people a fast experience by having it all there by making it take forever to load. At that point, you might as well split it up. So what you can do is you can grab code, pull it in as needed. So say you've got an email client with a calendar and an address book and an IM client, right? So you might start by just having the mail client load. And then when people click on Calendar, you grab the calendar code and shove it into the page.

And then when people click on the IM client, you might load that. And the reason for that is you can optimize based on usage patterns. So maybe 80% of your users use email, 20% use the calendar, 30% use the IM clients, so you can optimize based on behavior. Of course, you can optimize on feature loading as well, which is sort of what I was just talking about.

But it's basically you have an initial loading step, some prefetching of stuff you expect them to use after the application's already responsive, logical caching of things, another approach you can take is, here's my dojo code, which is stable. Here's my digit code, which is also stable, but I may pull in other digits later. Here's my custom code that's stable,

and here's my custom code that's changing every day. And so you might build those into four separate layers, so that the first three get cached more aggressively than the fourth one, which you're changing every day. Larger sites are starting to use statistical analysis. It's basically each week. They update their optimization strategy, or even every day maybe, based on how people are actually using the site. So if you look at a large site like Facebook,

you'll notice it's constantly changing, and it's constantly getting faster. And I guarantee that one of the ways they're doing that is they're looking at usage patterns for users, well, obviously usage for users, right, and pulling in what's needed and what's not needed, and then dynamically changing how that happens over time. You might also think about how to,

there's the classic Microsoft problem, or I think they invented it, but this is one of those interview question problems. You've got something that takes one minute to get across a river, two minutes, five minutes, and 10 minutes, and how do you get all four of those across if you've got one rowboat that can seat two people at a time? And the key is to put like things together, right? So if you think about it,

delay your media. Get your initial DOM in place, then go grab your media, then go grab certain things. Think about how frequently things need to update, and just sort of structure them in logical ways. So what are some of the approaches we take? Well, I keep talking about builds and compilation, and all that means is we're gonna take a bunch of JavaScript files and shove them together to reduce the number of requests,

and we're gonna do it in a very logical way. And what it does is that solves a lot of timing bugs, because of course all your stuff is in one file now, and you're not doing stuff that's stupid. Oh, one more point. And of course, moving stuff to CDNs, right? So pretty much any of the major JavaScript toolkits you can get off the Google APIs page.

So if you just wanna use Dojo or parts of Dojo, you can just point to the Google APIs link, or actually there's an AOL one also. And the nice thing is it's just cached, so if you and you and you write an application, and you all use the same Dojo, and your users go to all three applications, they don't have to reload it three times, if they're caching this logically.

I talked about that already, so I'll skip that. One thing we're actually working on is, so I've been talking a lot about builds and having to do this in advance, and that's kind of annoying, because it kind of defeats the purpose of just being able to write and go. You know, we'd love it if the web was just smart enough to handle this. So some of our clients, and when I say clients, I mean SitePen,

when I'm talking about the toolkit, I mean Dojo, so I'm not doing a good job of switching hats, but whatever. Some of our clients have thousands of different configurations, because each client might pay for different features in the software. And imagine trying to test and optimize and make sure thousands of different configurations were working at once. So it's gotten to a point where we need basically a dynamic build system.

So basically you just define a URL that you call that's the list of the modules you need, and the server will build it on the fly. If it's already built, it just grabs the cached version, and if it's not, then it builds it, and it needs to be like sub-second to do that. And we have a working version of that that we are probably going to open source in the next month or so.

We're working on modules for Apache, a Python module for Google App Engine, and something for Persevere as well. You know, thinking about sync versus async, I have this weird theory that everything is both sync and async depending on the time scale you look at. So if you look on a small enough time scale,

something synchronous, if you look on a large enough time scale, it's asynchronous. But when you're writing your application code, you should be thinking of everything as asynchronous so that you can always not block based on that behavior. There's a lot of different ways to optimize based on that. I'm a little short on time, so I'm gonna keep going. Sorry, Steve Souders wrote a couple of excellent books.

High performance websites and even faster websites. They're very good, but there's basically multiple ways to include your script in a page. And they all have different trade-offs. And some of them work in different browsers and different ways. And he has a decision tree based on what you're trying to do on which technique to use.

Yeah, I don't need to go into that. But you know, one of the reasons Ajax became popular was, oh my god, there's this concept that you don't have to reload the page every time the user does something, right? And of course, we've known that from the days of JavaScript, and we had done user behavior, but we hadn't really said, or I can load new data,

or I can load new components, or I can do form posts in the background and get stuff back. And that's what Ajax and what Comet are for, is to optimize that user experience. I went to a talk about JSF. Does anyone here like JSF? No, good. I don't either. Not that people don't use it with Dojo and enjoy it,

but it's not my cup of tea or whatever, Forte or whatever you want to say. The point is, I went to a talk in 2004 from Craig McClanahan, and we said, he was giving this great presentation with the typical Amazon store demo with JSF, and it was really awesome. And we asked two really dickish questions. One, does it scale?

And two, what if you just want to reload part of the page? And the answer for scaling was, well, it scales to hundreds of users. And everyone laughed because he's throwing Amazon, right? It's got millions of users. And then the other thing was, can you just reload part of the page? And he said, that's an area that's ripe for innovation. So we knew we were on the right track because he didn't have an answer for it.

Now, of course, JSF, the latest version, does have an answer for it, but at the time it was like, wow, the world's thinking about these technologies, and they're not thinking about how to just improve the user experience and make things faster in the background. Now, Comet is interesting. It's been around in some form since the late 90s, and the idea is it's a collection of techniques and protocols to allow you to push data

directly from the server to the browser, or give that type of responsiveness in the form of long polling, or faster than just normal Ajax requests. Obviously, I'm big on code size and maintainability. There's a lot of different approaches you can take. Obviously, we've talked about building, optimizing, crunching patterns.

I don't know why I said to see the talk on Friday morning because I forgot to update this slide. Yeah, I have a talk online that, actually, with Aaron Newton, comparing Dojo and MooTools for patterns, and I think it's on Aaron's site. You can find it. If not, email me or tweet me or Facebook me or whatever. We're big into kernel patterns.

We're big into RESTful approaches, but we also offer RPC-style approaches as well. Dojo has a thing called dojo.ready. Basically, the idea is, if you're gonna do anything that requires the DOM, wrap it in a dojo-ready block instead of just putting it straight in your source code, and that way it doesn't get called until the DOM is ready in the browser. You can actually also recursively nest dojo.ready calls.

Basically, when the top-level stuff is done, the next level down will get called subsequently, so it's a nice way to require different layers on the fly or pull other code in as needed. Any time you're building a big application, especially a single-page application, you'll probably want to use a kernel-style pattern.

People may call it something else, but the idea is that you want to have a lot of configuration options, perhaps, maybe based on a user, load their settings, load which modules you're gonna show on a page, maybe their preferences for how the application is laid out, that sort of thing. You shove it all into a kernel, and it's generally just a simple little pattern.

Basically, before the page is loaded, do some stuff, which we call pre-parse, and then parse the page, and by parsing the page, what we mean is, with just normal HTML, you can define widgets or digits in your page just through markup with some custom attributes, which works in every browser,

but it breaks the validator, but I don't care, and we can debate that some other time because I'm talking, I'm just kidding, obviously. But then, basically, parse the page and convert normal HTML notes, upgrade them to digits, and then do something with them afterwards, and that's the simple part of the pattern. You just connect the kernel to a pre-parse call

and then do something with it, and then you just load in, for example, here's a kernel, and it's got a user ID and some features, and a foo variable set to bar. It's a nice, simple pattern. A lot of people probably use it without really realizing it, but we use it in a pretty extreme way. It is a nice place to shove stuff. Some people might say it's really bad

to just shove everything into a kernel. I would say it's better than shoving everything into the global namespace, because you'll forget, and then you'll want to mash up with something else, and then you'll have script errors and kind of forget why they're there, or other people in your company will work on other parts of the application and use the same global variable, and you'll hate each other for life.

REST, how many of you are familiar with REST? Okay, everyone, I don't need to go into that, but you get the idea. It's just your standard methods. The cool thing is if you take REST, and you take JSON, and you take a few other services, you can basically think of the entire internet as a database that you can use in your application. This is a hideous slide on purpose.

This is a common set of architectures you could use to build a Dojo application, and the cool thing is all you're really writing is a little bit of code in the orange on the top left, and a data API to access your code, instantiating some widgets, and then basically you can use our concept of data stores

and your own data services based on whichever approach you want to take. Load them over a transport to your server-side code. If you want, you can try and sandbox them in a way that'll work in a portal, but the cool thing is you're just worried about that little part up there, and then whoever's working on the server-side is worried about that little part down here, and suddenly you can basically access data

of any kind of any form and put it into any style user interface you want with not much effort, which is cool. RESTful architectures recommend separating the UI and the data, so of course what we're saying here is in this architecture is that the UI

is concerned about the UI, and now some people have taken the opposite approach, saying the server should still care about the UI and reverse that relationship. We don't. So how do you do that? There's a lot of options. On the client side, you can use Dojo or Persevere or other toolkits if they have an extension for data or RESTful architectures. On the server side, you can use Spring or Persevere

or CouchDB or one of the common JS-compliant servers, or you can use Ape or a number of other things, and Persevere is another Dojo Foundation project. I'll focus on that since you're going to talk a little bit about Ape. And basically the idea is anything you can imagine doing in XML or with databases, you can do in JSON,

whether it's grabbing data, pathing it, querying it, referencing it, writing schemas or hyperschemas. So it's very cool. You can take JSON and start to manage cyclical relationships, multiple references, cross-site references. You can say, in my structure of data,

this particular object actually points to the search results for this tag from Google, which is kind of cool. Data-backed objects, right? So the idea of dojo.data is that basically you've got any data source and you've got widgets that all want to speak to just one API set.

So basically you have just a very simple API on the client side. It goes through a small translation layer, which is basically called a data store implementation, over some protocol to your data source. And you can use it very nicely. The cool thing is say you've got one data source, right? And say it represents stock quotes, okay? So you could have in your page a grid and a chart, right?

And the grid and the chart could talk to the same live data source. So then you've got a chart of all the stock quotes and it's changing numbers. And then you've got a set of charts that are going like this now. The reality is financial markets don't move that quickly, but it would be cool if they did. And it makes a cool demo when you create fake data that does that.

So data can become available in almost any form, right? So the idea is that dojo's built a whole number of ways, whether you just have data shoved into your HTML page, a CSV file, JSON formatted, XML formatted. People have SOAP extensions. I don't like SOAP in browser, but some people have a real need for it, especially if they're doing like a desktop-style application in the browser.

Dynamic sources, right? You've got a program on the server running and generating dynamic data for you on the fly, that sort of thing. Flickr, Google, Picasa, Facebook, any other data source you can imagine wanting to pull into your application, doing it easily and simply. Sort of said that, skip. Dojo has something like 60 or 70 existing data stores

and there's a lot more out there. They're very easy to write. And we're actually working on an even simpler one for dojo 1.5 called just an object store. But, again, the idea is that you've got basically four simple things, read, notification, identify, and write. We're actually thinking maybe we should just change it to get, put, and post, but we'll see.

The idea is you've got all your widgets, you've got a simple API, and then you've got your stores, which tell the APIs how to grab that data, update it, cache it, how to edit it, update it, read, write, et cetera. There's a lot more. So if you want to have code that your data

follows a particular schema, you can get JSON schema. If you want to do full... Did I turn myself off? Volume, great, okay. If you want to do an RPC-style approach. So one application we had had like a meg of basically get and set methods of various properties. It's basically imagine trying to work with

ad network APIs, to set quotes and bids and pricing and all of that. Well, we took that and we changed it to just a JSON RPC-style approach, where we just sent a file listing the methods and properties and parameters that were available, and we dropped a meg of code down to like 100K, or 50K, or something really small.

The idea is that you can generate all of those get and set methods on the fly, when you need them only. CommonJS has become very important for Dojo and Persevere and other projects, and we're working on that as well. There's a project called RequireJS that would work with their module system that would work with Dojo as well.

We're seeing JavaScript emerge as a true server-side programming language, so you can use JavaScript anywhere, which is really awesome. I mean, it's either completely scary or completely awesome. I obviously think it's awesome because I like scary stuff. But imagine writing JavaScript on the server, on the client, on your mobile device, everywhere, and you might say, well, why not Python or why not Perl or why not Ruby?

What's happened is JavaScript is so well tested for manipulating the DOM and browsers that re-implementing that in another language is just not worth the investment for most browser vendors. And the server-side implementations are actually becoming so fast, they're faster than the Python implementations in most cases. So it's pretty amazing that JavaScript has become this,

from this completely bastardized, unowned language to the world's leading, most popular programming language in just a decade. Quickly, people ask, who uses Dojo? A lot of people use Dojo in the public. Way more people use it in private. So Dojo is often used for internet applications, software people buy, error applications, et cetera.

Obviously, the Chandler Project, when it finally released, used Dojo for the web UI. DCTP is a German TV channel that does live video and uses Dojo for the interface. ESRI is the world's leading map technology provider. Pretty much if you've ever used mapping software,

ESRI is somewhere in that stack, and they use Dojo for their AJAX APIs. And they have cool things like, not just maps, but also demographic information. So you can pull in and say, OK, in this location, how many French restaurants are in this two kilometer radius? And it might help you decide where to open your French restaurant, or is this a good place to go to eat, that sort of thing.

But all using Dojo widgets and data. iFi, I don't know if it's available worldwide, but it's available in the UK and the US at least. It's basically a SDRAM card with a little Wi-Fi chip built into it. So basically, once you configure it, you can basically take pictures. And once you're in proximity of any Wi-Fi network that you've configured it for, the photos upload automatically to your computer

or Facebook or Flickr or whatever network services you've set up. And they use Dojo for the configuration and installation with Wizard, which is really cool. Fidelity is a very large broker, stockbroker, especially in the US. And they pride themselves on being the leader in technology in that space. And basically, they have Dojo down to like a 6K initial load.

That way, they show up as still the fastest website for building applications or for delivering stock quote data. And then they highly optimize it based on exactly the modules they need at a certain time. Lufthansa is a cool airline. Obviously, you see a flash block in place, so they messed up there. But they use Dojo on their site, which I like.

PlaxoPulse, a lot of people don't use this, but I kind of like it. It's kind of like an early version of FriendFeed. It just pulls in data from different places and uses Dojo. Queued, if you're in America, we have a service called Netflix. Netflix is really awesome. Basically, you get movies on demand, or you get DVDs sent to you. But their web interface for choosing the order

you receive movies is really poor. So this application called Queued helps you redefine the order of your queue really quickly, and it's really nice. But it's an air application, which is really nice. So it's a download, so you get an icon. And so you can actually get the best of both worlds in that case by using your web technology development experience,

using WebKit as the rendering environment, shove it all into an air application, and people can download it. And thousands of people use this. And we don't actually put much into it, so it's pretty cool. Sun Oracle has a product called Convergence. Basically, it's their email application. Obviously, we've probably built like half a dozen email applications for different companies. This one just uses a lot of stuff.

And before this, it was like a web applet for this, a download for that, and a web 1.0 version for this. So we helped them do that. Openness. Dojo is a true 100-point open source project, as I believe MooTools is as well. But I would have to verify that. I don't know. But basically, it's the definition DNL and all my RFA Jackson came up with,

which is basically like, not only is it open, but is it open for me to use? Can I be involved as a contributor, or does one company own the rights to who can contribute? That sort of thing. Lots of people use Dojo, obviously. We're always looking for help. People may have this perception that we're this big corporate entity. No. We just have a few large companies that contribute developers as well.

So we're always looking for help in almost any way, shape, or form. The future of Dojo, I've talked about it a little bit, but basically, lots of edge web development, lots of enhancements, more work on map and performance, performance, performance, performance, easier to use APIs, et cetera. Obligatory plug for SitePen.

We build web apps. If you ever need help with Dojo or your web app in general, you can call us. There's an online Dojo conference next week you can sign up for. It's not free, but a lot of the proceeds go to Dojo itself. Here's some interesting and useful links. Obviously, there's a lot of Twitter stuff at the bottom, because people use that now. And of course, there's this email thing

that I still use, too. So thanks, and I have a question and answer policy, which is you get one sentence to answer your question, and I answer it in one sentence. So I am ready for questions. Yes, what about offline?

So currently, for offline capabilities, we support Gears, which may be dying. We support the HTML5 model, which isn't quite there, but it's close. And that's our approach. Basically, we support whatever the browser can give us. People can and do build offline applications with Dojo. So Dojo, actually, that's way more than one sentence.

I'll shut up unless there's another question. I forgot my own rule. All right, who's next? Yes? Is there a steep learning curve? Is there a steep learning curve? No, it is steeper than something that's smaller. So Dojo is a comprehensive toolkit. One sentence.

You can ask anything, and I'll give any sort of answer I feel like. Yes? When do we drop IE6 support? Preferably, the idea is that 1.x will have it, and 2.x will not, and 2.x will come out in 2011. There's one up there.

I'm sorry. I couldn't hear the last word. EXTJS? Yes, what do I think about EXTJS? I think they have some amazingly lovely widgets, and I hate their licensing.

All right, thanks. Thanks.