I am an ERP Project Manager for 7 years within a big company which has many subsidiary companies. As ERP team, we are not only implementing ERP software but also writing our own ERP with the target that we sell this product in the future. Our platform is Java and our applications are web-based. Ibrahim has posted 11 posts at DZone. View Full User Profile

Are Rich Internet Applications Really Rich?

  • submit to reddit

As we started to search for an architecture for our ERP platform in 2001, there were 2 options to select in Java: desktop vs. web.

1- Desktop-Based Applications: If we select this option, 2 other ways to select; one is using AWT or Swing, the other way is building-buying a new component presentation framework. As my previous development experience Desktop Java was extremely difficult. Applications written in Java was not responsive as native windows applications. AWT and Swing was very heavy. Building a new presentation framework was another unknown way to go since requires many UI engineering effort(Layout-Window Management, Rendering, State Management, Event Model, Release Management, Server Communication etc.).

2- Web-Based Applications: Here we had another options; first is pure HTML and browser-based option, second is using Java in browsers (ie. Applets). Some ERP vendors, uses another option that's clients are web-based but doesn't require (or minimal setup) setup and loads applications on demand. Oracle ERP uses this model, its loader is JInitiator. Sun had offered similar function with its JNLP and Web Start technology.

What we selected is first option of Web-Based Applications; 100% web-based solution. Every option may be true in their context but in our context we had following motivation for this decision:

1- Web is shaping software world: After client-server applications era, every company tried to port their applications to web. But this was very hard since this selection requires very different technologies; HTTP, HTML, XHTML, DOM, XML, CSS, Ajax, JavaScript. ERP vendors still hasn't completed this effort since complete rewrite needed. Web world is still evolving; Web 2.0 and client-side Web is recently booming.

2- Browsers are deployment tool: One of the most important problems of application is release and deployment management. This problem had 2 part; 1st is for server-side and 2nd part is client-side. Web-based applications solves nearly all problems of client deployment since requires zero installation. Browsers are evolving in their own direction with many improvements and standard support (i.e. caching, rendering, new CSS specification support); browser-based Web applications utilize all new features with zero price.

3- Network is getting faster: One of the most important problems of the web application is downloading pages and its content. As the network speed increases every day, both in home and offices, web page downloading becomes faster and faster. This leads much more satisfactory user experience in the UI.

4- Web programming is easy: In Java, this is true but for other languages like VB or Delphi this may not be true. Java has very strong server-side capabilities. HTML and JSP provides declarative programming which is much more easy compared with desktop-based applications UI development. If true frameworks are used or developed, code generation is very easy. I think the only hard part is in client-side JavaScript which Ajaxian libraries are still trying to solve. Hardness of the JavaScript programming is caused by both the nature dynamic language and the distribution of client function into both client and server code.

Today, after years of heavy server-side only development and lack of understanding even JavaScript and Java difference, software world are awaked of client-side capabilities. In 2002, we were working our own JavaScript libraries and I had noticed that although many DHTML features added to JavaScript, there was mere usage in software world. Ajax is not a new JavaScript technique, we were using this technology with the name of Remote Scripting. Coming to 2004 and 2005, eventually Ajax had appeared as the cure of some problems. Today, web and desktop application gap is not yet filled. Some part of this problem is from the reason that JavaScript features are inefficiently or wrongly used (i.e. missing of server-side code support). Some part is caused by the nature of web platform.

Let’s try to list what was the rich functionality of desktop applications that we are still trying to fill:

1- Windowing System: Multiple document function is much more advanced in desktop applications compared with browser pages. Inter-document relation is very hard since some events may require navigation and this causes delay. Popup pages can’t be customized very easily; for example IE modal dialogs don’t allow you to navigate (we could achieve this with iframes). For filling this gap, many JavaScript libraries try to invent their own windowing system with layers, but most of them problematic (heavy or not easy to integrate with server-side).

2- Tab Component: Tab pages are micro edition of windows. Every tab page should be matched with a JSP page. But again JavaScript libraries were loading every tab content at one time. Partial loading of tabs may be recently utilized. We developed our own tab components which supports many sub-tab levels which were not existed in even most of advanced JavaScript libraries at the moment. We could implement that because of the help of server-side JSP pages. I think, currently available rich tabs are still can’t be easily integrated with your server-side page or object model.

