 |
REQ: alt.web-browser.die.die.die
Posted by javakiddy on June 30, 2006 at 05:55 PM | Comments (19)
In Where Swing should Venture Eitan Suez ponders the possibilities of making Swing applications deployable as web apps. Flip a deployment switch one way and you get a desktop application, another way and you get a web app.
Now I don't want to attack Eitan's comments directly, but for me his blog raises a more general point about the way user-facing software has been going recently. And so with good humour (and tongue planted firmly in cheek) I feel compelled to ask the following: why does everyone want the web to look and feel like a desktop app?
(Or, put another way: can't we desktop developers have an API all to ourselves, without the web apps mob muscling in?)
Even if we solved the practical issues (for example, until you can replicate Java2D, all you'll achieve is a feeble subset of Swing) there is still the issue of banging nails in with screwdrivers. Swing isn't a web API, and it was never intended to be one. And while the gap is very slowly closing between AJAX/etc and the desktop, the two platforms are still separated by a chasm in functionality which would cause even Evel Knievel to wet his pants.
I welcome more sophisticated tools for developing interactive web pages (hence my article on GWT on java.net) but I have to question the wisdom of taking this to the extreme of creating mail clients, spreadsheets and word processors via the web. Yes, I use GMail — but I'm only using the web interface because Google have yet to see the sense in making a Web Start client.
"Oh, but Java isn't as omnipresent as a web browser. Only a percentage have Java, while everyone has a web browser..." True as that statement may be, it doesn't alter the fact that GMail et al are a kludge, a fix, a hack, a work-around, a bit of gaffer tape to hold something together until a better solution comes along. They are not the solution. They are not even a step on the road to a solution. They are a diversion down a path which can only result in a dead end. The solution is to actually develop and popularise a true desktop application deployment mechanism which can match the 'go anywhere' spirit of web URLs.
So instead of taxing our little grey cells on how to make the web work exactly like Swing, why don't we throw ourselves behind the problem of getting Swing to deploy just like the web?
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Nicely put Simon, I especially like the title!I firmly believe that if Google released a slick WebStart client for Gmail, this whole lack of Java deployment argument would disappear virtually overnight.It is actually quite easy to deploy swing clients over the network, even transparently, once you let go of this whole 'web app' ball and chain.John
Posted by: cajo on July 01, 2006 at 06:37 AM
-
+1
Very well said. The only problem I see is that there already is a solution to this and as you all know it is called Webstart. It just has to be polished a little (like finer grained security policies ("all-permissions" anyone?) and a better reputation).
Sebastian
Posted by: yguy on July 02, 2006 at 01:40 AM
-
+1, damn web apps are the root of all evil. I propose we ban HTTP, everyone knows that the Internets can continue to fill its primary function (porn delivery system) with no more than HTTP.
Posted by: monkeyfuel on July 03, 2006 at 04:01 AM
-
I (of course) love all things Java... but
I also love Gmail's existing interfaces for a variety of reasons:
I access my email from a variety of computers... work, home, kiosks, etc. and Gmail's browser interface can be run "anywhere" without having to install a plugin (important on machines that don't belong to me).Gmail supports user interfaces for "small" browsers such as the one on my PocketPC and mobile phone.Gmail supports "rich" email clients via POP: Outlook, Eudora, Netscape mail.
Perhaps if I spent more of my time with a single computer I'd be more excited by the prospect of Desktop applications... but that's not the case for me anymore.
-JohnR
Posted by: johnreynolds on July 03, 2006 at 05:58 AM
-
I hear what you are saying John, but there's no reason at all why WebStart can't cover points your one and two (three isn't really a UI issue at all) right now or at some point in the near future.
It seems many (not just the Java clan) are expending huge amounts of effort trying to tame an unsuitable solution, when we (the Java clan) could be pushing to gets a very suitable solution (namely WebStart) deployed more widely. What makes this particularly frustraiting is that Java is in a 'space race' against Vista, with its 'managed code' environment (CLR) fitted as standard. This gives MS the ability to run applications in a safe 'go anywhere' fashion just like WS. Whoever hits critical (market share) mass first may well dominate the desktop for the foreseeable future.
Posted by: javakiddy on July 03, 2006 at 07:18 AM
-
JohnR,There really is no reason why Google could not provide both; rich internet clients for Java devices, and AJaX hobbled interfaces for 'functionally challenged' devices. ;-)To set one's aim at supporting the lowest common denominator, is destined to disappoint.JohnC
Posted by: cajo on July 03, 2006 at 09:20 AM
-
i most enjoyed reading this entry. i particularly like the important points you make about the fact that swing was not designed for the web and that web and desktop apps are different. a good web framework should come about by designing something fit for it, not adapting something that wasn't designed for it. so the verdict is: if you want to distribute and deploy a swing app, address issues of distribution and deployment, don't try to turn the swing app into a web app. makes sense. ok, so there's webstart, and there are always things that could be done to improve the experience of deployment. i've read about improvements in that area with java 6. what do you suggest for distribution? one solution: simply making a swing app a web services client. what do you think of the canoo product?
Posted by: eitan on July 03, 2006 at 12:24 PM
-
No.. webstart sucks compared to ... say .. Flash. With Flash I don't have to think about it.. webstart still assumes I want to "download" an app. Usually if it's webstart.. I don't even look at it.. I'm sure there's a lot of people like me.
That being said.. I also hate flash. But at least it doesn't get in my way.
Posted by: dog on July 03, 2006 at 01:19 PM
-
>> So instead of taxing our little grey cells on how to make the web work exactly like Swing, why don't we throw >> ourselves behind the problem of getting Swing to deploy just like the web? I wish!! Just keep posting this blog until the penny drops with everyone else!!
Posted by: gdonalds01 on July 03, 2006 at 02:17 PM
-
Eitan, nice to hear from you.
Canoo is a product I've no first hand experience at, so I can only judge by reputation and online materials. If I understand Canoo correctly, it makes Swing components act a little like RMI stubs, in so far as every significant GUI action is bounced back to a corresponding component class on the server (right?) In which case it is even more thin a client technology than Ajax. While it may be exceptionally useful in circumstances where the client has little memory but a fat network connection, I wonder whether it is really that useful on the desktop(...?)
Or maybe I'm just too ignorant of Canoo to truly appreciate it...? :)
Posted by: javakiddy on July 03, 2006 at 02:42 PM
-
Is there anything Java2D does that Flash can't do better? Regardless of whoever implements it, the web is moving towards a desktop-y feel, and it will go there with or without Swing itself.
You can't beat applications that feature minimal startup time, and are persistent across multiple machines. People won't want to download the same thing again wherever they use it.
We certainly aren't posting here thanks to a webstart Swing app...
Posted by: ilazarte on July 03, 2006 at 08:34 PM
-
Thanks for this entry! Let's stop messing with JavaScript and start doing things more systematically!
Posted by: imichtch on July 04, 2006 at 12:52 AM
-
Simon, right on. The entire attempt to desktopify the web with JavaScript etc. is pure horror -- that is from a developers point of view, yet as a user it's great. So, the subtext of this discussion is that people like applications GMail & Co. because it is readily available and easy to use. The question you raised however is about what we'd like to do as developers. Personally, I do not want to spend my time with development where the entire platform is broken. Sure, the tools available are nice and nifty, but it just feels too awkward. Whenever I develop a webapp I feel like I am building huge bridges over oceans of water and I keep asking myself why not build a boat?
Posted by: norb on July 04, 2006 at 01:32 AM
-
ilazarte, there's actually quite a lot that Java2D does that Flash cannot. While Flash is basically a scriptable animation/presentation engine, Java2D allows the programmer to easily work with the raw graphics data, raw drawing operations, and (via compatible and volatile images) some degree of sympathy with the underlying video hardware.
Your point about the initial download times of WebStart apps is valid, though. You're right -- this is something which needs addressing if WS is to prosper. But I would counter with two questions: (a) if you're resorting to Flash to augment your Ajax applications, doesn't that point to a fundemental flaw in your choice of Ajax to begin with? and (b) what is the difference between downloading GMail implemented in WebStart and GMail implemented in Flash?
Posted by: javakiddy on July 04, 2006 at 06:05 AM
-
Since Flash 8 or so, Flash can do a wide variety of bitmap realtime effects, including out of the box ones like blur. Couple that with it's proprietary video format, and you have a cross platform mm behemoth.
I *completely* agree with regard to feature to feature comparison. I don't doubt that the Java platform can match pound for pound the features that any Ajax+Flash combo could provide. Where it's ahead of the game is 0 startup time, transparency, and development ease/ubiquity. The last item I don't care about since modern IDE's really make development too easy imo. The first two are the big ones though. I'm cheering for Java, but we haven't seen much progress on really having a seemless browser application that doesn't announce itself; whether its the Webstart launcher, or the pause, or the telltale Java icon in the system tray.
I'm pulling for Java though! Come through for us Sun!
Posted by: ilazarte on July 04, 2006 at 01:39 PM
-
The truth is that when deploying to the default audience you use the default system: html-javascript. The problem is that html-javascript is a horrible vehicle for applications. The sad part is that even java.net does not think it's audience is sophisticated enough to use webstart for something like posting messages.
Posted by: jseltzer on July 06, 2006 at 07:44 AM
-
There's a project to make a remote GUI protocol, called Extemsible User-interface Protocol, or XUP, with a description and fairly complete prototype client at www.openxup.org. This is a component-oriented protocol which makes it different from remote desktop or X windows - imagine replacing the GUI events and set properties method calls with messages sent over a network (in this case, SOAP). The UI client is written in .NET, but the UI definition messages are similar to Swing, and a Java/Swing client should be pretty easy.
I've been working on something like that on my own, Holistic Interface Control Protocol, or HICP. It differs in using a persistent connection, like telnet, rather than SOAP over HTTP, and having a much lower level protocol - also in that I don't have anything working beyond being able to open and close windows with labels and buttons.
Either way, these provide a far better granularity for displaying genuinely rich user interfaces, with far less work than AJAX, and the same zero deployment that web apps have - users would only ever have to have a viewer, without any further downloads for any server-based applications, no matter how complex.
Posted by: jbayko on July 06, 2006 at 08:20 PM
-
I'd just like to follow up with a couple of details on Canoo's "thin Swing" product, UltraLightClient (available at: http://www.canoo.com/ulc):
UltraLightClient is an add-on technology for Swing rather than a competitor. While conventional Swing applications have a client-side architecture, the Canoo library offers the add-on technology required to leverage Swing's functionality in a server-side web architecture, i.e. it bridges the gap between Swing's rich UI components and a server-side web architecture.
ULC apps are deployed on the server. The UI is displayed by a "Presentation Engine", solving typical deployment issues associated with conventional Java clients:
this Presentation Engine can serve any number of applications, just like a browser.
it's small (about 500K in size)
it supports multiple JRE releases and works out-of-the-box on many clients, because most clients have some version of Java installed today, either as a browser plug-in, or on the desktop.
The programming model and the execution model are server-side. Applications are installed and executed on the server. The client runs a compiled Presentation Engine that is independent of individual applications.
The download includes a number of sample apps with source code:
http://www.canoo.com/ulc/downloads/index.html
[Removed client testimonials: sorry, read far too much like an advert. SEM]
Customers are excited about the benefits. A couple of mission-critical enterprise apps with complex GUIs have made the move:
e.g. at Siemens, 5000 users are managing financial guarantees with a ULC app:
http://www.canoo.com/ulc/successstories/companies/sfs.html
Navis, leading provider of cargo logistics software, uses ULC to offers a web-based version of its container terminal operating system:
http://www.canoo.com/ulc/successstories/companies/navis.html
-->
Sandra (I work for Canoo :)
Posted by: sandra on July 07, 2006 at 03:36 AM
-
XXX Disney Porn
INCEST
Gary Roberts Art & Comics
-->
Posted by: qspider on February 23, 2007 at 06:05 AM
|