Ajax: Back to square one

[R K Singh]

Just read few paras of Ajax tutorial and I think we are back to square one when it comes to separate client and server programming.

I got chance to work on cgi-perl (did some modification in Bugzilla code base.), worked on servlets when JSP was at 0.7 version(if I recollect correctly), then came J2EE with MVC and brought clear separation in all layers(with use of lot of design patterns).

Now with Ajax, I think we are going to do lot of server side things in JS.

I may be wrong but this is my first thoughts about Ajax.

[Gabriel Claramunt]

Why do you think that? With AJAX you just provide a more interactive and richer user experience. All the business logic is still executed in the server. (At least is how I use it in my projects)

[Bear Bibeault]

You either read a poor tutorial, or you misconstrued it badly.

Originally posted by R K Singh:
Now with Ajax, I think we are going to do lot of server side things in JS.

Absolutely not! That would be folly. As Gabriel wisely pointed out, Ajax helps us to give the user a richer experience, but all the lessons we learned about layering applications properly still apply. The way that we write responses may change (or more accurately, be augmented), but all the "rules" about how to construct proper web applications still apply

I may be wrong but this is my first thoughts about Ajax.

I think you have not had an accurate first impression.

[R K Singh]

You all are right, let me complete first my tutorial. I should have commented after reading completely.

AW thanks a lot for your input.

And sorry for posting in wrong forum (actually I wanted it to be general discussion, but I think it is technical.)

[Frank Silbermann]

Originally posted by R K Singh:
Just read few paras of Ajax tutorial and I think we are back to square one when it comes to separate client and server programming.

I got chance to work on cgi-perl (did some modification in Bugzilla code base.), worked on servlets when JSP was at 0.7 version(if I recollect correctly), then came J2EE with MVC and brought clear separation in all layers(with use of lot of design patterns).

Now with Ajax, I think we are going to do lot of server side things in JS.

I may be wrong but this is my first thoughts about Ajax.

The client code executes in a different place so it actually takes some work not to keep that separate client code from the server code.

I think you're confusing client programming with View programming (in the context of Model-View-Controller). And yes, AJAX does get in the way of separating the view from the controller. (In the classic MVC-style J2EE programming, you use POJOS, EJBs and databases for the model, servlets and XML for the controller, and JSP/JSTL/HTML/CSS for the view. It is MVC at a very coarse-grained page level.

With AJAX, you use JSP/JSTL/HTML/CSS/Javascript for both the view and the controller all intertwined like spaghetti.

Just as the Hibernate folks were dissatisfied with the clumsiness of the EJB API, a few people have already been looking for alternatives to the clumsiness of classic coarse-grained MVC-style J2EE web programming (even to the point of going to other languages such as Ruby, Perl, or PHP). For many people, the demands of AJAX is the final straw. "Why can't the same object-oriented language that we use to program the model be used to code the view and the controller?" they ask. One of these days that whole mountain of complexity is bound to be replaced by one or more of the following revolutions:

(1) Java Webstart and Applets. Just like the code running on the server, the code running on the client is Java. You can employ any Java design pattern you please in separating model, view and controller from one another.

(2) GWT. Just like the code running on the server, the code running on the client was originally written in Java. However, unlike Webstart and Applets, the Java-language client code is compiled into Javascript/HTML/CSS. The look-and-feel is limited to that which you can code via the provided Java-language GWT APIs, including AWT-style layout managers. However, refactoring and re-using display code remains feasible. (GWT differs from Applets primarily in terms of the technology used on the client side -- javascript, HTML, CSS and DOM versus the Java Runtime byte-code interpreter.)

(3) Echo. As with the model code, the view and control functionality also executing on the server are also written in Java. However, the Echo components running on the server are compiled into HTML/CSS/servlets for rendering on the client. Echo2, which is AJAX-ified Echo, has components which are compiled into Javascript as well as HTML/CSS to move some component behavior and interactions to the client. As with GWT, the look-and-feel is limited to that which you can code via the Java-language Echo APIs, including AWT-style layout managers. However, refactoring and re-using display code remains feasible. (Echo differs from GWT primarily as to where the bulk of the view code executes.)

(4) Wicket. As with the model code, the view and control code running on the server is written in Java. As with Echo, components automatically generate HTML/CSS for rendering on the client. As with Echo2, AJAX-ified Wicket components generate also Javascript to move component behavior an interactions to the client. However -- unlike Webstart, Echo2 and GWT -- the look-and-feel and layout of the components is done via separate hand-coded HTML/CSS files (one file associated with each page or panel class), rather than using AWT-style layout managers. These files contain no special tags, so they can be produced by designers using any HTML technology they please. You have more power and flexibility to integrate with other web technlogies, but you have to know HTML and CSS.

JSF tries to do what Wicket does, while supporting drag-and-drop GUI-builders and configuration of components via property-sheets in the IDE. This is great if you have a collection of pre-built components that provide exactly the functionality you need. Unfortunately, no one is going to provide you with precisely the application-oriented components that you need, and you're not going to make them yourself because the creation or modification of a typical JSF component is extremely error-prone and laborious. Therefore refactoring your views or re-using work is going to be extremely difficult (a real handicap in an agile environment). Even getting a set of powerful general-purpose components similar to those in ASP.NET is unlikely because of the market's fragmentation (lacking a single, dictatorial proprietary vendor to provide the components and profit by them). Your HTML will have to be coded via either a JSF tool or no tool at all.

