Every software entrepreneur I know dreams of building a platform business. Not just wistful "wouldn't it be nice" stuff, no, I mean an all-consuming lust to become that which others build on. Led down the garden path by the example of Microsoft's dominance in the desktop market, believers in the platform strategy view ubiquity and control as the backstop against comoditization and a foothold for launching new attacks against the competition. The part that's not so obvious is that becoming a platform means that you first have to come close to winning the market on non-platform merits at which point, voila!, you're a platform...so long as you haven't made it impossible to build on your stuff.
I got to thinking about this because the tiny sliver of time that Java occupies in my mind these days is generally dedicated to dissecting it's rise and fall. The more time I spend on it, the more I realize that what's happened to Java in the last couple of years is a failure to recognize a couple of things:
- that Java won, despite it's myriad warts
- that winning is not a god-given right
- that you can't expect to win on your own terms
In fact, Java never won on its own terms. It won by having enough pluck and backing to build up a real, honest-to-god platform. The platform became a platform because it got used for enough good things that it came close (enough) to winning the market for a certain class of apps. Java the language is a pitiful mess. Java the platform? Now that's a thing of fucking beauty. Not only did Sun build the alliances necessary to ensure that Java would be available to whoever wanted it, the "Pure Java" marketing actually worked.
The result is a system that won because it created an environment where, no matter what the OS, developers could plug in a set of Java libraries (I'm ignoring the JAR cluster-fsck for now) and know that it would all "just work" thanks to a common bytecode interpreter. Now, other languages have used a similar form of platform aikido to catapult themselves into utility. Python, PHP, Perl, and Ruby spring to mind as languages that don't really mind their C dependency chains. Quite the contrary! The communities around these languages (rightly) consider being able to "swig up" some C or C++ hairball as something they can script as a core feature. It allows them to turn one platform win into another. Which is exactly where Sun continues to self-destruct.
Instead of understanding that they won the platform war and will inevitably lose the language skirmishes, the Java camp seems hell-bent on trying to shoehorn Java (the language) into ever more places that it doesn't belong. JSR 290? Gimmie a freaking break.
All of this points to a bright future that Sun, currently, seems too limp-willed to exploit. There's an amazing amount of good code that people have churned out in Java. The "Pure Java" thing actually played! Instead of allowing the partisans to throw stones at folks who want to run other, more productive, languages on top of the JVM (aka: the platform), Sun should follow through on it's baby steps and start giving real respect to the dynamic languages folks who want to help them continue to win on a platform (not language) basis. Hiring the JRuby guys and shipping jrunscript (aka: Rhino) in Java 6 are good first steps, but they don't go far enough. The atmosphere has to change. Acrimony needs to be turned into understanding, and real investment needs to be made in making the platform successful, even if it comes at the cost of one particular language.
It's not too late. I hope.
Here are the slides from my talk on Mobile Ajax development. I've got a longer-ish blog post in the works about getting a working emulation environment set up, but it's taking much longer than I'd anticipated to try to track down some of these things (if you know anyone at SonyErickson or Obigo, drop me a line). Hopefully next time I give this talk I'll be able to include a demo of the "foldable interface" thing I keep muttering on and on about.
There's some fun data in the slides that the carriers would really rather not have disseminated, not that their collective folly hasn't been laid bare qualitatively already.
I'm in Brussels this week at EuroOSCON, and yesterday I was fortunate enough to give a tutorial session on "Building Better Ajax Applications". The slides are online, but don't try to view them with anything but Firefox 1.5 or later.
For the last year or so I've been occasionally giving a talk like this and this time I decided to overhaul the whole thing. Every time I've done the talk I admonish folks not to use Ajax just because they can, and if at all possible to work with interaction designers. Last week at the "Future of Web Applications" conference in SF, Jeff Veen boiled the key points of the ID problem down into the most coherent set of objectives I've heard. He outlined them as:
- Discoverability
- Recoverability
- Context
- Feedback
Having worked with a wonderful set of interaction designers (and now friends) at Informatica, I've got nothing but the deepest respect and admiration for the questioning eye that good user-centric design brings to the process of building applications. Jeff's description of the problem instantly made sense, and I've tried to put the example code in section 2 of the tutorial into the framework of those points. The distillation of the problem into easily digestible terminology is one of the things that was new with "Ajax". Hopefully Jeff's list of the 4 goals of ID can help developers similarly start to frame the problem better.
Good writing (in contrast with mine) is defined by great verbs. Verbs are the essential component in answering "how?". You can't tell a story without the verbs. The sad little world of nouns and adjectives only tells, it never shows.
Which is why we need to fucking bury the word "utilize".
Maybe it's just that I've been free of the corporate-speak haze for too many moons, but nothing gets the hair on the back of my neck to stand up in empathized embarrassment like hearing a smart person say "utilize" when all they needed was a simple "use". It's as though the accreted mental sludge of sitting in meetings causes some sort of malapropism-Tourettes. To my delight, it seems the dictionary on my MacBook agrees with me; from the "utilize" entry:
Because it is a more formal word than use and is often used in contexts (as in business writing) where the ordinary verb "use" would be simpler and more direct, "utilize" may strike readers as pretentious jargon and should therefore be used sparingly.
See! "Used sparingly"! Not effing "utilized sparingly".
The Dojo Foundation has been very lucky in having had so many supporters (Google, Mozilla, SitePen) and so many interested students and mentors for the summer internships. While some of them aren't yet wrapped up, today's announcement of the linker hitting trunk makes me want to at least give an overview of what's been accomplished so far.
dojo.gfx -- portable 2D graphics with a DOM
Unlike <canvas> based solutions, dojo.gfx.* gives you what you really want when you're building apps: a good way to draw a shape that you can attach event handlers to. It's also not limited to whatever rectangle you've carved out on-screen for the drawing area. Kun Xi, Eugene Lazutkin, and Gavin Doughtie have been cranking on this all summer and in Dojo 0.4, you'll be able to say "give me a circle here" and you won't be constrained by artificial box constraints or incompatible event handling. I can't wait to see what gets built with this by people who can design beautiful things. The sky is, finally, the limit.
Plugins for Editor2
Heng Liu and Paul Sowden have been reworking the already fast Editor2 component to support plugins. In the process, Heng has added image insertion dialogs, find/replace support, and contextual menus. When Editor2 was originally designed, flexibility was lost for speed. Now it's got both, and extensibility to boot.
The Linker
This is the holy grail of JavaScript optimization: removing "dead" code. Dojo already provides a package system to help prevent including too much and a build-time compressor to help reduce the size on the wire of what you do need, but the linker does all of this one better by analyzing the application and figuring out what functions are entirely unused. Thanks to the generosity of AOL, and the hard work of Satish Sekharan, James Burke, and Uwe Hoffman, Dojo now packs such a beast. It's not integrated into the build system yet, and probably won't be "prime time" until 0.5, but it works. I'm a huge fan of incremental optimization, and a linker like this will be hugely valuable to large-scale sites that want to make use of any of the JS frameworks that are helping to provide a consistent surface area for developers.
Other projects are still underway and I don't want to jinx them by talking about them before they've landed, but I think that on the basis of this work alone, we can easily classify this summer a success. Huge thanks, of course, to Brian Skinner for his patient and thoughtful work in shepherding of the entire program.
Older Posts
Newer Posts