« EJB 3.0 draft and POJO's | Main | Lightweight RMI »
Rich clients are making a comeback
July 20, 2004
What happened to the Java Thick-Client? Long ago, in the early days of the web when we were all trying to figure out what applications would actually work on the web, people experimented with thick-client technology. Sure, there was HTML – but it was too simple. So people added Java Applets. But they never quite looked right, or worked seamlessly. Microsoft tried to launch ActiveX but people complained about safety and non-windows compatibility. DHTML behaved differently in various browsers. But Flash remained because it performed as advertised.
Thick-Clients fall out of favor. By the late 90's there was a backlash against thick-clients. “Thick clients are pretty, but they don’t deliver anything useful,” was the tagline. "In order to be useful the server-side code is what counts." So all of us Java folks designed browser-based applications with heavy-duty processing on the server but all the user got to see was HTML. We used things like CSS, server-side includes, and Tiles to make HTML UI’s look right and maintainable. Overwhelmingly, the buzz in Java land revolved around server-side technologies (read: J2EE) for the last 4 years.
It’s no surprise that the browser-based thick client options haven’t changed since people gave up on them. Correct me if I’m wrong, but the 4 options that were there in the late 90’s are still the only options: Applets, ActiveX, DHTML and Flash. I’m not counting JavaScript because it only serves as glue – the look of the site is still HTML.
But the thick-client still didn’t die. It couldn't because clients kept asking for it. Not explicitly, but users compare browser-limitations of web applications to desktop applications. Inevitably in a client meeting, someone pipes up “I don’t want to have to wait between screens.” So I would try to explain the whole concept in layman’s terms – the browser only has the form, the logic is far, far, away on the server.” “Well then let’s merge the 3 screens into one,” was the response. Great! Now we have to create more spaghetti on the server to deal with that one cluttered screen with three form submits.
Vanilla HTML UI's aren't enough anymore. User’s notice when you work around the browser's shortcomings seamlessly though. They don’t appreciate “just HTML” anymore. Sure, it was cool to check your bank balance online or order a coffee-machine over the web using a plain HTML UI – but that’s old and people take that sort of functionality for granted now. A simple case study is Oddpost which proves that you can build a company around a service that’s built almost completely around a thick-client application, and people will pay for it and then someone with deep pockets (Yahoo) will buy it!
For Java architects, the good news is that you can design thick-client applications using 3 out of the 4 options and still use Java on the server-side. Yes, Oddpost proves that you can have a DHTML-based front-end and a Java back-end. Java Web Start makes deploying regular Java applications easy with a Java back-end. But my favorite, Flash MX proves you can have it all! A slick, useable, browser-based front-end powered by server-side Java. The evidence is in the petstore demo implemented by Macromedia with a Flash front-end and Java-back end.
Read Followup: Choosing a UI Markup Language
July 20, 2004 at 06:27 PM in Opinions | Permalink
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834205eab53ef00d8353b9f2b69e2
Listed below are links to weblogs that reference Rich clients are making a comeback:
