In the old days, when I started my career, the serious work was done on dumb terminals. The where nothing more than a display with a keyboard, connected to a mainframe or mini-computer. The displays where character-based (mostly green or amber colored), no graphics, no mouse. At that time, the PC gained momentum, and also Microsoft Windows became usable. WordPerfect (now Corel) came with a graphical version, Microsoft released Word.
Work shifted from the terminals to the PC. In the transition phase, a lot of people would have a terminal and a PC on their desk, but the terminal disappeared fast: terminal emulators took over. Not long after that, the client-server architecture was born. No need to starting a terminal-emulator anymore, just start the client-server program to enter your data. Because they ran on Windows, the C/S applications had a much richer user-interface and one could use a mouse to point-and-click.
PC’s and C/S applications soon became the nightmare of most system-managers. The so-called DLL-hell. Newer programs required newer libraries, but not all older programs would work with the newer, or the other way around. And every supplier used it’s own network-protocol/port it thought suited best.
C/S applications are still widespread, and they will be around for some time to come. But with the more recent evolvement the web technology has been through, application developers are pumping out web-applications. Advanced webpages that allow you to do your work via a webbrowser, like FireFox or Internet Explorer. Why? No DLL-hell, since you only need a webbrowser. And simpler roll-out of new versions, since you only need to update the application on the webserver (application server) instead of every PC that needs it.
But the HTML language has very little support for tasks like entering data. The webapplications don’t have the rich user interface we were used to with traditional C/S applications. And there’s another thing: the web is stateless/connectionless, whereas C/S has a dedicated statefull connection to its data.
In the last couple of years, this shortcoming of webapplications has been solved. Webapplications can maintain state, and several webframeworks give you an interface as rich as traditional C/S. At the moment there are a lot (A LOT!) of webframeworks. Some very good, others very small and task-specific. But they all work from your browser, once the developer created and application with it and deployed it on an application server.
Unfortunately, application servers don’t all work the same. So a webapplication developed for one, might not work on a second. If we only count the big names, there are about 8 of them. And there are lot more if you count the little ones as well. Multiply that by the number of webbrowsers. We have 4 important ones. That’s 32 combinations. Developing an application that works on all of them is no simpel task. So webapplications mostly work on one or two ASes and if you’re lucky with all webbrowsers.
Why is it that we massively embrace the webapplication hype? Do we really like the webinterface? Or do the developers and the systemmanagers tell us they are easier to use?
Wouldn’t it be nice if we had some sort of old-fashioned C/S tool that used port 80 and that would be suitable for not only one task but for several. I don’t mean a webbrowser, since it only renders HTML pages. I mean a real application that understands buttons and dropdownlists and stuff, but that communicates to a server or application serer with a standard protocol. Like say, over port 80 in HTML. That would mean a general client for Windows, Linux, Mac and Solaris. It would download the application info in XML format (like a web.xml) and with that it could render the application. Client side.
But what GUI toolkit would be the toolkit of choice? There are so many toolkits. Or a client with several toolkits in one, so the user can choose? Like an advanced form of skinning? And what components should the toolkit support? Would a standard grid ala Excel suffice, or do we need one that supports coloring, sorting and grouping-by-dragging?
I’m not sure where we are heading (or for that matter: where this post is heading), but as a developer, I live in an interesting era.
Better late than never, just noticed this post. Just wanted to propose to keep an eye on Adobe Flex 2 (http://labs.adobe.com) and the currently in-works Apollo (http://news.com.com/Flash+to+jump+beyond+the+browser/2100-1007_3-6071005.html). It’s C/S, port 80 (and additional if you’d like to support push), cross platform, great backend integration, very customizable, large set of UI components and extensible framework. Anyway, not willing to spam any longer, go check it out, you can build really cool RIAs for free (the framework and compiler are free)! Let me know what you think?
Flex 2 is propietary. Furthermore, Flex 2 requires a client-side install. Every time Adobe/Macromedia decides to upgrade the Flex 2 player, just like we see with Flash and Shockwave. Basically that means you cannot deliver applications without asking for certain requirements. Ajax (for instance) does not require client-side installs. That’s better.