Kirill Grouchnikov's Blog

"Death to the Browser" - bring on a real application platform

What is needed is the Post Browser, the Next Browser, whatever name you want to give to it. Sure, it can still run HTML (the old stuff), in a container that is essentially the same as today's browser. However it should be capable of complete look-and-feel customization via a standard markup language. It should provide a rich set of custom controls and be able to access the desktop (with appropriate security, of course). It should have a native, secure, bidirectional mechanism, and one that supports multiple connections so that we can access services from multiple sources in a composite application. It should also have extensible controls so that we can extend and improve the behavior of controls and applications as needed. Furthermore those extensions should become part of the next release of the standard, which shouldn't take years to come forward.

Comments

• I think you misread the intent of Mr. Rhody's request. Swing, and correct me if I'm wrong as Java creates new acronyms every second so it's hard to always be current, is for creating thick apps. Your application is installed on the client's machine (or at least the client portion is).

  What is being asked for is a robust thin app framework. The advantages of a thin app are well documented, as well as the glaring disadvantage Rhody is complaining about. I don't think waiting on a new browser is the answer, or even needed. AJAX is proving to be a great fill in the gap, and the latest Flash offers a much better applet framework than java did.

  Right now, I feel like we are in a thick app / thin app tug'o'war... each side pulling because they feel their method is best... hopefully we might reach an understanding of right tool for the right job over one size fits all, but I wouldn't hold my breath.

  Posted by: neelm on November 01, 2005 at 06:02 AM

• Thanks for the mention of flying saucer :-) Perhaps you didn't know that flying saucer has a pluggable mechanism for substituting any JComponent for an XML tag. In xhtml it is used for form components and images. What it is lacking will be added once we have use cases/enhancement requests.

  Posted by: tobega on November 01, 2005 at 06:22 AM

• neelm,
  It always baffles me to hear of web applocations as thin. It can not run without a browser (or other hosting environment), which is thick - hence it's thick itself. All AJAX applications require browser installation (that is present there due to aggressive Microsoft strategy of bundling IE with Windows machines), exactly as Swing applications require JRE to be installed. The only thing that makes Swing a lesser choice - JNLP sandbox restrictions.

  Posted by: kirillcool on November 01, 2005 at 06:35 AM

• For terminology's sake - web applications are thin. Source code, logic, and processing are done on the server side, and only presentation / some validation logic is performed on the client side. The 'fat' side would be applications where the model tier / validation and other such work beyond simple validation & presentation are done upon the client side, or the code for such exists on the client side.

  We can't argue web applications are thick because they need a browser, as Java applets / applications need a JRE. Otherwise we can apply that to any networked activity with a host and a client. FTP would be fat because you need an FTP client as an OS util. E-mail? RSS? Fat clients. Web services? Fat client because you need RMI APIs. Heck, even the ping utility would be a fat client, because ping has an executable file. I don't agree with that definition of any installed utility in an OS defines it as a fat client.

  You've got a great point about swing or other Java GUI apps though, as Java only needs the JRE & a remote start link. But there's a reason why applets haven't enjoyed popularity outside of chat & yahoo games.

  Posted by: phlogistic on November 01, 2005 at 02:28 PM

• Indeed, "thick" or "thin" clients is defined as where most of the work is done. But what we really want to get at is the deployment problem of updating clients, and the "thick" or "thin" definition is no longer directly correlated to this problem. In this respect, I would say that a Java WebStart application is just as thin as a browser-app. And to go back to the original definition of "thick" and "thin", it makes even more sense now to have "thick" clients than it did before, with all the desktop computing power going to waste. Or perhaps, to turn it around, we should all really be working with pretty dumb cheap terminals.

  Posted by: tobega on November 02, 2005 at 12:36 AM

• phlogistic,
  When you write a Swing application, it doesn't mean that it's not client-server. The business logic can reside on server side, while the client is GUI only with a little validation. The only real difference in this case is that JS / AJAX applications bring only a portion of source code to the client, while in traditional Swing client you load the whole source to the client side.
  Few points on this:

  In the long run, it's better to have the whole executable on client side in order to prevent multiple load of the same screen
  You can use very simple techniques for modularizing source code and loading pages in Swing as needed using URLClassLoader.

  So, what's really thick, and what aspect of AJAX application can't be replaced by Swing code (that has plethora of components without need to emulate them in DHTML)?

  Posted by: kirillcool on November 02, 2005 at 12:45 AM

• are you talking about roomity.com
  again?
  .V
  

  Posted by: netsql on November 02, 2005 at 05:25 AM

