John Reynolds's Blog

August 2005 Archives

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

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.

Is Simon Phipps' mailbox full?

That's an amazing statement... it seems that Open Source is also inspiring Open Mailboxes. Kudus to Simon and Sun.

Straining the bath water (in search of lost babies)

Romain Guy's blog "Get to love web development" chronicles his growing love for the Wicket web component framework... and I must admit that I am very tempted to take the plunge... but my first reaction was to ask the obvious questions: Why another Java web component framework? Why not evolve (fix) one of the existing web component frameworks?

Tapestry's Howard Lewis Ship had a slightly different reaction:

"Wicket is looking to me like a mix of Tapestry and JSF. I've been giving a lot of thought to what a much better web framework would look like. Tapestry has the templates right (and everyone's been copying that) but internally, the component approach is too limited. I'm envisioning something closer to an AOP approach and may find time to work on a prototype someday."

Kudus to Howard for admitting that Tapestry isn't perfect... and for reminding all of us that "a much better web framework" is still a real possibility.

My cautionary note is that most innovations in web component frameworks seem to be throwing the baby out with the bathwater.

I'll explain what I think "the baby" is, but let me hasten to add that I don't want to single-out Wicket... the sounds of sloshing bath water are all around us.

One of the loudest noises is coming from the direction of Ruby on Rails. Everyone from Matt Raible to David Geary is lauding the power of Ruby on Rails.

Ruby on Rails sounds great... but they're not just throwing out the baby, they are throwing away the tub. Do we really have to flush Java down the drain to make web development "fun again"? (The folks on the Grails and Trails projects seem to be enjoying themselves.)

But I digress... What I really want to talk about is web components.

It's the Web Components (stupid)!

In the domain of Java web component frameworks, user innovation has resulted in (at least):

• Echo
• Tapestry
• JSF
• Wicket

Unfortunately the innovators also threw out whole libraries of pre-existing web components. You can't use an Echo component in a Tapestry application. You can't use a Tapestry component in a JSF application. You can't use a JSF component in a Wicket application.

To be fair... with the exception of JSF, none of the web component frameworks set out to define standards for the web components themselves, and in many cases these frameworks were developed during overlapping time frames.

Innovation is a great thing, but the continuing innovation in Java web component frameworks is somewhat stifling innovation in Java web components (and in tool support for component based programming).

Consider AJAX as an example: Google and a new acronym made AJAX sexy this year, and now every web component framework that I am familiar with is scrambling to support its features.

The problem (for web component innovation) is that proponents of each framework are building "the same" AJAXian components. We're seeing some innovation, but mostly we're seeing a lot of duplication (tables, trees, etc.). Worse (from my perspective) we aren't seeing significant tool support for developing JavaXIAN^TM web components (components with client-side JavaScript and server-side Java).

Fortunately, there are great plans and repositories for client-side AJAXian JavaScript, and no doubt many JSF, Tapestry and Wicket components are (unknowingly) sharing the same client-side JavaScript. It's the duplication of the server-side code that's a waste. As Michael Jouravlev points out in his article Building Web Components Without a Component Framework, components have a pretty clear set of responsibilities that are distinct from the application framework in which they are embedded.

It’s wonderful that we live in a world where Wickets and Rubies get a chance to compete... but at some point we need to cast a few things in stone in order to move on and innovate in other areas. Agreeing to support "standard" web components would constrain framework authors, but it would empower a whole new group of innovators.

Kudus to Wicket's creators for creating a loveable framework (I trust Romain's instincts on this one), but you will really win my praise if you figure out how to utilize JSF components. It's not too late to rescue a few babies ;-)

Longing for an Integrated Maintenance Environment

We are blessed with many great IDE choices for developing our code... and now we're beginning to see glimpses environments that will help us maintain deployed applications

When the dot.com boom went bust, I was fortunate enough to land a job as an enterprise architect in the development and production support group of a mid-sized corporation. After a career in R&D, I found myself in a more typical IT environment where keeping things running was way more important than implementing new features.

This change in perspective from R&D to IT was a very good thing for me. After years of delivering solutions to customers and moving on to the next challenge, I was now the producer, consumer and supporter of my own team's creations. I now had to "eat my own dog food" in a production environment (24x7x365).

When you really have to live with (and support) your own products, your perspective on what is important changes.

For the most part, business applications are conceptually simple. You present a form to a user, validate the responses, and process the request. It's hard to conceive what could go wrong after deploying such Simple Business Applications^TM, but inevitably Murphy's Law kicks in at 2 a.m. during peak processing season.

Another common factor of Simple Business Applications^TM is perpetual change. SBA's are living and breathing entities that evolve over time: Fields get added, fields get deleted, validation rules change. Edicts from governing agencies impose new constraints. Changing business partnerships impact workflow. Nothing is truly static.

Add to the nature of SBA's the inevitability of staff rollover (developer's tend to change jobs frequently), and you start to place a premium on code that is robust, easy to fix and easy to learn.

Continue Reading...

This work is licensed under a Creative Commons License.