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.
Jan 10, 2008 @ 10:37:01
>>What if you replace EJB invocations in Andy’s utopia and appcelerator messages in Appceleratorland with a REST based approach?
AppAcelerator does seem to support REST operations int the HTTP widget.
“The http widget provides a way to do HTTP POSTs and GETs to any URL that returns a well-formed XML or a JSON result. This is very useful for doing REST operations to a 3rd party website”
Jan 10, 2008 @ 10:46:10
Moreover, perhaps this is all new, but Localization is also supported:
http://doc.appcelerator.org/index.html#localization
Jan 11, 2008 @ 06:54:34
Thanks Bill.
I probably should expand this a bit in my own blog … but for now I’ll just comment inline:
– You do have to edit HTML. But at least that’s a known entity and better than proprietary MXML for Flex or other tools like that.
– We do support localization out-of-the-box and have since day one.
– We are concentrating on building more widgets and are increasing every day. With the 2.1 release in 2 weeks, we’ll have almost 20 of all types of UI, layout and advanced controls. With our new developer network which will launch in a few weeks, we’ll also open up widgets to outside and allow people to upload their own widgets and help others manage them and share them with others.
– While we do support an optimized remoting protocol based in AJAX and HTTP/JSON – we also now support REST as well (both in-domain and cross-domain) with our new app:http widget. In addition, the marshalling and transport layers are completely open and can be swapped out with other mechanisms (we’ve done this with another framework called Phococoa where we used form url-encoded POSTs instead of AJAX calls).
– URIs can also be bookmarked (we call this history tracking and it’s available now) and we’re working to make this easier and more robust.
– With 2.1 we’ll introduce a new just-in-time compiler which also compiling on the fly in the server environment the appcelerator-enabled HTML which will compile down to the DHTML/Javascript which is completely HTML 4.0 valid (assuming the author does make their HTML + appcelerator code valid).
– We have a new Eclipse-based RIA developer product which will be released in the next release in a couple weeks which will introduce code assist, project creation, update management, syntax highlighting and just-in-time code/web preview.
– Appcelerator can be used unobtrusively following the Unobtrusive Javascript (UJS) pattern. For example, with 2.1 you can do $(‘mydiv’).on(‘click then effect[highlight]’) and place that JS code in a standalone javascript file
Beyond 2.1, we’ll start to introduce other services on top of Java — such as Groovy, Grails, JRuby, etc. so that you can use the power of the JVM but the simplicity/productivity of scripting languages to build your services.
Our community is growing fast and we welcome collaboration with other open source projects and developers. Our goal is to be the RIA-enabler for the next generation SOA-based web.