Infrequently Noted

There was a ton of JavaScript news around this year's JavaOne. First was Greg Murray's JMaki, a library that allows JSP and JSF developers to easily add scripted components (e.g.: Dojo widgets) to their pages with minimal effort.

Next was the less lauded, but arguably more important, Phobos. Think of it as an app-server for JavaScript. These apps can take advantage of the huge number of available Java APIs for doing most anything under the sun. FWIW, Jot takes much the same tack, but fixes the database layer impedance mismatch with a wonderful abstraction. Instead of imposing the amazingly painful "build, deploy, test" process that Java tools try to hide (and usually fail at miserably), both Phobos and Jot acknowledge that the future belongs to dynamic languages. You might still hear lots of FUD out of the static languages camp about how interpreted and/or late-binding languages are tremendously slow, but the truth is usually that your language choice probably isn't the bottleneck.

It's usually bad algorithm choice or an inability to move things that are actually slow to a faster path. I think this is part of why my love affair with Python hasn't ended despite the proverbial writing having been on the wall for a long time. I mainly blame the craptastic XML-SIG, earlier versions of Zope, and Guido's weird malaise about web development for this, but that's another sad story for another day. In Python, you don't worry about language speed. You develop fast and then when you need to optimize, you profile. If things really aren't tractable (which is rare), you just move those critical sections to C. This is a common theme across most modern scripting languages. In Java, you can still get to C via JNI, but it's a second class citizen. Perhaps it's all the "pure java" marketing BS. Perhaps it's how difficult JNI makes it to get across the border and back. Who knows, but Java has certainly suffered as a result.

Phobos is starting to fix this by acknowledge that instead of making the Java mistake (again) and attempting to boil the ocean in yet another new language, we should be riding on the investment in libraries that are already available and make it possible for application authors to work at a faster, higher level and drop down to "the metal" where it makes sense. Obviously Phobos won't solve all of Java's myriad problems, but it will at least allow the Java platform to compete on developer productivity. The tools haven't saved us, and I doubt they ever will. Time to look up the stack. Kudos to Sun for having the foresight to free developers from the shackles of expressive mediocrity that Java has imposed for so long.

Which brings me to GWT. I got asked about this at the smackdown panel and of course I hadn't had nearly enough time to dig into GWT to form a coherent answer. I'm not sure that just looking at the code and playing with the demos has given me enough depth to give a useful answer either. From where I sit, GWT looks like the physical manifestation of hiring managers' frustration when trying to hire for "ajax developer" or "UI engineer" positions. The truth of the matter is that there just aren't very many of us in the world and interestingly, Google employs a fair number of them. That they did GWT smacks of recruiting desperation and the need to better leverage the Google SSFPU (super-smart fungible programming unit).

Turns out you can't just drop a good hacker into UI programming and trust that it'll work out. Not only does someone in the UI engineering role need to have a solid appreciation for the constraints of the web, they need to be multi-language clued, know when to defer to visual designers, have the balls to push back on stupid requirements, and empathize with users. And that's the baseline. No wonder Ajax is sexy and hard to hire for. The great apps in the Ajax word are developed by great engineers and designers.

