Simon Morris's Blog

A Rose By Any Other Name

Oscar Wilde once famously remarked that Britain and America were two nations divided by a common language*. Of course, we've all heard the urban legends of Brits innocently employing their vernacular to ask for cigarettes in America, and the misadventures of American tourists dealing with the twisted logic of British place names, remnants of a few millenia assimilating every passing Viking, Norman, Celt, and Roman — not to mention a large portion of the German royal family. (Yes, it's written "Leicester Square", but it's pronounced "Throatwarbler Mangrove".)

[*] = Some credit George Bernard Shaw, although it seems neither man actually used quite those words. [The Top Three Quotation Origin Requests]

Yes, language can be a slippery thing at the best of times. The potential for ambiguity is high even when all parties agree on the terms in use, but when terms are subject to malleability, discourse can quickly descend into a babble of cross purposes and conversational blind alleys. Fabrizio Giudici recently fell foul to such polysemy in his blog, in which he is troubled by an imprecise definition of 'Rich Internet Application'.

It highlights an interesting question: what do we mean by Rich Internet Application? And, more importantly, which of the many and various solutions which go by that name is the most likely to succeed?

Comments

• Have enjoyed your fresh perspective on things but I have to disagree with your depreciation for the browser as a platform/VM. The ubiquity and maturity of browser software solves many traditional problems in client-server architectures and though not optimal by some standards, many times lead to the best possible product.

  Some of the technologies you mention might look like crp in the eyes of a purist but if developers are using them that means that the alternatives we have are even worst :)

  How do you think a Google Gear implementation of a GMail (or generic) email client would measure up to Thunderbird (and its million settings every time I install it)..? (http://synodinos.wordpress.com/2007/06/03/google-gears-and-others-bite-the-dust/)

  Posted by: synodinos on June 12, 2007 at 09:27 AM

• "Browserism", "Neo-Desktopism"... Classic. Very funny terminology! I think you've pegged the industry right now in a very light humored way. This is going to be the next major software showdown.

  Posted by: bobsledbob on June 12, 2007 at 12:40 PM

• Awesome article Simon! I totally agree with what you say. “Browserists” forget about user experience. Do applications and services exist to serve users, or do user's have to bend to the will of inadequate applications? Only in the software industry does such insanity exist! Other industries, which heavily rely on technology, like automotive, do a great job of integrating and hiding technology behind intuitive user interfaces, and deliver a human-friendly user experience. My issue with all of these technologies is that they forget that humans consume content and services, via these apps and services. And currently, there is piss poor support for service enablement!!! All these web2.0/ajax bigots keep touting the browser + javascript as the answer to everything, but they don't pay attention to their web app consuming more than one service :).

  My background is enterprise computing and I can see a total dichotomy in people coming at solutions who have a commercial software background vs. enterprise software. People in the enterprise will pay thousands of dollars for total crap software, that barely does what it’s supposed to, and has a complete crap user experience. And on the desktop, people seemed to have stopped innovating… there are obviously exceptions to this… Apple comes to mind. Microsoft’s Office 2007 comes to mind as well. And Xbox 360 and Live come to mind… content is king, desirable services are king, and the delivery of this via a compelling user experience is king. Lots of people seem to forget all of this… it’s all about picking the technology to enable the lowest common denominator development teams to build the lowest common denominator apps, cheaply.

  People forget that writing good software is as much art as it is science! And when creating user experiences it’s even more art than engineering. And I don’t see why the two shouldn’t comingle and come together to deliver the best experience to the user… leveraging all the good things in enterprise software and software built for the consumer space… I think people’s expectations for software are very low. And I can't blame them… most websites and software is just plain ugly! Created by people who don’t know how to communicate with others, and in an environment where it’s ok to deliver quick and deliver cheap… and deliver crap.

  Posted by: nazmulidris on June 12, 2007 at 01:05 PM

