Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Google I/O, In Retrospect

I went to Google I/O last week and thanks to DeWitt Clinton I gave a talk on where browsers are headed and if they can really get us where we want to go. I'm afraid that even more so than is usual for the talks I do with slides, this set is somewhat indecipherable without the actual talk along side it.

Slides are below in PDF format (6mb):

Sadly, I didn't make it to many of the sessions, but I was able to catch Brad's excellent talk on building a client-side searching utility with Gears. His demo app used a custom build of Dojo, which was exciting to see because not only was it stripping out stuff that he didn't need from the base dojo.js using the customBase build option, but he was also able to use the build system to alias dojo. to pt. so that it didn't conflict with other versions of Dojo on the page and also packed up all the modules into a single file. We've had each of these features in Dojo for a while, but seeing them used together was incredibly powerful. Dojo can act as "Dojo" or the basis for your own library without much more work. The demo itself (a client-side search engine) was also powerful. Brad used Gears' worker threads to parallelize the work of pulling fetching, tokenizing, and handling a site's content. The speedup in being able to move this kind of work into the background (potentially onto separate processors and cores) opens up a new world of potential applications. I've been thinking about the implications of a ubiquitous Gears ever since.

An aside: Google throws a hell of a party. The only thing I've seen comparable to it was the awesome time that Microsoft hosted at this year's MIX. Landing the Flight of The Conchords was quite the geek coup for I/O, particularly since most of us had no idea who would be playing. Considering that I also got to see David Capurro at yesterday's Laughing Squid party, I'm pretty blissed out on geek meme entertainment.

Update: video of my talk is up at the Google I/O site. The video should make the arguments somewhat more clear than the slides alone could (although on the downside you'll to suffer through my myriad "um"'s and "uhhh"'s). Also, Neil McAllister has a piece up today which summarizes some of the talk's points. I'm afraid the talk left him with the impression that I support natural monopolies when in fact I only raise questions about their formation in order to find ways to effectively break them (or hollow them out).

Zend + Dojo: More Than The Sum Of The Parts

In the past several months, more and more integrations of Dojo with server frameworks have been shipping, and we couldn't be happier about the Zend + Dojo integration that was announced yesterday.

Fundamentally the Dojo and Zend teams really "get" each other. Both are deep packages that give you an opinion about how best to do something but also all of the tools you'll need to make it work at scale. The "use at will" term that the Zend folks use made immediate sense to us. Like Dojo, Zend doesn't saddle you with more than you're really going to need up-front, but at the same time, when you need something awesome which is well tested and integrated, it's right there. No digging around on google to find a "plug in" that will get you where you want to go...both Zend and Dojo give you a full stack of great components to work with out of the box.

There have been some questions on IRC today about why Dojo and not something else, and we know that the Zend folks are committed to continuing to allow Zend to work with other frameworks as well and we fully support them in that. There seem to be lots of choices of Ajax frameworks which Zend could have integrated, but when you look at the requirements of serious products which need to ship tested solutions to really hard problems, the field whittles down very fast. In response to the needs of our users, both Zend and Dojo take seriously our responsibilities to provide integrated, high-quality, unambiguously licensed products that will let user scale both up and down. Key to this is understanding the full spectrum of use-cases, informed by past experience, and striking a balance between enterprise-ready features and close-to-the-metal primitives. The Zend Framework has a larger view of the server-side than Dojo can, and as a result there are new opportunities to optimize and improve the user experience for all classes of users through this integration. This isn't just about including some scripts on a page, this integration is about improving user and developer experiences, and both Dojo and Zend bring a lot to the table which can compliment the other. Dojo's strengths in progressive enhancement, packaging, localization, and accessibility all have obvious allegories in the ZF world where a complete integration can more value based on what developers are already doing. All of those features of Dojo will work better when the server-side knows how to "hint" things for the client and work with, not against, the client to deliver better experiences.

I'm perhaps most excited about the data-driven opportunities in the Zend/Dojo integration. Dojo's data infrastructure is second-to-none, and the design of the and dojo.rpc layers provide Zend Framework integration the ability to take advantage of systems like the incredible Dojo Grid and the client-side charting package. There's more to look forward to, and figuring it out together with the folks at Zend is a great opportunity for the Dojo community.

Pete Higgins and I will be participating in next Tuesday's discussion with a broader chunk of the Zend Framework world, but until then (and long after) we'll be hanging out in the #dojo and #zftalk channels on We're looking forward to working more with the ZF community to build great experiences, and are hugely excited about the direction things are already taking!

Blatantly Mis-Quoting Sublime

100 points to Freedom.

Dojo, DWR, CometD, OpenRecord, and the newly accepted Psych Desktop project are all 100 for 100 on Dion's scale because we've done the hard work of building a Foundation, ensuring the IP provenance of every checkin, built a community structure that gives everyone who's significantly invested a real voice, and have made the sacrifices that ensure that Dojo Foundation projects aren't just "open", but that they're trustworthy.

Dion's right:

The license is a great starting point, but it isn’t enough.

The Dojo Foundation has open door for any web projects that want to join and will do what it takes to get their score all the way up to 100. If the projects you're using aren't 100 for 100 — particularly given that we make it so easy — isn't it worth asking "why?"

App Engine: Most Of The Stuff I Want, None Of The Stuff I Don't

I'm not sure who or how, but I got an invite to yesterday's Camp Fire One event at Google where they announced their new App Engine platform. The event itself was small-ish, with lots of interesting people invited (both from Google and not). I had no idea ahead of time what the announcement would be, and frankly I forgot all about the event until the day of. I'm glad I remembered (note to future self: next time, pack gloves and a hat).

As they started talking about the platform and what's part of it (and what's not), I couldn't escape escape the feeling that they'd gotten it right. It is absolutely the case that for most apps, scaling requires some amount of re-architecting. Systems like Rails are built with such a dependence (intentional or not) on the features of relational data stores that they quickly hit bottlenecks because frameworks aren't keeping developers out of the gutter. This is nearly the same lesson that the security community collectively came to when it started to beat the average developer about the head regarding the awesome power of defaults. What systems do and don't do for you "cheaply" defines their character, and in many systems those choices aren't made consciously, or if they are, they don't have the benefit of a different perspective which might de-emphasize certain traits. Call it libertarian paternalism, choice architecture, or pure condescension, but whatever it is, systems and platforms today are in the explicit business of making some things easier than others.

