Wednesday, March 23rd, 2005

Ajaxian libraries: Learning from Java Web Framework problems

Category: Ajax, Editorial, Java, JavaScript, Library

<p>Having a lot of different implementations and innovations is certainly a good thing.

However, many Java web developers are frustrated as hundreds or thousands have sprung up over time. As soon as Servlets and JSPs were released, people realised that they wanted to build a framework at a higher level of abstraction. This lead to pet projects starting up all over.

Some of these projects made their way to opensource. Some are still in use in production apps.

Consilidation has happened, and the JCP is trying to push that ahead even more so with the JavaServer Faces specification. But, people haven’t all been thrilled with its technical merits.

I worry that we face a similar problem in the JavaScript, and Ajax world. We already have many abstraction modules out there. How many people do their own thing to get the browser type etc.

We need to take more advantage of reuse. I want to be able to say:

My current project is using Foo and Bar.

and have it mean the same thing as:

My current project is using Struts and Spring

Part of the game is taking JavaScript developement seriously, and using tools such as Maven repositories to keep track of dependencies and JavaScript modules.

Also, we have the benefit of having frameworks like Rails, JSF, Tapestry, WebWork, ASP.NET etc… all helping us out. This means that developers don’t need to be JavaScript gurus to get simple things done.

Related Content:

  • Learning
    SearchStorage.com provides IT pros a full range of learning resources to help you make informed technology decisions and quickly troubleshoot the...
  • How to Learn Java
    Are you interested in learning Java? Interested in getting a Job in the IT industry as a Java programmer? Well, Janeice Del Vecchio, a presenter at...
  • Simplifying data access using Java Standard Tag Library
    Learn how to quickly build a simple JSP to search an employee table using SQL to demonstrate how easily JSTL accesses...
  • Installing the JavaServer Faces Web application framework
    Obtain and install the JavaServer Faces Web application framework as a solid basis for deploying Java applications on a Tomcat...
  • Cocoon as a Web Framework
    Art of Java Web Development covers several different Model 2 web frameworks. Cocoon is more than one type of framework. Cocoon automatically...

Posted by Dion Almaer at 5:11 pm
3 Comments

++---
2 rating from 4 votes

3 Comments »

Comments feed

I absolutely agree with you on taking javascript more seriously. Even within our own applications it should be taken more seriously. Too often developers or web designers (including myself) just hack together some common.js file that has dozens of functions. Not only that, but they/we copy code from old existing apps and just tweak em a little. Maintainig all that code becomes a nightmare.

We need an organized repository of “good” javascript libraries and packages that we can simple “install” and use. Much like the PHP PEAR project. A tool like Maven would be perfect for this. So anyone care to put together an online repository and start compiling some good javascript code into it?

Comment by Ramin — March 23, 2005

jsaulait (http://jsolait.net/) has a pretty nice “Module” framework, like packages and with an import mechanism, check it out:

http://jsolait.net/doc/tutorial.xhtml

Comment by Daniel Serodio — March 24, 2005

All I would like to see to start is an abstraction module in Javascript to hide the browser differences so that I can use XHR and other common features without having to duplicate the workarounds. And then I should be able to copy/paste code across client projects. Naturally I would share and verson control the base framework to benefit all clients from upgrades as the framework must evolve with new browser releases.

Anything more than a simple compatibility layer would be more than necessary for most uses.

Safari 1.3 is due out with the April release of MacOS X and I am expecting to see many XHR improvements, but as Safari 1.2 was the first release with XHR and the fact that users will not instantly upgrade I will need that abstraction layer to satisfy Mac users.

And around the corner is IE7. I am curious what JS changes that may include.

Comment by Brennan Stehling — March 24, 2005

Leave a comment

You must be logged in to post a comment.