• @synodinos : How do you think a Google Gear implementation of a GMail (or generic) email client would measure up to Thunderbird (and its million settings every time I install it)..?

  I'm not sure millions of configuration options are a compulsory part of desktop software. That is just the path the people on the Thunderbird project have decided to take. Playing devil's advocate (while also being very cruel) I might venture that the lack of configuration options on GMail is more a result of its lack of functionality (one need not configure what does not exist) than any measure of 'intrinsic superiority' over desktop apps. ;)

  Actually, I'm not that cruel. I recognise that web apps do that their advantages -- but beware, these are not advantages which cannot be copied by desktop (or even neo-desktop) software.

  Posted by: javakiddy on June 12, 2007 at 01:15 PM

• Hey Simon...

  I've never been called a Neo-desktopism -- interesting... :-)

  Anyways, my point is that if the mobile user experience and mobile context is to be maximized/leveraged today, it is about local.

  For simple web content consumption that doesn't need to leverage the handset capabilities, go browser-based.

  That is all my argument -- today vs. tomorrow, theory vs. practice. I've written quite a bit about this exact topic on my blog, and no need to rehash here...

  The panel discussion at JavaOne was not only between an "Browserist and Neo-desktopism" as you called it -- it would have been cooler to be called Neo-mobilitism -- but it was between a "Theorist vs. a practitioner", and as you know, "...in theory, there is no difference between theory and practice. But, in practice, there is".

  I am all about what is next, but also about what is today... let's keep it real and minimize confusiion, especially for those who want (need) to monetize today. More about this specific topic at: About Mobile Web 2.0 Practice, Theory and Timeframes

  ceo

  Posted by: eortiz on June 12, 2007 at 04:11 PM

• great stuff! thanks for a good read, with some guffaws about browserists eg. "wow, you can drag the map!" and saving to disk, hee hee! Us desktopists are planning a rearguard action innit. Problem is... well, people ;)

  Posted by: evanx on June 13, 2007 at 02:04 AM

• @javakiddy: ...the lack of configuration options on GMail is more a result of its lack of functionality

  My complain about FF was not the fact that it has many configuration option, actually I enjoy customization as any other geek. The problem with desktop apps is that the in the vast majority of s/w packages there is not a clean/easy way to export the customization settings, so every new installation is followed by a time consuming period of applying settings.

  In the case of a novice user, this can be frustrating.
  In the case of a power user, this can be daunting.
  In the case of an administrator, this can be a nightmare.
  And personally in the case of my PC crashing, it's spending the rest of the week in limbo.
  

  (thanks again for the interesting article)

  Posted by: synodinos on June 13, 2007 at 03:18 AM

• @eortiz: It was perhaps a little dangerous to throw an example from the mobile arena into my blog, given that that space is filled with a lot of other issues which are unrelated to my central point about technology (for example, as you point out, the mobile platform is still trying to explore ways of maximising revenue streams from the emerging mobile market.)

  I think the biggest mistake Tim O'Reilly made with his 'seven principles' was that he tried to define a new type of application by tying it to a concrete platform (the browser and Ajax.) I seem to recall a blog from Tim recently in which he regrets using the term "web" in "Web 2.0". But now the same 'religion' is being taken into the mobile space, where the browsers is seen as being the only means by which collaborative/buddy-centric/etc applications can be delivered.

  I'm tempted to write a "The Web 2.0 Delusion" blog, in which I debunk some of the technology claims made in Tim's seven principles. For example, his claims that "Gmail has already provided some interesting innovations in email [...] with user interfaces that approach PC interfaces in usability." and "[...]Google Maps, web based applications with rich user interfaces and PC-equivalent interactivity." is clearly as provably false as saying the Earth is only 6,000 years old. But Web 2.0 isn't really my main concern (the underlying technology is) and I get the feeling by writing such a blog I'd be walking into a huge minefield of issues. :)

  I should point out I do not take issue with any of the abstract concepts behind Web 2.0 -- merely the fact that its followers seem to want to anoint the browser as the only means of delivering them.

  Posted by: javakiddy on June 13, 2007 at 03:33 AM