3- Grid Component: We have searched a grid component many times but for many years web-based grids couldn’t reach to the desktop grid functionality. Only a few years ago, in-line editing etc. could be added to the feature list of web grids that DOM capabilities explored at last. We firstly developed a list component for the some functions of grid component (Sorting, Filtering, Selection, Paging). We could finally developed a grid component with has in-line editing with the help of Ajax. Our grid component supports many cell input types, insert row which eases data entry.

4- Master-Detail Forms: To provide this functionality, we must have grid functionality since Detail is formed with many input lines. After developing grid component, we easily supported this structure with detail tabs. One of the most important problems of this structure is mapping master-detail form into JSP pages. Current web-based master-detail solutions mostly don’t have detail tabs (One detail) or detail in-line editing and insert row causing to navigate another page for insertion.

5- Poor-Featured HTML Components: For many years, native form components are not improved. HTML 5 had many exciting components but should be earlier. Every JS library developed their own components to add features, but complexity and heaviness of those components still prevents us using them. I see many efforts; magical combo-boxes, super auto-completing text boxes, masked inputs etc. I think added feature value of these libraries doesn’t weigh its cost. We could only use partial codes like menus, tooltips etc. not the whole JS library. One of the big challenges for this is browser compatibility which still a burden of JavaScript coders.

6- Navigation: Page navigation causes UI interruption and users have to wait your page or component load. With the poor of server or network performance, users’ application satisfaction diminishes. Ajax libraries try to decrease page navigation, and this brings new problems. One of the major problems is that we have to synchronize server-side JSP page state with client-side state. Everything done in JSP pages should be done in JavaScript which causes us to keep track of 2 states. This is duplication of efforts and another burden on Web programmers.

7- Client Host Access: HTML doesn’t have this functionality. You can’t access client PC from Browser since security. The only feasible way to achieve this was using ActiveX components which are platform dependent and requires some security setting changes. Web site may not require this feature but as ERP web applications, we needed native printing or some manufacturing device access through the client host. Desktop applications are much more comfortable since have nearly no restrictions.

As the development and enhancement continues in Web world, we will see if this gap filled in the coming years. As a supporter of Web-based development, I think desktop applications will not be replaced completely with web applications. Both architectures had some powerful aspects and every software should be placed to the true platform considering software requirements. I give following link as a supporter of this idea: http://www.infoworld.com/article/06/10/02/40FEbrowseapp_1.html

Published at DZone with permission of its author, Ibrahim Levent. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mike P(Okidoky) replied on Wed, 2008/10/29 - 9:39am

I *thoroughly* disagree with point number 1.

I get involved with Swing based desktop application quite often, and I have experienced for the last number of years, that Swing has been snappy, responsive, and just as fast as native applications.

I think people arbitrarily condemn Java as slow or bad on the desktop just because it's the expected thing to say, which is expected to automatically get nods from other inexperienced (with Swing) people.

I've written reasonably complex gui applications and Swing was never the bottleneck. What has been the bottleneck for me is the way the client communicates with the server, for client-server applications. Your off the shelf hibernate type setup is not the most efficient method of feeding information to a gui. Better to keep a model with all the information on the server, and have a gui act as a remote viewer.

As for delivery/installation, webstart works almost perfect. There is a bug where occasionally it screws up its internal cache when a download is interrupted. Other than that it's been smooth sailing.

HTML components suck on Java. I've tried using Mozswing, which lets you embed the native Mozilla browser as a component in Swing, but it has bugs, and the development seems to be idle, which is pretty disappointing. It's also massive and heavy, and I can imagine how developers might get sick of working on it. I've tried a few Java based HTML renderers, but development seems to always stop half way, leaving a half functioning library that doesn't render pages off the web well at all.

I'm disappointed to see that most gui efforts are towards web 2.0 browser based solutions. It's know it's the most effective way to connect to the customer, but computers are capable of so much more than just shoehorning a bunch of javascript and html into a browser leaving a weby experience. I wish Webstart would be used more often, or with the new applet and applet installation and deployment features, which I haven't played with too much, applications embedded on a webpage as an applet, with the ability to tear it off and drop it onto the desktop. The latter sounds cool, but I'm crossing my fingers it's stable. I fear it's clunky, flaky, and crashes and stalls left and right. I'll have to find out...

Harald Krake replied on Wed, 2008/10/29 - 10:09am in response to: Mike P(Okidoky)

I 100% agree with Mike!

When it comes to desktop enterprise applications, the key to achieve good performance is to understand the way desktop apps deal with persistence and that this is fundamentally different from web applications. However, java desktop enterprise frameworks are ultra-rare.