If you're willing to hand-code our GUIs (or, in the case of Wicket, hand-code the Java-side of your GUIs while using any generic WYSIWYG HTML editor for the associated HTML/CSS files), then one of the four approaches mentioned earlier nicely solves the problem. You can easily build your own special-purpose application-oriented web components simply by subclassing or composing existing Java classes into new Java classes; therefore, you can easily refactor your displays and re-use aspects of them, and you can apply agile methodologies to view development.

In my opinion, the two best approaches are Webstart/Applets (for when it is sufficiently easy to convince users to download the needed Java runtime and application jars), and Wicket otherwise (for unlimited control over the look-and-feel, and ability to integrate with other HTML/HTTP based web technologies).
[ September 22, 2008: Message edited by: Frank Silbermann ]

[Bear Bibeault]

Traditional web programming is a "mess of spaghetti" only if you write it that way. Regardless of the technologies used, programming can be well-structured or not. Yeah, it's a bit more work to learn how to use the web technologies together in concert, but the results are generally better than the one-language solutions. At least at this stage.

While a "whole Java" solution may be appealing to some developers (I'm not one of them), but what they produce is more important. Applets failed for a number of reasons that Sun hasn't yet seem to have overcome. Swing UIs are generally pretty horrible. It doesn't mean they can't be good -- I've seen a lot of great ones; they're just in the minority. (Of course, there's no dearth of bad web UI's either, but that's not the point.)

Tools like GWT have their place, but the UIs that they generate are usually less than pleasing. And there's major limitations placed on the UI by what the tool supports. Not too mention the problems caused by the translation layer. Developers are simply trading one set of problems for another.

You pick the tool that works best for you and the product that you are trying to create. I've tried them all, and for me, the traditional stack of web technologies works best.

[Frank Silbermann]

Originally posted by Bear Bibeault:
Traditional web programming is a "mess of spaghetti" only if you write it that way. Regardless of the technologies used, programming can be well-structured or not.

Yes, you can develop programming practices that result in well-structured code with almost any approach (but you have to be _especially_ disciplined using the traditional approaches when AJAX is added to the stack). The advantage of the approaches I mentioned is that you can use object orientation when coding the view and the controller, thereby facilitating abstraction, re-use, and the easy ability to refactor (which, among other things, gives you more options for separating concerns).

Yeah, it's a bit more work to learn how to use the web technologies together in concert, but the results are generally better than the one-language solutions. At least at this stage.

... Applets failed for a number of reasons that Sun hasn't yet seem to have overcome. Swing UIs are generally pretty horrible. ...

Tools like GWT have their place, but the UIs that they generate are usually less than pleasing. And there's major limitations placed on the UI by what the tool supports.

Your comments are basically the reason so many developers prefer Wicket over the other, purer (i.e. single language) approaches I mentioned. Wicket allows users the full expressive power of HTML/CSS when designing their GUIs. (You can even insert your own Javascript, though I'm told the pre-written AJAXified components usually make this unnecessary.)

Not too mention the problems caused by the translation layer. Developers are simply trading one set of problems for another.

The translation layer may be a big cause of problems in Echo and GWT -- I don't know; I don't have much experience with them. For Wicket, translation is no more an issue than in JSF or ASP.NET. (Maybe there's a bit less of a translation issue because you are writing Java rather than having a tool generate it.)

You pick the tool that works best for you and the product that you are trying to create. I've tried them all, and for me, the traditional stack of web technologies works best.

What is your experience with Wicket? Until recently it was inconvenient to learn due to the lack of professional-quality documentation. But a good Manning book on it just came out.

The biggest weakness of Wicket is that it's easy to end up with too much session-state for a website with a massive number of concurrent users. I'm told that sophisticated users can get around this problem in the latest version, however.

[Bear Bibeault]

Actually, Wicket is the only technology mentioned that I haven't explored in depth. It sounds interesting, but it's a bit off-topic for this post and forum. Perhaps you could start a topic in the App Frameworks forum to discuss this?

[Matthew Quinlan]

Originally posted by R K Singh:
Just read few paras of Ajax tutorial and I think we are back to square one when it comes to separate client and server programming.

Client-Server 2.0 ....coming soon to a browser near you
[ September 23, 2008: Message edited by: Matthew Quinlan ]

[Frank Silbermann]

Originally posted by Bear Bibeault:
Actually, Wicket is the only technology mentioned that I haven't explored in depth. It sounds interesting, but it's a bit off-topic for this post and forum. Perhaps you could start a topic in the App Frameworks forum to discuss this?

I don't have time at the moment to start a new topic, but here are a few nice links to intros and already existing discussions:

http://www.javaworld.com/javaworld/jw-06-2008/jw-06-wicket1.html

http://www.oreillynet.com/onjava/blog/2007/01/wicket_another_java_web_framew.html

http://olemortenamundsen.wordpress.com/2007/08/31/wicket-%E2%80%93-tired-of-spring-mvcwebflow-jsp-or-jsf/

http://ptrthomas.wordpress.com/2008/09/04/wicket-and-gwt-compared-with-code/

http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/

http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/

http://www.javalobby.org/java/forums/t60786.html

http://www.manning.com/dashorst/