• First thank you for reading what indoubtedly is my worse blog post ever :-/ But undoubtedly there is some confusion around and rather than "a rose by any other name" I think the point is "nomina sunt consequentia rerum" - absolutely no intention of bringing up an anglo-saxon vs latin war ;-) but recently there have been a lot of announcements and it's easy to get lost in a forest of marketing buzzwords. So I'd like to focus on what each technology _has been designed for_, thus what it delivers best.

  "a technology being used totally in contradiction to its original intended purpose."

  The above is precisely my point. Which doesn't mean (@ synodinos) that it necessarily doesn't work, but that probably there are better ways to do that thing.

  Posted by: fabriziogiudici on June 13, 2007 at 05:36 AM

• @javakiddy: Simon, if you write "The Web 2.0 Delusion" blog, I might consider joining you, and write the mobile side of it... :-) ceo

  Posted by: eortiz on June 13, 2007 at 08:51 AM

• I see your Leicester, and I raise you an Arkansas. :D

  Posted by: rickcarson on June 13, 2007 at 05:56 PM

• There are some more fundamental considerations such as:

  Where is the data stored, locally or remotely? If you answer remotely, then a whole bunch of other factors kick in, such as the network not being reliable (however, as the network gets faster, the cost of our collection delusion of an reliable network gets cheaper and cheaper).

  What the browser brings to the table is a deployment mechanism. Java itself also has an excellent deployment mechanism (jars). But 99 times out of 100 when I'm getting a jar it is by downloading over the internet - which indicates that of the two it is the more fundamental mechanism. Even the majority of my desktop applications were served up over the net (nb: legally) (and of those that weren't (e.g. the OS), they are updated over the net)

  Where the browser and the net get into trouble is that html is inherently stateless and static, yet we keep trying to cram stateful and dynamic functionality on top of it.

  Moreover, the browser is not a mature solution, because it is not standardised. Until we can get consistent implementations (and specifications) of things as fundamental to the browserists as CSS and Javascript, then it is not mature.

  Where is your application logic stored? Someone had an excellent article that pointed out that if your startup was based on mashups, then your whole business could be ripped out from under you by other people simply by them changing (or withdrawing) their API.

  Posted by: rickcarson on June 13, 2007 at 06:44 PM

• Yes, I believe that was "Raymond Luxury Yacht" that was pronounced "Throatwarbler Mangrove". Thanks, Monty!

  Posted by: escape_llc on June 14, 2007 at 10:41 AM

• rickcarson wrote: "Moreover, the browser is not a mature solution, because it is not standardised. Until we can get consistent implementations (and specifications) of things as fundamental to the browserists as CSS and Javascript, then it is not mature."

  But, here's the rub. The "browser" IS stable and mature. To be specific, individual implementations of clients called "Browsers" are stable and mature.

  FF2, IE7, etc. are VERY powerful pieces of software upon which to write applications.

  Where the immaturity kicks in is in the adoption and implementation of standards with similar behaviors ACROSS the implementation.

  Just to confuse Simon, what IS Thunderbird? Is it Browserism or is it Neo-Desktopism? The VAST builk of Thunderbird is written in Javascript. The overarching goal is to further get the runtime behind Thunderbird (and Firefox) refactored so that it can be a headless system to upon which to better write client applications.

  But, in their basic form, Firefox and Thunderbird are both, at their core, a set of native services with the XUL and Javascript layer integrated on top of them, and the actual Firefox and Thunderbird functions and presentation are managed all in the "languages of the web", so to speak.

  The modern browsers are becoming the "4GLs" of the early 90's. Those who were writing apps in VB 3 and PowerBuilder Back In The Day are looking at HTML and the modern Widget sets today. Whereas the 4GLs of old were bound to some flavor of SQL database to really get their value, today we have web services (of some flavor) filling that role.

  The immaturity of the browser client platform is really moreso in the development tools section, and in truth even then it's not really horrible. FF, Safari, and IE7 have several tools to support client development. And FF3 is moving the bar up with its advances in Javascript 2.

  No matter what, if you're a in house corporate developer, and you want to push your application "to the limits", then you're going to be creating something "client specific", whether that client is Flash 9, Java, FF2, IE7, or .NET, if you want to squeeze out every bit of functionality and not get trapped by the Lowest Common Denominator of cross browser compatibility, then you're picking a client and sticking with it. The clients themselves are very capable, it's their compatability across vendors that are immature. If you toss that requirement out (which is very practical for internal applications -- if you can pick VB, you can pick Firefox...), then you can have a field day.

  But make no mistake, the browsers are converging and the LCD of behavior is climbing every year. And the developer space is muddled and confused specifically because of the browsers increasing capabilities.

  Posted by: whartung on June 14, 2007 at 02:45 PM

