I spent almost a whole night discussing, whether AJAX is the right technology for simulating Swing or SWT clients or not.
There were several speakers involved and we had completely different opinions about AJAX. Also some comments from my
last entry "The day after AJAX" confused me a little. The problem in both cases was: it seems like there are different architecture styles philosophies in the AJAX-world:
- Using asynchronous communication and partial updates to make existing webapplications more usable. In this strategy the applications are still looking like webapplications and browser works like expected. Such applications are still thin - (TAJAX? :-))
- The second strategy is more radical. In this case, developers trying to use browser as a platform for the delivery of rich, or even fat clients. In this case own widget toolkits layout managers etc. are often used. Frameworks like dojo provide even a whole event mechanism framework, clientside storage is also often used. Such Fat-AJAX applications (FAJAX? :-)) behave more like a native application and have nothing in common with an usual website.
I my opinion TAJAX is absolutely valid, useful, still maintainable and provides added value. I didn't mentioned this strategy in my past entries ("The day after AJAX" and "The beginning of WEB 3.0 with Java Fat Clients").
In other cases (e.g. intranet) Swing with JNLP or SWT with eclipse's update manager are still easier to develop maintain and are also more powerful. Sometime is an Old Plain Swing Application (OPSA? :-) ) even cooler than AJAX: checkout aerith or LookingGlass.
So always ask the question "Why?" in case there is no reasonable answer (from the customer perspective, from the development perspective it is always one -> coolness) - you are going to practice the "The VooDoo consulting style".
airhacks.fm the podcast:
Stay in touch: airhacks.news.