Thick As A Brick
One of my grad school instructors, Dr. Muth, used to stress to us that we'd get more mileage out of synthesis, connecting ideas from different sources and combining them into new ideas, than cold analysis, taking a source and stripping it down to its essentials. In that spirit, I'd like to connect the dots between what java.net bloggers and other smart people have been saying recently about "thick clients".
Phillip Brittan recently blogged about Microsoft's thick client plans for Longhorn, its next major OS rev. Philip notes news coverage of Longhorn's thick client API's, which are meant to lure developers into writing more sophisticated clients that can provide a richer experience than what's possible in a browser... and of course, such clients will only run on Windows.
This is what Daniel Steinberg and I were talking about at the O'Reilly Mac OS X conference, when we left a session on thick/rich clients by Watson creator Dan Wood. As Daniel relates in his weblog, we talked about the possibility that web content developers would create single-platform rich clients and, as we've seen so often with desktop software, just do a Windows version and figure that's good enough for the majority of users.
So much for the openness and heterogeneity of the internet. If I have to pay a Microsoft tax to go online, forget it.
But there's a way out of this trap, and we're a part of it. In the slides from Dan's session - and this is from memory because only a Keynote version is available online (um, hello? print to pdf?) - there was a very surprising item at the end of his session. Thinking about how to distribute rich clients in the future, he wondered if Java Web Start might be the answer. I was surprised to see this because as far as I can tell, Watson is very much a native Mac application, and Java was never mentioned in any other part of his session.
But let's pick up this ball and run with it. Let's say we have a net application that's poorly suited for a traditional web client. We need to build a richer, more desktop-like client. A native application is an obvious choice, but then we have to have expertese in multiple platforms (or anger users of platforms we choose not to support), and we have to hand out an installer - absolutely unacceptable to some users, particularly in the enterprise. We could try single-window DHTML, which saves us the installer hassle, but pointless differences between browsers (thanks again, Microsoft) make this as bad an option as native apps.
So here's a wacky idea... how 'bout we do it in Java? With J2SE, we get:
- A mature language with a huge talent pool available
- A deep set of API's, particularly strong in networking and XML
- Deployment via Java Web Start prevents us from having to hand out an installer, yet it practically becomes an application after repeated use.
and most of all...
- Write Once Run Anywhere. This is the point of Java after all, why not finally exploit it?!
In my session at the OSX conference, I argued there were no Java "killer apps" because seemingly nobody has applied Java to tasks to which it alone is the best solution, where WORA is critically important. I suggested there were two general fields where Java could make the most impact:
- Off-network apps, since a web app obviously can't be considered for such tasks
- Situations where the user experience requires a richness that can't be provided by the click-wait-read cycle of a web app, yet multi-platform support is desirable or even critical
In my session, I offered DVD extras - sometimes currently offered as a Windows-only goodie - as an example of the former. An ONJava blog I did a while back, "What If the iApps Had Been the jApps" was a hypothetical example of the latter. Interestingly, when I wrote it, I had no idea that someone had actually written jTunes 4, a remarkable Java mimicry of Apple's iTunes.
But it makes sense - this is an MP3-playing app that could be run on any OS that currently supports Java, and nicely, any future OS or device that supports Java. Analysts have expected for years that Sony wants the PlayStation 2 in your living room to become a "media hub" - if it supported Java, you'd immediately have a top-flight audio player without anyone having to write or port a new app to the PS2.
What's also interesting about the iTunes example is something that Amy Fowler wrote a while back in her weblog, Would you run in flipflops (actually I did once, trying to get on Star Tours at Disney World... caught the tip of my right sandal and nearly cartwheeled) She points out that the typical web interface is a miserable way to sell and manage music. And she's right. But iTunes is a more interesting hybrid than I think she realizes.
Here's the basic iTunes window. This is how you browse, arrange, and play music.
Obviously, we're in thick client territory - lists, tables with sortable columns, custom components, copy-and-paste, drag-and-drop, and nice fast responsiveness.
But the integrated music store is different. Find some music and click on an artist. You get a screen that looks like this:
This is obviously HTML, supported by the Safari WebKit, and if it's not it might as well be - simple paragraph formatting, some images, links to each album, and a "buy" button for each album's form. Notice also the simplified browser-like navigator above - forward and back buttons, plus browsing hierarchy links for "Home -> Rock -> Supertramp"
So then, what do we make of this situation:
In this case, we see a merging of the two worlds - the album info is HTML, with links to the artist, top downloads by this artist and (if you scroll right), recommendations based on purchases of this album. But below that, we have a thick-client table, still sortable by title, artist, time, etc. And the "arrow" icons here act as links to albums or artists, reloading the HTML section above. Overall, iTunes is a very slick merging of the thin and thick client.
So getting back to the concerns about Longhorn and its thick client API's...
if writing thick web clients is such a good idea, why don't we do it today, in Java?
Longhorn's not coming out for two years. Java works today. Java Web Start works today. Swing works today (despite Joshy's complaints to the contrary). Sockets, RMI, JDBC, XML parsing, even auto-discovery with Jini are all available, for free, today. Simple HTML support is in Java today (maybe not enough to write a good browser with, but enough to do something like the music store).
Consider how Apple had to whip up a Windows version of iTunes to get their music store to Windows before they were eclipsed by competitors (analysts actually suggested that Napster releasing its music store a week before iTunes would kill iTunes... ha!). Had Apple written iTunes in Java in the first place - and jTunes proves they could - then they could have had a Windows version out three years ago And it would run on Linux. And it might make users want Java on their PS2's.
Why wait two years for Microsoft to screw up the internet for everyone? Java is ready for the future today. Are you?