• @whartung: Just to confuse Simon, what IS Thunderbird? Is it Browserism or is it Neo-Desktopism?

  Tiz neither. Thunderbird is not an RIA, it is an old style client-installed desktop application. :)

  FF2, IE7, etc. are VERY powerful pieces of software upon which to write applications.

  Strange, then, that nobody seems to bother. Why is that? Put another way, why does GMail look like GMail, and not like Outlook, Eudora, Thunderbird or any of the other truly rich UI experiences? Was this a conscious rejection of the UI of existing clients, or a recognition that the browser platform can only do so much?

  Here is the challenge: The original 1.0 version of Photoshop was release in February 1990 on the Mac (says Wikipedia.) While much of the UI will have needed to be bespoke coded, it nevertheless fitted quite happily atop the software foundation it was written on. There's nothing special about the Mac, Photoshop could just as easily have been written on a DOS PC, an Amiga, and Atari ST... All of them would have provided a software toolkit rich enough to write such an application. We are now over seventeen years since that initial release. How many years will it take the browser platform to develop its UI capabilities to a point where it could natively run a port of Photoshop v1.0 with all the UI fidelity of the original?

  You might answer, "aha, but I could use Flash or applets!" to which I would siimply counter "then why do we bother with the browser at all?"

  :)

  Posted by: javakiddy on June 15, 2007 at 03:20 AM

• Tiz neither. Thunderbird is not an RIA, it is an old style client-installed desktop application. :)

  So you want to quibble about packaging and distribution, or is that what this whole thing is about?

  How would you label the Mozilla Amazon Browser then? www.faser.net/mab/chrome/content/mab.xul (require Firefox, of course). NeoDesktopism I assume. Because in truth the only real distinction between the MAB and Thunderbird is how its distributed and packaged. The core code driving the user experience is the same for both applications. And the FF team are striving to make an application like Thunderbird usable like the MAB is -- with the click of a URL.

  Strange, then, that nobody seems to bother. Why is that?

  Sure they do. Have you ever seen MS's Outlook Web Access (OWA) running in IE? Quite different from what you get in any other browser. Why is that? Because MS built IE up to be able to do things like OWA. My understanding is that we have XMLHttpRequest because MS wanted it for OWA.

  Do you see these kinds of apps in the wild? No. Because public "must have browser XYZ" apps (FEMA anyone?) are scorned upon for good reason. But behind the firewall? I've seen some very nice applications written for IE, and IE only.

  When you want to go cross browser, then the Lowest Common Denominator curse of compatibility puts a yoke on your neck. Like the poor souls who are still maintaining Java 1.1 applets. I mean, Google wrote an XSLT engine in JavaScript to support some browser that was lacking it.

  How many years will it take the browser platform to develop its UI capabilities to a point where it could natively run a port of Photoshop v1.0 with all the UI fidelity of the original?

  First off, rather than "how many years until", how about "and what do we do then when we can write Photoshop 1.0".

  Next, when you say "browser platform", what do you mean? Do I have be able to run Photoshop in Lynx? What if I can run it in Safari, but not FF or IE, does that count?

  Rasterizing bit images have been lacking in the web space for some time. But even that is changing today. Safari and Firefox both have a "canvas" tag that allows "Java 2D" like operations to be performed on them. So, you get paths, compositing, and it also gives access to the image data in raw form.

  The real limitation between that capability and PhotoShop 1.0 may well be limited by the JavaScript performance (particularly for the image analysis and filters), or by any imposed memory limitations.

  But as is, it seems more than capable enough to create something along the lines of MS Paint. And, it seems particularly well suited to something like a MacDraw kind of "object" based drawing program.

  Don't think you'll be writing Word using the canvas tag as they seem to not allow Fonts and Text in the tag. But that's a simple oversight. I mean, seriously, there's nothing stopping them really from exposing the entire underlying Java2D like rendering model to something like the Canvas tag. They have just chosen not to for some reason.

  Because what did the Mac provide? A blitter / QuickDraw and events. Canvas and the browser provide that now, so if Javascript is performant enough, then it's just a matter of time, isn't it?

  Javascript is getting faster, and 2.0 should show some solid gains, particularly with the use of sealed classes.

  Frankly, the most glaring thing right now is that Canvas punted on drawing text. If they added that ability to Canvas, I see no reason why a MacDraw style object based tool couldn't be crafted to run in the browser in short order.

  But the key is that the browsers are adding more and more functionality.

  They're closing gap. As I said, the browsers are the new 4GLs from the mid-90s. Computers have adequate performance to handle the tasks, so the browsers are going to be able to fill more and more of those roles.

  So, I'll reiterate: rather than asking "when will the browser do XYZ", answer the question "What do you do then?".

  Posted by: whartung on June 15, 2007 at 03:36 PM

