Related link: http://www.theserverside.com/articles/article.tss?l=RiAWeb
While — and this may be a faux pas here on O’Reilly, but I hate the “Web 2.0″ moniker anyway — I believe firmly that Java could have a future as a desktop development environment, I don’t buy this at all.
The main problem with this 2.01 development model is you immediately drop what is making 2.0 work so well: integration. With the singular client (browser) the user gets a lot of value-add to every web application. While AJAX tends to work “best”, Flash in limited doses doesn’t change it much. And here I am really talking about little things.
As I write this post, for instance, I am using “resizable text area” and the Google Toolbar’s Spell Check in FF. These DRASTICALLY increase the usability of the O’Reilly blogging system, yet don’t require the server to know anything about it. Other plug ins like Piggy Bank and other whole browsers like Flock continue to dial up the functionality the end user can have without the app developer knowing or having to worry about it. With a fat client, the only real functionality the user gets is that which the developer deems worthy of writing. Even if such a client included a plug in architecture, it most certainly would never have the broad support or utility of things like CTXExtensions, Greasemonkey and the rest of the FF space.
I agree... partially
Hi Robert,
I agree with your point, but with a few reservations. First, web browser-based applications, speaking directly from a standards perspective, are limited in how far they can they the "Web 2.0" moniker. Second, while browser plug-ins and extensions are nice, they're not something that every user will have installed, or even would install if they new it existed. With this in mind, a "Web 2.0" company must develop or implement the functionality, which given the first point, means they are limited to the set of standards supported by at least one, but in reality, all of the major browsers on the market.
Now an "install-on-demand" system that allows the ability to implement browser-enabled components would certainly be helpful, but both Java via Applets and Microsoft/Windows/Win32 via ActiveX have provided this capability since pretty much day one and, so far anyway, neither of them have been adopted in any great capacity. From an Intranet perspective they have, but from an Internet perspective too many issues with security have scared off any potential for ActiveX and in regards to Java Applets... I wouldn't even know where to start looking to make any attempt at understanding why they haven't become more widely accepted.
With this in mind, the notion of building classic desktop applications such as word processors, spread sheets, etc... within the context of a web browser have been blocked by the major majority of application developers and development companies. Changing that mind set will require an ability to showcase that secure, full-featured applications CAN be built within the scope of a web browser with expectation that the a major majority of clients will be able to run these applications with their browser of choice. Not an easy task as the language and platform options are EXTREMELY limited at the moment.
Technologies such as XAML, XUL, to some extents SVG, and other similar efforts could become the answer to this assumed problem ('assumed 'from the standpoint that with Java Applets and ActiveX the ability has and still exists, but in 10 years time are still not considered a viable option.) XPCOM could also provide a cross-platform way of developing web-focused applications, but Java offers this now, and convincing folks to develop XPCOM-based components in extended numbers using C++ isn't going to be an easy task. And with projects such as Mono implementing a cross-platform version of the CLI (.NET) standard, the ability to use any supported language (a long list) and gain cross-platform capability will prove to be a difficult benefit for many developers to overlook in regards to developing applications on top of the .NET framework.
Of course, with the popularity of Ruby on Rails, a lot of functionality is provided for you out of the box, making the job of server-based web application development EXTREMELY easy. But RoR is still, for the most part, a server-side technology, and until it implements extended functionality on the client, will continue to be seen as a server-side solution at a time when folks are beginning to shift their mentality towards what the client, and in particular the "fat browser", can offer them in regards to taking the load off of the server.
With all of this said, I still agree with your point that the browser is where its at. But the browser won't be replacing the classic desktop applications anytime soon. I have my doubts it ever will, even with extended compiled language support, but I will leave that one for a time when the compiled language support arrives and we have some time to see if folks adopt this in any great numbers.
With this last paragraph, then your point regarding the notion of a "Web 2.01" moniker is something I STRONGLY agree with. But the functionality gap between a web-based app and a classic client-side app is something that I think we are going to be left dealing with for quite some time to come.