Wednesday, May 10th, 2006

Raising the Team Collaboration Bar with AJAX and JSF

Category: Java, Programming

New from’s Java section of their site comes this quick look at the combination of Ajax and one of the newer offerings by Sun – their JavaServer Faces.

I am excited about Sun Microsystems’ JavaServer Faces (JSF). Multiple, psychological studies prove that “group think” results in diffusion of responsibility and poor output. JSF has potential as an effective product development framework and supports both the building of AJAX-based Web applications and helps teams collaborate. What developers need is a way to promote collaboration and get the front-end team talking to the back-end team.

The introduction of AJAX, Web 2.0, and rich Internet applications is driving demand for a new wave of Web development. This demand is for more complex Web applications and will be a big challenge for all development teams. Overcoming this challenge will require a new level of team collaboration. Front-end development is no longer an afterthought; the front-end is the ‘Application.’ Collaboration between front-end and back-end developers is becoming more important. Teams who fail to collaborate will suffer.

The author introduces JavaServer Faces, mentioning its role in the technology tree (part of J2EE and built on top of JavaServer Pages). Follow that, he describes the problem that he sees this technology being able to take care of – the issue of collaboration between front-end and back-end developers. Time can be lost between each waiting for the other to finish, and without some kind of isolation, this is a difficult problem to overcome.

Instead, he suggests that the included UI components and some planning can make the JSF technology work for you, making collaboration easier and reducing the risks of integrating development from various individuals. He’s also included some specific ways that the framework can help you accomplish this goal.

Posted by Chris Cornutt at 7:17 am

3.6 rating from 41 votes


Comments feed TrackBack URI

While the conclusion or idea may be fine, it must be said that the article is worthless. It can be compressed to: “Lack of collaboration is a problem. JSF will help you have better collaboration in your team. Why? Because it does.”

There’s no real information on how will that happen, what JSF provides for collaboration or why is it better than previous solutions. The author does not include specific ways that the framework can help. He speaks broadly and generally.
Is this “Craftwork + structure -> Engineering + reuse -> architecture” specific? Does it even have any meaning at all?

Comment by Gonzalo — May 10, 2006

I did a presentation on a similar topic in Minneapolis last night. Often whe you are developing between the client and server, they two must (of course) be coordinated in parallel. In terms of AJAX, you must determine what and how the data is pulled on the server, and then coordinate/mediate this behavior in the mix of everything else on the client via JS or whatever. It’s mixing these two pieces of development which cause complexity in development. This is the same for most, traditional Model 2 frameworks, including RoR, even outside of AJAX.

The slight advantage of something like JSF is that instead of managing/mediating the client and server as two separate pieces under Model 2, you deal with the single notion of a ‘component’. The component itself mediates all of the client/server communication, including AJAX apis, http, parameters, data formatting, etc.

Comment by Jacob — May 10, 2006

[…] I just made the home page of […]

Pingback by Godfrey’s Blog » Blog Archive » picked me up — May 10, 2006

Thanks ajaxian and Chris for the great exposure. I look forward to more feedback. Collaboration is becoming more critical. Effective team collaboration will “make or break” your AJAX project. AJAX is a major shift in focus to the front-end. For Java folks JSF helps a huge amount.

As developers, we need to have fun. AJAX is fun and we can create great web applications. AJAX web apps can really get end users excited. Component-based development is a great way to keep the development of these web applications simple and fun.

Here is a video that shows how easy building AJAX apps with JSF is:

Comment by Godfrey — May 10, 2006

That’s cool, but the whole issue with the JSF space right now is that everyone’s developing vertical solutions to AJAX. Use this component or that component to solve a specific task. The real evolution that needs to take place is a standardization in the JS Agent realm and in the framework itself, to mediate the ajax communication in order to provide a consistent foundation for all JSF component developers and allow for standardized hooks for the end developer. This can easily happen with JSF 1.2 and the additions we made. So while all of these component packages are great, even in large quantities of almost ‘framework’ proportions, we have to solve/enhance JSF at a much lower, more fundamental level. The features are now API capabilities are now there, we just have to publish it. More at J1–

Comment by Jacob — May 10, 2006

I agree, the one area programers waste a lot of money is lack of collaboration. Why should industry pay for this? How much time is spent programming that ends up on the cutting room floor.

Comment by Brit — May 10, 2006

Following shows a perfect model for collaboration between application developers and web designers.

No serious applications can ever emerge with out a solid set of reusable GUI Widgets, which must offer higher-level abstractions that let developers focus on business logic at hand. Imagine writing desktop GUI, without Windows GUI-API. Are you going to implement all the primitives yourself and include in the same functions that implement business logic?

This web page shows how one can build reusable Ajax GUI Widgets:

I am a Java developer. I ask Web designers to give us great GUI Widgets and we will build great GUI applications!

Isn’t it simple?

Comment by Murthi — May 10, 2006

Leave a comment

You must be logged in to post a comment.