• @whartung: So you want to quibble about packaging and distribution, or is that what this whole thing is about?

  That's what it is about, yes. RIAs do not require software installatiion.

  I fail to see why so much effort is being taken to re-implement all the software APIs we've had for decades (graphics, local I/O, widgets, socket I/O...) inside a web browser. Surely it would be easier to adapt the exisiting desktop software toolkits so the resulting applications could be loaded over the internet, rather than installed to local disk.

  Put another way: surely it would be easier to adapt the APIs/tools used to write Word, Photoshop, Excel, etc etc etc so they can load from the Internet, rather than re-write them from scratch inside a web browser environment. Why is the main effort being put into the latter rather than the former?

  Posted by: javakiddy on June 16, 2007 at 03:10 AM

• Nice article! Thanks a lot! And very interesting discussion. I only wonder what if instead of IE users would get another free tool with every and each new PC. For instance an application based on Eclipse RCP. This app should have a very catchy name (and very attractive icon ;-)) and be able to propose an access to rich repository of plug-ins. It should be extrimly user friendly and easy to use. So that in 30 minute one can get e-mail, word processor, video player etc. (as plug-ins, I assume that HTML brwser plug-ing is installed by default ;-)) So would users be concerned whether all that works outside browser or is not HTTP based?

  Posted by: imichtch on June 16, 2007 at 10:34 AM

