|
|
||
Simon Morris's BlogTo the Top of the Food ChainPosted by javakiddy on January 15, 2008 at 03:44 PM | Comments (12)One of the things which slightly unsettled me after the release of Update N was the frequent mention of how much better things would now get for Java applets. The subject cropped up again, in detail, during my post-holiday catch up of Java Posse podcasts. To paraphrase Obi Wan Kenobi: "Applets, now there's a name I haven't heard in a long long time." Like many who came to the platform in its early days, my first experience of Java was via web applets. Back then I was working on projects for Hewlett Packard — the only way to build Java code on HPUX boxes was to call the JVM embedded in Netscape 2! Boy was I glad when HP released a proper SDK! While I recognised the potential of the Java platform (which it still hasn't fulfilled!) I wasn't mad keen on grafting it into web pages. Years later web designer friends would jokingly comment on Java's decline at the hands of Flash — no doubt they expected a robust defense of the applet platform, but that was the last thing I was ever likely to give. The undoubted kudos and publicity Java received thanks to applets came at a heavy price: the term "Java" became synonymous with eye candy. Useful applets were few and far between compared to the sea of eye candy. It's an image which seems to have stuck in the minds of many, as I've found when pitched Java solutions to government and media clients. I sometimes think it's an easier sell if the client has never heard of "Java". All this talk of applets has got me thinking: isn't it about time we moved Java up the food chain? Survival of the fittestPerhaps some Java folks never really got over the humiliating defeat to Flash during the latter part of the Nineties. No sooner is there a renewed focus on the desktop than people are extolling the virtues of the Java Kernel for applets. My response is simple: "let it go!" Flash won fair and square — their technology was nimbler, better met the needs of the audience (who, if you hadn't noticed, were more at home with 'Photoshop' than 'Visual Studio') and had all the key features within easy reach (read: video!) Java applets were, and still are, an application development technology in a graphic design world. What do we honestly expect — a revival? Sure, there's nothing stopping us creating our own Flash like development tool... except Flash's origins are very different to Java's. Born initially as a vector animation and graphics tool for the web, even now Flash still retains the feel of a technology who's users are more at home with a paint brush than a screwdriver. This isn't to say that Java doesn't have a place in the realm of graphics and animation, but there is a difference between low-level graphics/timing APIs, and the applications which sit atop them. (Are you listening Microsoft anti-trust lawyers? Winsock != Internet Explorer :) Besides, even if we came up with a development UI comparable to Flash, why would anyone want to switch? What must have functionality would force Flash users to abandon their hard earned skills en masse and join the Java camp?
By the pricking of my thumbs...Ironically, while the Java camp plots its return to the web browser, Adobe have been steadily trying to get Flash away from the browser and onto the desktop. Increasingly users are becoming restless with the limitations of the web as an application platform. Web 2.0 hasn't delivered the kind of rich interface experience people recall from their time with desktop applications. It is only natural that Adobe should wish to follow the herd as they move away from the browser and back onto the desktop. But this is where Flash's heritage starts to work against it. The desktop isn't the web (obviously!) — while users do seem to favour more visually impressive UI's, they're also demanding a comprehensive widget library backed by plenty of functionality. Flash's UIs are still very much glorified web forms, and its API support for functionality outside of the web (crypto, heavy XML, desktop integration, file formats, network protocols, the list goes on...) is extremely feeble. It makes me wonder why, given Java is currently sitting pretty at ground zero of the likely next big thing, anyone would suggest upping sticks and muscling our way against the flow of traffic?
Fixing JavaAt last steps are being taken to address the JRE's download size and start up time, making the Java platform a far more attractive proposition for both the developer and end user. But there are two key issues which still need addressing: one minor, one an 'elephant in the room'. The first issue is branding, specifically the amount of it. No, this isn't a plea to increase Java's visibility through some clever marketing campaign — quite the opposite, we need less branding! The fact that a given application was written in Java needs to be hidden from the end user. From applet splash panels, to tray icons, to WebStart download dialogs, and so on: the end user mustn't have Java's 'alien' (non-native) nature thrust into their face. After all, who are we preaching to? Regular end users don't care what their software is written in, but software publishers do care when their products are littered with tags and logos for the tools they use. The second issue (and the aforementioned elephant) is video support, or lack thereof. It can't have escaped anyone's notice that YouTube et al went with Flash for their embedded video component. Hardly a surprise, given the equivalent Java applet would have been a nightmare (even with the kernel.) What is it with Java and audio/video — why is it always such a struggle?
Top of the food chainWhenever Java has lagged on the desktop the culprit has often been its fetish for re-implementing native components as bytecode. Flawless native look-and-feels and web content rendering was impossible, until we ditched our fixation with '100% pure' and reached down to wrap the native components. Java's attempt to re-write media codecs fizzled and died, and again the solution points towards leveraging native codecs rather than writing our own. What use a 100% pure Java PDF viewer, when we can embed the native PDF viewer already available on the user's system? Can you see where this is leading us? :) Well, I began by talking about the demise of the applet, and how some would like to re-animate it. Coming almost full circle, I want to propose we turn this idea on its head (ouch, mixed metaphor!) Instead of embedding Java inside other applications, why don't we focus on embedding other applications inside Java? In the 'battle to come' for the Rich Internet Application space, Java is in a very strong position. We already have an extensive developer community, oodles of API support, and age-old issues of deployment and startup are finally being addressed. Now we need only a few tweaks to WebStart, and a new media API, to really get the ball rolling! Compare that to the uphill job Adobe has ahead, turning Flash's web-centric functionality into a tool which could churn out a respectable RIA word processor or media editor. Flash is heading Java's way again, but this time it'll be fighting on Java's home turf. But let's not get complacent: many a superior technology has fallen to weaker opponents who somehow caught the imagination of the public (and if there's one thing Flash is good at...) Let us assume, for argument's sake, Java reigns supreme... Even as the World Wide Web's star begins to wane, and newer stars twinkle ever more brightly in the night's sky that is the Internet (who says I can't do poetry, eh?), Flash's future is still assured. It will always retain its place as a handy 'embed' inside other applications. Can you imagine a desktop application in the not-too-distant future, where the help system consists not of boring text but rich vector/media animations? Those animations would be running inside an embedded Flash plugin, naturally... but what of the host app? Wouldn't it be spooky if it was written in Java? Hmm... Flash movies, running embedded inside Java Rich Internet Apps — now there's irony for you... :) Bookmark blog post: CommentsComments are listed in date ascending order (oldest first) | Post Comment
| ||
|
|