Change in all things is sweet. -- Aristotle
You work for company A whose bread and butter is a desktop GUI application that it provides to it's customers for a monthly fee and via something like the Citrix Presentation Server. Life is good, but it's time for work to start on the next version and a manager drops the word "Ajax" in a meeting.
You get nervous. Ajax means web and from what you've heard from your buddies in marketing who help to run the web site, web development is different and hard. You've got a browser, three or four different languages, threads, cats and dogs living together. You start to update your resume. But where does a desktop developer go when all the world is going web?
You call up a friend at company B. Company B also has a desktop GUI application that it provides to it's customers for a monthly fee via something like the Citrix Presentation Server. You meet for lunch ("Uh, when you say "next door", do you mean Chili's or Flingers?") and start to cry in your beer.
"Dude," says your friend, "we're moving to Ajax too, and it's way cool and easy."
You fall out of your chair.
Now take a deep breath and realize that...
Your Desktop GUI Skills are More Valuable than Ever
I've written reams of posts on why component GUI development is better than the typical web development approach (Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks is probably the most cerebral), but the guys over at the ZK framework put it better than I can:
In 1994, we developed an infrastructure, inspired by zApp and OWL, for developing an accounting system for Windows. In 2000, we developed another infrastructure, inspired by Struct and WebWorks, for developing another accounting system for J2EE. After coaching and watching the development of both systems, we found that not only the Web edition required much higher programming skills and prerequisites, but also its total cost is four times more than the client/server one. Worse of all, the user experiences reminded us the age of green terminals, though the look, after decorating with proper images and CSS, is modern and fresh.
Four times as expensive seems a touch high to me, but I've seen worse. Certainly twice as expensive wouldn't be a stretch. Now we've come a long way since I wrote my first CGI script back in 1993 (I think I used /bin/sh), but the difficulties of juggling browser and server contexts and languages in your head at the same time has gotten worse, not better. There's just a lot more technology of which to keep track.
Face it, developing code using the event driven component GUI model is just more efficient and, yes, pleasant. And that's great for you because that is the skill set you already have.
Refreshed from your lunch (the calamari was excellent) and armed with your friend's helpful suggestions, you run back to the office and scan your calendar for the next product planning meeting. There's one that afternoon. You bring a new yellow legal pad, a sharp pencil and an eager expression. When the manager opens up the floor to suggestions, you're hand shoots up and you yelp, "Echo Two!"
"Echo what?" says the manager.
"Echo2," you say, catching your breath. "It's a component GUI framework for writing Ajax applications. We would write the new application pretty much like we write the current application, except that the result would be an Ajax application and run on the web. And we wouldn't have to fire anybody and hire all new expensive programmers."
Your manager looks impressed. The other developers shoot you envious glances, especially the guy with the copy of Real-World Ajax tucked under his arm.
So, crisis averted, right? The new version is coming along and it's all milk and honey while you write the same type of code as before, right? Well, not quite. There are still some differences between your prized desktop app and the web app you will soon come to love. But never fear. You are about to be enlightened as to
Things You Should Keep In Mind When Moving from the Desktop to the Webtop
This list could be endless, but let me focus on those things that I've found to be particularly salient in desktop to webtop projects.
- Is your old application concurrent (possibly having two or more actors -- users, threads, systems -- operating on the same data), i.e. is it client/server or is it stand alone?
- Are you going to want any specialized or custom components for your application? Does your old application make use of lots of third-party components and widgets?
- Bandwidth: even a LAN tends to be slower than your computer's data bus.
- The component GUI model is so nice, but what if something blows up on the browser? Help!
I could go on, but these are the biggies. Let's take on these issues one by one.
Concurrency
The easiest thing to do with your application in terms of concurrency is to leave it alone. If it was a single user, one-thing-at-a-time type of application, let it be that kind of web application. If it was a client/server app that already handles concurrency, reuse your data model, your business and persistence logic as much as you can.
The hard part comes when you want to make the transition from a non-concurrent to concurrent app. If you've got a data model that looks pretty standard, i.e. related entities represented as one or more tables in an RDBMS, you can use tried and true design techniques (see ORM, Spring, Hibernate, optimistic locking, pessimistic locking, etc.) to transition your app. If, on the other hand, your app deals with a complex document, something that looks more like a tree, an acyclic directed graph or even a cyclic directed graph (think word processing doc, UML diagram, etc.), then you've got trouble.
You would like to be able to provide atomic transactions on these hierarchical structures, something which is still an active area of research. There's also the issue of document validation, i.e. is it still valid to add a footnote to a document if the paragraph it was attached to has been removed. Finally, there is the problem of presenting all of this complex hierarchical collaboration data to the user in a way they can make sense of. The truth is that collaboration with complex documents or information structures is something with which everyone struggles. No one has gotten it right as yet.
If you must introduce concurrent features under these circumstances, go with add-ons instead: shared bookmarks, a comment system, a shared whiteboard or clipboard. Or try coarse-grained locking of document sections.
Specialized Components
Just as with traditional component GUI frameworks, with Echo2 you can compose new, more complex components out of existing components. Three drop down lists can become a date picker, for example. But sometimes what you need is just not in the toolbox.
In the case of Swing or AWT you would dust off the low level pixel painting API and have at it. In the case of Echo2 you're going to have to dust off something you don't already have: a knowledge of Javascript, CSS and XHTML (and HTTP). You didn't think you would be able to get away from that stuff entirely, did you? The good news is that you will only need a few of these highly skilled Java/Javascript/CSS/XHTML widget designers and, once they've developed their excellent reusable widget, it'll be at least another day before another requirement forces them back to the keyboard.
Bandwidth
Your desktop GUI was pushing things to the screen; your Ajax webapp will be pushing things to a browser. Besides network connectivity being slower than intra computer connectivity, the two operations are fundamentally different. Take for example the case of a list of 5000 emails that are displayed in a scrolling table. At any one time, perhaps only a dozen emails will be displayed at once. In the case of the desktop GUI, only a small area of pixels need to be updated as you scroll through the list. In the case of an Ajax application, you will need to send the data for those 5000 messages to the browser, either all at once or incrementally as they scroll into view. This data is then inserted into the document object model (DOM) of the web page. This can be an expensive operation and if not carefully thought through can make certain operations awkward or impossible.
Take for example the Yahoo! Mail Ajax GUI. It incrementally loads emails as you scroll through the list. It's slow. And if you want to delete all of the emails in the list, you have to painstakingly scroll through all of the emails so that they load. Otherwise you can't select the whole list and delete them. That's behavior very different from that of a desktop app.
When Things Go Wrong
Things do occasionally go wrong in Echo2/Ajax land, and when they do they can be very hard to diagnose. The nice fiction of a Java-only development environment breaks down and you have to trace through your Java, the client-side Javascript engine and your components, the DOM of the application page, the CSS, etc. When this happens, bring one of those widget developers to the party. You'll use your IDE's debugger, tools like Firebug and Venkman, and the built in message debugging support in Echo2, all to track down and eliminate your bugs.
All I can say is welcome to the world of web development. This is what we go through all the time with or without Echo2.
Conclusion
We've looked at one way of developing Ajax applications with Echo2 that will let you reuse most of your desktop GUI development skills. Echo2 may not be your cup of tea. There are other server-side frameworks, such as ZK, and there are client-side frameworks like GWT and Tibco GI that have things to recommend them for the component GUI developer.
Also, I haven't even touched on the .NET side of the house. That will be the subject of a separate post.
Last, it would have been impractical to touch on all the differences between Ajax and desktop apps. For some ideas, have a look at Michael Mahemoff's excellent Ajax Patterns wiki or, better yet, buy his book.
Technorati : ajax, desktop apps, echo2