• I fail to see why so much effort is being taken to re-implement all the software APIs we've had for decades (graphics, local I/O, widgets, socket I/O...) inside a web browser. Surely it would be easier to adapt the exisiting desktop software toolkits so the resulting applications could be loaded over the internet, rather than installed to local disk.

  Let's reword that, just for laughs.

  I fail to see why so much effort is being taken to re-implement all the software APIs we've had for decades (graphics, local I/O, widgets, socket I/O...) inside a virtual machine. Surely it would be easier to adapt the exisiting desktop software toolkits so the resulting applications could be compiled on the fly, rather than built for each platform.

  Here's the deal.

  The people in charge of those decade old APIs haven't been on this train. Also, those decade old APIs have been essentially monolithic, with a single point of control.

  All of these new wheels we see being reinvented are organic in nature. The platforms are both implementing standards and at the same time defining new ones.

  If Firefox didn't exist and put pressure on IE, none of this would have happened, as they drive each other in to new directions.

  The mistake that you make regarding the RIA is this:

  RIAs do not require software installatiion.

  Sure they do. ALL RIAs require software to be installed to run. Whether its a browser, a JVM, a Flash client, whatever.

  But some RIA platforms are more ubiquitous than others. Generic HTML browsers are more common than any other specific runtimes, and work in all sorts of different devices: desktops, handhelds, green screens, etc.

  From generic browsers you move on to the modern browsers, empowered by javascript. Then you throw in the VMs and plugins: Flash, Java, .NET, Squeak (???), dot dot dot.

  So when you target the most common of these RIA platforms, there's this implication that "you don't have to install anything". But anyone who has fought IE 5, then 6, and now 7, or encountered the "Must have IE to continue" really knows the fallacy of "not having to install anything". Only Mozilla and FF users can run the Mozilla Amazon Brower, for example.

  However, as the large internet companies have discovered, there's enough commonality across the ubiquitous modern browser, that the LCD of the modern browser offers a reasonably high level of functionality. Witness Yahoo effectively requiring a modern browser today for many of their services. Google only requires it for their advanced applications, but Yahoo pushes it on their front page.

  But not only are we fortunate enough to have a powerful and ubiquitous platform for application development, we're fortunate that such development isn't driven by a single company, but rather 3+ companies.

  IE getting better makes Firefox better which make Safari better which make IE better...

  Also, now, with the level of functionality of the modern browser, it is getting more and more difficult for a browser of less functionality to make any real inroads. Essentially, with the browser market as it is, you have to keep up to even play. It's not like you can charge less for a less functional browser today. The only real holdback today are handsets, and iPhone is here to try and put a nail in that idea.

  So, you have this wide ranging platform, getting pushed on several fronts, and being used by a gazillion people on the planet. These gazillion people represent a vast mindshare of idea makers, implementors, and consumers.

  The question now becomes, why shouldn't you push this platform? Why use a single sourced toolset and runtime when you can leverage the bubbling soup that is the modern browser wars and that every user already has access to?

  No one envisioned that the browers would be where they are today. In hindsight it seems like a waste of time and effort with all of the alternatives available. But the fact is, that's what happens with the feature creep. That's what happens in a competitive space.

  Most of what is being said about the browser and Javascript were said about Java years ago. The Java naysayers were wrong then, and they're wrong today. So, why wouldn't the browser naysayers be wrong today? Javascript 2.0 run on a VM with a JIT. Especially when we have so much more activity in this space -- Apple is releasing Safari on Windows for a specific reason. It's not as if Windows NEEDS another browser, but here we go!

  Is it a waste that the JS guys are writing their own VM and JIT vs using, say, Java? Yup!It sure is. But that's the not the JS guys fault, is it? They wanted a VM and a JIT for a free and open source tool, and Sun's wasn't quite there yet. So, off to the wheel shed again to carve out a new one. This new one will be 17.75 inches in diameter instead of the 18 inches of Java. Oh well.

  No, you can't create applications with quite the fidelity of Photoshop on the current browser platform. Not today. (Not yet...) I can't write Flash in Javascript.

  But, on the other hand, how many of these kinds of applications are written today? Now compare that to eleventy bazillion back office accounting and purchasing systems. Business programmers reinventing FORTY YEAR OLD wheels every day across the planet.

  Any platform can be used for "RIA, software that you don't have to install", assuming you have the runtime installed. The RIA argument has been used for years in all sorts of camps. C code is easier than, say, Lisp, to use on Unix machines because there's an enormous C runtime "for free" on Unix systems. Lisp advocates don't worry about things like EXEs or executables, they already have their runtime. Java programmers don't think twice about trying out a new Jar, their runtime is installed. Perl/Python/PHP run EVERYWHERE (that a runtime is installed...).

  But why not write to the platform that is not only already installed on your machine, but on everyone elses as well. While Flash has a huge installed base, Javascript is even higher. The programming language with the widest internet deployment in the world? (modulo embedded processors) Javascript. (Java may well be higher if you count J2ME handsets, but not all of those are connected.) If your market is the Internet, Javascript is there. Even cell phones are catching up.

  So, that's why folks are targeting the platform. That's why the platform is growing.

  If you want an easily deployable Photoshop, yup, you'll need to look somewhere else. But if you want an easily deployable app of some other kind, I think today you need to have a REALLY compelling reason to not target the browser client today.

  Posted by: whartung on June 16, 2007 at 05:14 PM

