I agree with new JBossian, Andy Rubinger. Plumbing sucks. Andy talks about how he hates Struts, et al. and wished he could rip it out for a more lightweight model where the client is Ajax/JavaScript talking directly to EJBs on the server side. Andy is a young guy (still in his 20’s I believe) so he possibly missed all the 3-tiered application development done in the mid-90’s with VB, VC++, and Power Builder. Personally, I miss those days because GUI development was fun and productive.

If Andy likes this idea so much, he should take a look at what Jeff, Nolan, and Ben are doing at Appcelerator. The Appcelerator approach is interesting in that it is very much like Andy wants. They turn HTML/Ajaxey based applications into an event/message based model. What I think is interesting about their approach is:

  • You can mock-up your server interactions directly within your web pages. This allows the client app developers to create a working application that doesn’t require a server to run and that can be developed independently of server side business logic
  • Your server can become stateless. Since AJAX applications can hold state, this means no more HTTP Session replication on the server side and that the server needs less memory.
  • Client architecture is decoupled from the server side architecture (but not completely, I’ll explain later). With JSF, Seam, Spring, or (insert your favorite Java webflow framework here), you’re basically married to Java. This means no experimenting with Ruby, Groovy, Rails, Grails (why you’d want to, I don’t really know 😉 but hey, you have the option). Appcelerator works with Java, Ruby, Python, and even .Net.
  • Things like validation are done on the client by marking up the validation logic directly on HTML elements. Other AJAX frameworks do validation on the server by sending tons of mini messages back and forth. What a silly idea guys. You wonder why you have to do unnecessary rearchitectures like Jetty’s continuations. Anybody who has ever written a distributed application realizes that to scale you must minimize message passing.
  • You don’t write much Javascript. You embed event modeling directly with HTML attributes.

There’s a billion AJAX frameworks out there. I couldn’t find any out there that had all these attributes. (If you know of one, I’d be happy to add and edit this blog). What I didn’t like about their project was:

  • You still have to edit HTML. Not sure how well app-dev lifecycle would work if you used a professional designer app with Appcelerator.
  • I’m not sure how they would handle localization/internationalization.
  • Their widget set is still relatively small
  • Appcelerator’s distributed messaging architecture is Appcelerator specific. Yeah, it works on Ruby, Java, et al. but you still have a coupling between your client and server architectures via Appcelerator’s messaging layer. Which brings me to my next point…

What if you replace EJB invocations in Andy’s utopia and appcelerator messages in Appceleratorland with a REST based approach? Bill Higgins wrote a great article about AJAX + REST awhile back. If this approach goes mainstream, we’re just turning the clocks back to a 3-tiered architecture. I dont’ think that’s a bad thing though!

There is at least one drawback I can thinking of. Hyperlinks. Hyperlinks are just so important in integration and propagation of information. In a pure AJAX+REST approach, you give up on hyperlinking and your app behaves really like a traditional Swing/VB/PB app.  Another thing is that sometimes it does make a lot of sense for the server to render content.  In these situations I still believe we can keep the server stateless and combine it somehow with teh AJAX+REST approach.  Whoever can pick out the valuable pieces of Struts-like apps and combine it with the AJAX+REST approach will truly have something compelling.