Mike P(Okidoky) replied on Wed, 2008/10/29 - 10:48am in response to: Harald Krake

> java desktop enterprise frameworks are ultra-rare.

Framework? You just roll your own. Bunch of server/client data, and client side Swing based viewers. As for the original point, Swing isn't the problem at all. The framework is where the problem lies.

Jide makes a framework, not sure if that could be used for a client/server setup.

Harald Krake replied on Wed, 2008/10/29 - 11:45am in response to: Mike P(Okidoky)

[quote]Framework? You just roll your own.[/quote]

Guess what I did ;)

However, for a lot of projects this is not a valid option (lack of developer resources). As a result, most projects "misuse" existing Java-EE related frameworks and patterns which ends up in applications running like a pile of marsh mellows. Because web apps usually run fairly well with Java EE, the culprit must be Swing... :(

There are desktop frameworks, but most are closed source and so nobody takes any notice. Same holds true for Swing enterprise applications in general.


Ibrahim Levent replied on Wed, 2008/10/29 - 1:44pm in response to: Mike P(Okidoky)

Yes, Sun made many improvements in Swing components to make Java powerful in Desktop. My observation was based on my experience in 2001. In those years, this was a problem and to eliminate Swing's drawbacks for example IBM had developed SWT. Today, I think Swing should have been closed the gap between native applications since I heard many news about this (I did not use Swing for a long time). To use Swing or SWT or Web GUI depends on your project requirements and may differ.

Lieven Doclo replied on Thu, 2008/10/30 - 4:27am

I too completely agree with Mike. But that said, the lack of enterprise-ready Swing frameworks is just the thing we're trying to tackle with Spring Rich Client. We're currently adding a lot of stuff (which you won't see at the moment, it is sort of a surprise :)), hopefully attracting more enterprise users. Don't get me wrong, the framework currently is usable in the enterprise, and is being used by software companies at the moment.  But it could be better.

The problem currently lies in the fact that Swing GUI just aren't sexy at the moment. Every inch of attention goes towards web-oriented frameworks like IceFaces, Flex, GWT or some other 'next-gen' web 2.0 framework ... Swing GUI are perceived as too heavy, too clumsy. But then again, these sort of comment mostly come from people may not have even touched a Swing GUI in their life, let alone build one.

Jose Maria Arranz replied on Thu, 2008/10/30 - 5:21am

Ibrahim, your web based ERP seems developed using the classic page-navigation pattern (you use JSP heavily).

Web page navigation is not bad, in fact is the pattern used to build the web world at the time of writing, but it has some severe problems for web applications (back button, page caching, full reload etc). Page navigation has been very useful but it never will catch the desktop experience.

Alongside AJAX a “new” paradigm is surging, the One Single Web Page approach. In OSWP the application lives in the same page, there is no reload, when something must to change the new piece is taken from server. This approach is basically the same as in desktop, in desktop there is no “page navigation”, most of web applications live in the same window frame. As you know “modal windows” (windowing in general) can be simulated in web pages avoiding the problems of the “real” windows in the web environment.

This technique was not possible before but now we have web frameworks OSWP capable, for instance ItsNat, IceFaces, GWT (add yours here), with the exception of GWT they are server centric (GWT is client centric in spite of its Java nature). JavaScript libraries can be used to achieve this objective, but they need some support of the server because in a big application you need load new code when needed.

Server centric frameworks are more appropriated for OSWP in my opinion (I’m biased because I’m the author of ItsNat) with a OSWP-capable server centric framework only the markup and custom JavaScript code to manage this markup is sent to the client, the business logic remains in the server, changing big parts of the web page is business logic too. In a big application the page-based equivalent would be tons of web pages, in some way you can “simulate” page navigation changing big parts of the page, these parts or fragments are usually based on templates. In ItsNat these fragments templates are pure HTML code.

Other advantages are:

•    Big bandwidth saving (AJAX dixit)
•    More responsive UI (no more stupid full reloads for small changes)
•    Goodbye to back button, reload and page caching problems.
•    Goodbye sessions used to coordinate data between pages. In the OSWP approach the server keeps in some way the state of the client page.   
•    Desktop applications can be ported more easily to web because the paradigm is very very similar. For instance, in ItsNat Swing data and selection models are used for components.


Rajesh Sawant replied on Thu, 2008/10/30 - 10:38am

I too 100% agress with Mike and Harald Krake.

I feel biggest problem with Swing was that on one really understood how to program effectively with Swing,

If you have knowledge of Threads,Painting & EDT you can build amazing Swing Apps,that

can compete with any RIA Apps,I can bet on that.For RAD development lover I think

Netbeans Matisse , Swing Application Framework can help.What I like of swing is it is most flexible UI framework ,but whats makes it more complex.

So need is more wrapper frameworks, toolkits and demos of Swing are required,Sun should invest in these like Adobe does for Flex.


With Java update10 ,Java on client rocks !!!...

Omar Palomino S... replied on Thu, 2008/10/30 - 11:29am

For Ibrahim, Mike and Harald,

 I think this post gives a good vision of how was the situation about rich platform (desktop or web) and the current trends Web 2.0 is evolving.

But I think that it needs to be updated the section about Swing Clients, there is a lot of tools out there rigt now, and with Open Frameworks like Swing Labs, JGoodies and Open Swing (I still don't take a look at Spring RCP), that comes with a good set of RICH Components out-of-the-box, and gives you a fair integration with Netbeans Matisse, that, IMHO is the best thing could happen to Java on desktop.

I'm a former server-side developer that for project requirements had to be involved in desktop applications at the same time. So, my point is, there is not a true answer, just the best solution for a problem. And in a proposal you cannot dismiss web 2.0, desktop app, or a combination of both. (Like Open Swing team)

Today, I think I have the best of both worlds. I'm currently working in projects that use Web 2.0 or Swing as a Front-End, and Spring and Hibernate/JdbcTemplate as a Back-End. Always looking the right architecture for a given project.

 -- just my 2 cents, Omar

ps. Just for the record, Java6u10 is a must.

Harald Krake replied on Fri, 2008/10/31 - 10:12am

The funny thing with RIA applications is that they move towards single page applications (most prominent is GWT) and are now facing exactly the same problems as Swing applications did (and a lot still do).
For example, a really snappy application definitely needs some smart client-side object cache and a well performing solution for the lazy loading problem. With the browser part based on Java Script, however, you cannot pass Java objects between the server and the client or even hold some reference to remote objects. You always have to copy the objects' representations, which at least is technically "suboptimal".
With Java at the server- and the client-side (and the right framework, of course) things are a lot easier and I really hope that 6u10 will push client-side Java again, probably supported by Java-FX providing some more eye candy.

Andy Gibson replied on Fri, 2008/10/31 - 4:26pm

I'd actually disagree with point number 4. I realize that this is from 7 years ago and times have changed, but..

 You are looking at problems of web development from a client/front end scenario with tabs and tables. Coming from thick client/ Delphi software development background, my problem was relating to the statelessness of the web. For example,  to create a widget editing wizard, I would expect a solution to be able to provide (at least the illusion of) state without having to reload data each trip to the server and remember the values I had entered 2 wizard pages ago. There are all sorts of problems that crop up for state in a full blown web application such as handling multiple browser windows editing the same entity type without having same named values in the session overwritten or ending up with huge user sessions.

While it is possible to come up with some lightweight fixes for some of this stuff, I think needing a sturdy and scalable backend makes web development all the more difficult. Only now with Seam and Spring Web Flow are we seeing solid framework based solutions to these problems.

Comparatively, with Swing or a thick client alternative, I think it is easier to come up with a 'back end' given that a thick client can handle it's own business layer locally, or use a remote one, even using frameworks like Spring on the desktop to make it easier. State is held locally, I can just grab an entity, fiddle with it, edit it, and save it.It gives developers more time to focus on the user experience and putting the rich (even filthy rich) into the client.

In general, I find web application development feels like some big Rube Goldberg machine with all these distributed pieces where you can't really see the whole, and if just one small thing isn't in place the whole thing fails, usually with some giant stack trace but no comprehensive error message.


Jose Maria Arranz replied on Sat, 2008/11/01 - 6:29am in response to: Andy Gibson

@Andy Gibson: "I would expect a solution to be able to provide (at least the illusion of) state without having to reload data each trip to the server and remember the values I had entered 2 wizard pages ago. There are all sorts of problems that crop up for state in a full blown web application such as handling multiple browser windows editing the same entity type without having same named values in the session overwritten or ending up with huge user sessions."

With the one single web page approach all of these problems are gone, session object no longer is used to coordinate web pages and you can simulate modal windows in the same page to build a wizard.


James Selvakumar replied on Mon, 2008/11/03 - 1:19am

I too disagree regarding#1.

We develop a lot of swing based desktop applications and they work pretty good especially with jre 1.4 and above.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.