• @whartung: ALL RIAs require software to be installed to run. Whether its a browser, a JVM, a Flash client, whatever.

  That is pedantic in the extreme. It's like saying a major disadvantage of GMail is it needs a computer with an operating system installed.

  However, as the large internet companies have discovered, there's enough commonality across the ubiquitous modern browser, that the LCD of the modern browser offers a reasonably high level of functionality.

  There isn't. That's the problem. Browsers are fine if your application is forms based, the further one moves away from forms the weaker they get. So address book applications work well, email less so, word processing is isn't great, spreadsheets only just about work, and paint programs are almost impossible to implement. While, using the traditional desktop APIs all of these apps are unhindered.

  Any platform can be used for "RIA, software that you don't have to install", [...]

  I'm not sure if you quite grasp RIAs. The intent is that they never install on your computer. So to run Photoshop one would type "ria://ria.adobe,com/photoshop" into Windows, OSX or my Playstation 3, and Photoshop runs. And this works for the computer in the cybercafe down the road, my hotel room, my friend's house... etc... so long as I can prove I have a license to run the software.

  But why not write to the platform that is not only already installed on your machine, but on everyone elses as well.

  Because I might want to write software which isn't forms based, perhaps? Like a graphics utility, a video or sound editor, a spreadsheet, a reports tool, a file sharing client, a virus checker, a label printer, games...and a few dozen other general classifications of application which don't neatly fit into the shape of a form. ;)

  Posted by: javakiddy on June 17, 2007 at 09:52 AM

• That is pedantic in the extreme. It's like saying a major disadvantage of GMail is it needs a computer with an operating system installed.

  Umm...isn't this the core of the entire topic of this post? If Java were as ubiquitous and "hassle free" as HTML/CSS/Javascript, then we'd be having these discussion in the XUL forums, don't you think? Or all the Common Lisp wonks would be howling at the moon because they could write CL based RIAs that everyone can use.

  Simply put, GMail is not written in Java because of a) Ubiquity, b) Hassle factor (pick two). Neither are many of the other public facing RIA. The majority are HTML/JS, with some Flash.

  I mean, they're sharp guys at Google. They use Java. Yet, GMail is a Web 2.0 Ajax application. Heck, they even route around Java on the client by letting us actually WRITE Java but DEPLOY HTML/JS! With GWT, HTML/JS becomes a proxy JVM for the client code. No doubt some subtle semantics are lost in the translation.

  As I said earlier, it seems the only major stumbling block for higher fidelity Web apps is a better raster component, and JS performance. They're working on JS performance, I assume they're working on a better CANVAS tag.

  Once these come out, you're going to have to push the goal posts out even farther for what the "Web 2.0" JS/HTML client can't support in terms of applications.

  Of course, the applications that you mention seem to be fairly questionable for any RIA, simply because of their internal, machine bandwidth issues. The general overall infrastructure aren't really set up to manage things on the scale of large PhotoShop images, much less movies, either. The fact that I could run a net served Final Cut Pro from my PC or the one at my Mom's house is pretty well moot if I have to download my several GB of Movie data from my PC (or any host for that matter) to my Mom's PC to actually run it. If I need to bring several GBs of movie data in order to use my RIA movie editor, I may as well bring the software with me.

  I think it would be interesting if software vendors had the idea of transportable keys. That way I could drag my movie and FCP around on a hard drive, and plug it in to someone elses computer, "re-register" the software (which enables it on the new computer), edit away, yank out the hard drive, take it home, and re-register again (which disables the license on the other computer). Kinda like how my AIM chat windows automatically get nuked when I leave it on at home and login again at work.

  That way these ultra high bandwidth apps could easily move.

  If you want Java to fill the RIA space consumed by JS/HTML now, then the efforts need to be made to get it deployed as much and as easy and fast to use as JS/HTML is today. Pay Apple, Firefox and Opera (MS will tell you to pound sand) some cash money to "embed" the minimalist JWS downloader (not the JRE, just the piece that "knows" about JNLP). Or, distribute an ActiveX/Netscape plugin that does JWS instantly, just like Flash, and then push down the consumer JRE.

  But you have to hurry, because the browsers are not slowing down, and they're not going to wait for it. They have the scent and they're going for it.

  Posted by: whartung on June 18, 2007 at 06:59 PM