Not coincidentally, great engineers and designers value great tools. Great tools allow them to express themselves better, faster, and with less effort. This is why the smartest hackers I know want either a fully dynamic language or C. Everything else (yes, you Java and C#) are bad compromises to these folks. They raise the average by enforcing mediocrity. This is a Good Thing (TM) on average but a truly awful thing for people who need to move faster than the herd. Traversing the stack with ease, closure to slab allocator, is what defines great hackers. A high-profile investor and former hacker has written broadly on the subject, so I won't try to rehash his observations. What I do find interesting though is that folks who think they want great hackers are shocked by how bloody honest they are when they finally land one. These people call bullshit because they're constitutionally unable to stomach dumb. Before I moved to the valley, I thought that the shorter average tenure of people at tech companies here was the result of competition, but the more time I spend here the more I realize that for the best-of-the-best, it likely has more to do with the impossibility of moving Mt. Stupid than with competitors offering a better package or employers folding up shop.

So what does that have to do with GWT? Well, I think that like Java and C#, it's going to raise the average. This is also a Good Thing (TM). I'll go out on a limb and say that it's a safe bet that Bob, Cal, and Andy won't be picking it up any time soon. If they do, it'll probably be to build tools for other people. Oddly that might even be a sign that it will succeed in a broader market.

The obvious next question is "what does that mean for Dojo?".

After mulling it over for a couple of days, I think that it will boil down to "coopetition". At a minimum we'll probably see Dojo widgets integrated into GWT as an external project. Lord knows our licensing makes that a no-brainer. Beyond that, there are a lot of places where it's a "battle of paradigms". We think that markup is the fastest way to declare initial UI state but not a very good way to express logic. GWT takes the tack that it's easier for most programmers to declare UI layout in Java since they don't have to learn another language. We think that JavaScript is a better language and that it would be better of people learned more, not less, of it. GWT clearly doesn't agree. We think that imposing a compile cycle on webapp development is one of the worst things you can do for productivity. GWT seems to make the argument that library breadth makes this moot.

At the end of the day, both approaches are trying to get to a better level of productivity for building more responsive apps, and that can only be good for everyone.

Update: just saw that the Ajaxians have been thinking about GWT as well.

I was supposed to give a talk in Amsterdam yesterday, but as the airlines would have it, there was no such luck.

I got as far as Houston in my trans-continental journey before being stymied by aggregated air travel stupidity. Luckily, Andy Smith of Flock fame stepped into the breech and gave the talk in my place.

The talk was written out ahead of time and Andy can read better than I ever could, so I assume it went as well as possible. At least he didn't report any sharp objects being thrown at him afterward.

The text of the talk is here.

I'm also speaking tomorrow at JavaOne. Here's to hoping that defending JavaScript as a "real language" won't get me booted from the premises.

Tomorrow is my last day at JotSpot.

Huh?

For some months it has been clear that the Dojo is now on a path that requires more hands-on management, and either I can choose to double-down or get out of the way. People use the word "vibrant" to describe the Dojo community, but I think that hardly begins to cover it. The amount of traffic on the Dojo lists is stupendous. Contributions and committers are coming out of the woodwork, companies are looking to Dojo for a solid platform to build on, and our next release has been languishing. Clearly something has to change.

At the same time, I care deeply about Jot. Yeah, I know, companies can't love you back, but Jot is an amazing place, has a truly unique product, and is chock full of people I'd love to keep working with.

My friends have had to put up with this kind of agonizing for months now.

I don't talk much about Jot here, and I think it's probably because of the classic engineering apathy towards marketing. All I see is my bug list, not the cool stuff we just built. But now I've got a little time to reflect.

Jot isn't a Wiki. Not really. It may also be the most kickass wiki the world has ever seen, but in many ways that's incidental to the overlap with the core system capabilities. I often say that "it's an application platform cleverly disgusied as a Wiki", but that doesn't really capture it. When people think "application platform", they see something that requires them to set up a database, install some gunk, get Apache correctly configured, get the rest of the environment bootstrapped, and then voila! Programming nirvana. A lot of these supposedly "elegant" platforms require that you cough up this giant configuration hairball before you can even start. The justifcation for this seems to usually fall into either the "but we're using a pretty language!" or the "we're using the standard business language!" buckets.

Bah. Humbug.

Now, of course, I too used to accept the apache-database-blah-blah-blah dance as a cost of doing business. But as with most things where there is an entire business devoted to making something just appear to happen magically (web hosting), these businesses are just filling in the gaps until the root inefficency can be elided entirely.

Jot represents the first system that I've ever seen that gets this right. Instead of forcing you to think about some kind of MVC fuss-and-bother, you build what you were after in the first place, usually a form, and then start iterating on the implied structure of that data.

You don't change a model and upgrade a schema, you just add the property you wanted to add. This has been the secret to building applications like Tracker. We don't worry about a data model when building apps like this. The data evolves as our understanding of how people will use the UI evolves, and because it's all versioned, experimentation is non-destructive.

In the same way that test-driven coding allows you to make changes with confidence, the deployment environment playing "version nanny" is a great liberator in development freedom and process. Loading anything, data or program, into the system has the effect of strapping the suspenders on, and isn't that when you really need them? Not when it occurs to you that you might be doing something destructive, but at the point where you might otherwise be doing something destructive.

Add to that some awesome Dojo integration with Jot (which I'll talk more about when the new version hits the servers), and Jot really is the first of the next generation of application platforms. Web services make the configuration dance transparent on the macro scale, and Jot can do the same thing for apps on the local scale. It's a level of power that I've never encountered before, and don't expect that I will again anytime soon.

Soooo...

Wednesday is my first day at SitePen.

Dylan has quietly been "getting the band back together" under the umbrella of a small consulting firm that he helped to found back in The Day (TM). SitePen is nothing short of the A-Team of Dojo-based application development. In addition to employing two of the project's co-founders, a large number of core Dojo committers are working on projects large and small for a diverse set of clients who value great UI married to top-notch engineering. Along with the great guys at TurboAjax, SitePen helps to fill in the gaps that the Open Source nature of Dojo leaves unfilled.

But what about that whole "need to spend more time on Dojo" bit? Well, SitePen is hiring me to work on Dojo full time. Sure I'll be fixing high-priority bugs for SitePen customers, but all of my work will be rolled into the Open Source project. Most of the time though, I'll be focusing on what the community needs and how we can best make the project's goals of universal adoption a reality.

My new job will be to push Dojo forward as fast as we can possibly make it go. There's a long list of improvements for Dojo that I've been putting to the side for when I stumble onto a large pile of "free time". SitePen is going to allow us to make those things a reality.

Time to see how high this "Dojo" thing can really fly.

So it was good natured ribbing at Cal when Leonard set up fancytrousers after a discussion at dinner the night before where it was pointed out that we Americans use the wrong words for everything.

But perhaps it's just mean-spirited to point out that apparently there is a picture on the internets that shows Cal with a facial expression that might, in some jurisdictions, be considered smiling.

I fully expect my Flickr account to be suspended any minute now.

Hot damn! The Python Essential Reference has a new version out! Huzzah!

The 2nd edition of this book has been in my backpack for going on 3 years now. It is the only Python book I can't live without. No offense to O'Reilly, but with the exception of "Learning Python" and the "Python Cookbook" books, their core Python language books have sucked major donkey. New Riders has them licked with just this one title. If you want a book on the best damned language this side of C and the other side of Scheme, "Python Essential Reference" is the way to go.