As the presenters showed how to make an app quickly, I knew I was looking at something I hadn't seen the likes of since Jot. We all know that Big Table is a column-oriented data-store, but since most people are still stuck on the likes of MySQL, it's hard to appreciate how liberating it is not having to think about how adding properties to models will affect a schema. The way App Engine is constructed lets the data store layer provide something called expando models. These models give us the kind of flexibility that I've only ever enjoyed before inside of Jot. Want a property? Just add it. No migration, no schema version...just data finding a happy home, and as your app's skeleton "solidifies" and you figure out which properties really do need to be faster, you can migrate that data into fixed properties with indexes and types and all that jazz. It's like a gradual type system, only for data stores. It's agility nirvana for application development.

Speaking of application development nirvana, they also had the good sense to start with a great language (Python) and a great webapp framework (Django) as the basis for the new system. For all the Rubyists and Java heads out there who are surely crying bloody murder, I suggest that they just try it. Seriously. Django's template system is freaking sweet, and Python (despite it's lambda-related warts) is close enough to being executable pseudo-code as to still hold the second place in my toolbox of languages.

There's a lot which I'm sure others will (and have) covered about how App Engine is going to change the game for startups and players like Amazon, but I think that if someone else had launched this system it would still survive on its merits alone. The only wrinkle in the whole thing will be seeing what's done about pricing over the long haul. It really shouldn't be hard for Google to beat S3 on price, and I'm sure there will still be a market for EC2 for non-traditional tasks, but fundamentally I think App Engine has all the makings of something really, truly better than the current (assumed) stack.

After more than a year of mourning the effective loss of Jot as a platform, writing apps on the server just got interesting for me again, and that may be the highest praise I can offer and framework or platform.

Dojo 1.x: Industrial Strength Open Web Tech

...just ask AOL. James Burke just pinged me to let me know that AOL Webmail has been updated with a slew of new features built using Dojo 1.0. A quick inspection of the app shows all kinds of great stuff including tons of custom widgets as well as extensive use of the Grid. To keep loading of the app quick, AOL is using custom builds to pull Dojo from a CDN and a number of application-specific layers in order to defer loading of code until it's needed. Congrats to the AOL Mail team! It's inspiring to see a site that does billions of page-views a month using Dojo so effectively.

Dojo 1.x is now powering the UI of the world's largest mapping service, one of the world's largest email services, the most useful personal information service anywhere, and the front-end of my favorite RSS reader.

The proof of Dojo 1.x's quality really is in the pudding. Congrats again to the AOL Webmail team!

Update: Travis Vachon also just sent mail to let me know that OSAF's Cosmo project has also released their 0.14.0 version which has also made the upgrade to Dojo 1.0. Congrats, Cosmologists!

Older Posts

Newer Posts