• God, I hate this blog software...

  Sorry about the Wall -o- Text

  [No problems. Previous comment edited to fix paragraph problem. SM]

  Posted by: whartung on June 18, 2007 at 07:00 PM

• Claiming that Google just deploy HTML/JS is not entirely true. Google provides also a set of client applications and plug-ins to access their services: Google Toolbar, Google Desktop and Google Talk client. And if you take the mobile space, you will see that Google recommends using the Java client applications they have developed instead of using the web access. Then you find Java applications for GMaps and GMail, that according with Google are up to five times faster and provide a much better user experience than the web versions. On the other hand, which is the difference between HTML+specific JS libraries+SQLite+Local web server and any other RIA platform?

  Posted by: trapalas on June 22, 2007 at 02:01 AM

• @trapalas:Claiming that Google just deploy HTML/JS is not entirely true.

  I wasn't aware anyone had made that claim.

  On the other hand, which is the difference between HTML+specific JS libraries+SQLite+Local web server and any other RIA platform?

  Applications written atop MFC, .NET, AWT or Swing do what they do because of MFC, .NET, AWT, Swing (insert your favourite toolkit here, eg. Qt.) Applications written atop Firefox, IE and/or Safari do what they do despite Firefox, IE and/or Safari. Okay, so that's a tad over critical, so let me qualify it: Browser apps are fine if all your application needs is forms. The further your application moves away from forms (word processing, then moving to spreadsheets, and finally at the extremes paint programs and then video editing) the more unsuitable the browser becomes as a platform, and consequently the less efficient and the less functional. RIA's written using desktop technologies like .NET and Swing can address the full 'application space' with equal ease. They provide a single technology which can address any application (including forms.)

  The optimum solution is to make rich applications like Word or Photoshop capable of being deployed in the same transient ('via URL') manner as a web page, rather than turning the web browser into .NET or Swing so it can be used to (re-)write Word or Photoshop.

  Posted by: javakiddy on June 22, 2007 at 02:53 AM

• The claim comes from a previous whartung's comment: whartung: I mean, they're sharp guys at Google. They use Java. Yet, GMail is a Web 2.0 Ajax application. Heck, they even route around Java on the client by letting us actually WRITE Java but DEPLOY HTML/JS! With GWT, HTML/JS becomes a proxy JVM for the client code. I agree on your vision about the "optimal solution", I think that something similar exists today and it is the XBAP deployment model in the .Net WPF. The first time I point my browser here and a complete 3D chess application got downloaded and started running in my desktop, I realized it was the right path.

  Posted by: trapalas on June 22, 2007 at 03:52 AM

• "Because it does not require a web browser to run, Java WebStart is an example of a Neo-Desktopism technology." Well, you'd be awfully hard pressed getting a hold of the app in the first place, without the ability to launch a HTTP GET and already have a runtime installed with ability to launch per META match. /Casper

  Posted by: mrmorris on July 01, 2007 at 07:39 AM

• @Casper: Well, you'd be awfully hard pressed getting a hold of the app in the first place, without the ability to launch a HTTP GET and already have a runtime installed with ability to launch per META match.

  Well that's easily fixed by adding an address bar to the WebStart GUI tool itself.

  Posted by: javakiddy on July 01, 2007 at 11:20 AM

• @trapalas: ...it is the XBAP deployment model in the .Net WPF. The first time I point my browser here and a complete 3D chess application got downloaded and started running in my desktop, I realized it was the right path.
  
  Is part of your 'optimal solution' that everybody switches to Win32? ;-)
  
  On my Mac, Safari just downloads a 5.1 KB 'Valil.Chess.WinFX.xbap' file...

  Posted by: vovtz on July 04, 2007 at 12:38 PM

This work is licensed under a Creative Commons License.