Skip to main content

Decoupling client-side JavaScript components from server-side web frameworks

Posted by johnreynolds on August 25, 2005 at 7:27 AM PDT

Michael Meehan's recent article,"Can Ajax be running partner of Web services?" got me thinking about what wonderful tools JavaScript and DHTML are.

I had dabbled with JavaScript years ago, but the pain of dealing with IE, and particularly Netscape 4, left a bad taste in my mouth. I settled for pretty dull web interfaces, using only minimal DHTML and avoiding "fancy client-side stuff" like the plague. Most of my presentation layer logic was server-based, using frameworks like Struts to handle dynamic content and validation logic.

Web component frameworks like Echo, Tapestry and JSF added spice back to life. Wonderful people took all that nasty JavaScript and packaged it up in nice little bundles that I never had to deal with. I could now add snazzy menues, tree controls, and sortable tables to my web-apps without having to stray far from my comfortable and safe Java knowledge base.

Life was definitely better, but I had a nagging suspicion that I was living a lie. JavaScript is the native tongue of browsers, and I was crippling myself by speaking only Java and XML. This suspicion was verified when I started trying to port components between web component frameworks. Let's face it, the "sexy" behavior of any Tapestry or JSF component is written in JavaScript... the server-side Java that processes the requests is pretty mundane. If you can't reuse the Java, no big loss. If you can't reuse the JavaScript, you're starting over from scratch.

My journeys between Tapestry and JSF may have been enough to rekindle interest in JavaScript, but what really got me hooked again was AJAX. Many blogger have pointed out that AJAX is nothing new, but something surely changed. Sexy web-apps that once required applets or Flash are popping up all over.

Take a look at the demo for Novell's Hula project. That's a truly sexy user interface, and it's implemented as JavaScript over Web Services.
This is a pure client/server (or should I say client/services) architecture: JavaScript client and Mono services.

The folks who are writing these sexy apps know JavaScript/DHTML and leverage it to the max, but what really interests me about this architecture is the decoupling of the JavaScript from the server-side code. The Hula client runs on Web Services that happen to be implemented using Mono, but you could change the implementation to Java and the client wouldn't care.

Contrast the clean separation of Client and Service from approaches like JSF and Tapestry. With Tapestry/JSF, an HTML author designs the layout, and a Java author implements the user interface logic. With the Client/Service approach, a DHTML/Javascript author writes the user interface, and a Java/Mono author writes the services.

With the JSF/Tapestry approach, there's a tremedous temptation to tightly couple the services to the user interface... ending up with a great application, but not with reusable services.

With the Javascript Client/Java (or Mono, or PHP, etc) Service approach, it's much more likely that your services team will develop reusable services, and you'll probably end up with several tailored user interfaces.

I don't think that Tapestry or JSF are "doomed", but I do think we're going to see much more interest in DHTML centric client frameworks. The clever person who develops a server-side framework that appeals to JavaScript programmers is probably going to be very popular.

The bad news is that the IDEs for JavaScript just aren't very good yet, but there is a lot of activity going on. With better tools, better Javascript SOAP support and JavaScript embedded in Java 6, we might even start seeing more server-side JavaScript servicing those rich JavaScript clients... a pure JavaScript web application stack.

I'm not about to abandon Java, but I am going to learn more JavaScript...
When in Rome, it really does help to speak Italian.