• Hi Kirill,
  is XUL (http://www.mozilla.org/projects/xul/) what you are looking for? In that case Firefox could be your "NextBrowser"; I don't know whether XUL has the same capabilities as Swing, but looking at Firefox and ThunderBird it seems to me it is quite good.

  Posted by: riccardocossu on November 02, 2005 at 05:45 AM

• Sorry, but the thick or thin definition we are using does not make any sense to the user.
  One of our customers is an hospital. Poeple use various applications.
  Half a dozen are web based, they start up instantly (link on the desktop that points to the entry web page) and you can use all of them at once if you need to -> they are thin.
  Then there are two Swing apps. Open both of them on the 128MB that most PC's have in that place and you have reduced the PC to his knees, plus they take a few seconds to start up -> this is thick.

  Please, how can you compare web apps on an equal footing to HTML apps when the former sucks at least 30MB for each app started when the latter goes more or less un-noticed by the user?
  

  Posted by: aaime on November 02, 2005 at 05:54 AM

• Nice blog entry Kirill,
  At the cajo project we have a tiny 11kB Java application that can remotely host any Swing or AWT UI. What is really distincitive is how simple and intuitive developing for it is. It is literally transparent to applications. If you haven't had the chance, please take a minute to look at the example wiki:

  http://wiki.java.net/bin/view/Communications/ProxyUsage

  I think you would be very pleasantly intrigued!
  To further confuse the issue: It also works perfectly in browsers! :-)

  Posted by: cajo on November 02, 2005 at 06:18 AM

• netsql,
  Never talked about roomity, and since you so wanted me to try it, this is the exception i get in firefox:

  Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
  at x.y.z.cl.a(Unknown Source)
  at x.y.z.eP.b(Unknown Source)
  at com.bapp.Start.createAndShowGui(Unknown Source)
  at x.y.z.ds.run(Unknown Source)
  at java.awt.event.InvocationEvent.dispatch(Unknown Source)
  at java.awt.EventQueue.dispatchEvent(Unknown Source)
  at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
  at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
  at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
  at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
  at java.awt.EventDispatchThread.run(Unknown Source)
  Caused by: java.lang.NullPointerException
  at org.jdesktop.jdic.init.JdicManager.initShareNative(JdicManager.java:129)
  at org.jdesktop.jdic.browser.WebBrowser.(WebBrowser.java:80)
  ... 12 more

  Posted by: kirillcool on November 02, 2005 at 06:45 AM

• The main problem with web based clients is that the interactivty and response time depends vastly on N/W bandwith.
  Eerytime a link is clicked/submitted the entire page and its contents have to be transmitted across the web. Although AJAX alleviates the problem ,for continously changing interfaces it offfers no solution. Then comes the perennial problem of rendering / testing of a page on various browsers.

  Rich/Thick clients are a solution to both these problems and Swing (with its vastly improved API)in particular is the perfect technology to create these thick clients.

  Posted by: psychostud on November 02, 2005 at 10:07 AM

• aaime: "...Open both of them on the 128MB that most PC's have in that place and you have reduced the PC to his knees, plus they take a few seconds to start up -> this is thick."

  
  Kind of depends on the task the application is trying to do doesn't it? The 2 Swing apps are probably doing a hell of a lot more than the web apps since they use 30MB. Try putting a power application like that on an app server and open it up to hundreds of users and watch your app server reach it's knees very quickly.

  
  P.S. Great blog Kirill! We've been wondering when everyone will wake up and realize that the JRE IS the super-browser. Add the MVM and it should easily become the desktop.

  Posted by: evickroy on November 02, 2005 at 05:13 PM

• Evickroy, nope, they aren't doing more for the most part, besides a few things that cannot be done at all on a web app (workflow design).

  Have you ever looked at how much memory is used by an empty JFrame? No less than 16MB, more probably 20MB.
  Add a button that does something stupid, like concatenating strings,
  and press it repeatedly. After a while the memory usage is around 30MB and it won't go down... and if you're not careful and set some parameters like -XX:MaxHeapFreeRatio you'll end up with something that's using all the 64 MB of heap without good reason (they are allocated, not really used, but without the parameter above the JVM won't release the heap).

  And oh, if you are using windows you'll have to look at the virtual memory consumption, the bare memory utilization only tells you how much of the application is in memory now, the rest is usually swapped...

  Posted by: aaime on November 02, 2005 at 11:31 PM

• There's a catch. SWING applications deployed via WebStart are still compiled and run in a sandbox. That step is too slow, SWING is too hard for newbies. All in all the complexities of developing killer GUI applications need to be reduced even further, granting that it has become better. Don't get me wrong: SWING is a great API. I use it every day and I can handle it well. But it has cost me years of learning. Plus I see people coming from the VB world looking at me in astonishment how difficult it is with Java to deal with "simple" applications. So. How I see Seans proposal is this. We need a dynamic, easy to learn programming language, possibly Ruby, where the coding is done at the server and the application does not run(!) at the client, but that is brought there via "http+". SWING was a good step in the right direction. So was Java. It's time to move on.

  Posted by: norb on November 03, 2005 at 01:47 AM

• Hi

  Please can any one help me to manage a stick up footer on the website for IE 5.0 +. Its designed in CSS or JavaScript or Both.

  As you can see 1 on http://www.bmw.co.uk . Any kind of help is highly appriciated.

  thanks

  Imran Hashmi
  http://www.visionstudio.co.uk

  Posted by: itsonlychand on November 03, 2005 at 03:26 PM

This work is licensed under a Creative Commons License.