Skip to main content

How different are ajax4jsf and jMaki

6 replies [Last post]
Joined: 2003-06-11

Hi All,

I am trying to evaluate JSF Frameworks and found jMaki and ajax4jsf very interesting..

It seems jMaki not only Support AJAX behavior for JSF Components but also for existing Java Script toolkits..
Where as ajax4jsf can only provide ajax behavior for JSF Components..

what are the differences between these..How well they merge with the JSF Lifecycle etc..


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-08-24

I use Eclipse IDE Version: 3.2.0 enhanced with MyEclipse and JMaki is working flawlessly.

I even got Rico framework working using JMaki :P and I'm currently using the Rico Livegrid in one of our applications.


Joined: 2006-08-08

I think over using tools for Ajax and Jsf and some useful UI widget in jsr 168 portlets in Websphere portal jdk 1.4.
I see the backbase, infragistics, Ajax4Jsf, jmaki, ICEFaces and G4JSF. I don't convinced witch of them to use. I use eclipce IDE and jmaki work with Netbeans.
What is your recommendation?

Erwin Karbasi
Development Architect

Joined: 2003-07-31

Hi Erwin,

Many of the frameworks you mention mantain the view state on both the client and the server. While there is a penalty keeping both sides in synch it may be better if you have a JSF centric architecture where the state must be in sync. Also the frameworks you mention tend to use the full JSF life-cycle where the validation facilities of JSF are used even on AJAX based requests.

Use jMaki if you are really interested in JavaScript centric rendering of your widgets on the client. In this cased a JSF component renders some intial HTML div components and JavaScript tags to re-render the content on the client. The benefit here is you can get some really snappy UIs.

Keep in mind jMaki uses JSF 1.1 by default and the PhaseListener approach by default which means you will be responsible for making validation occurs before forms are submitted (when using AJAX communication) and you will be responsible for making sure the model data on the client and server are in sync.

We are working with the JSF Extensions project ( to make sure that we can maintain client and server state if you are using JSF 1.2 or better.

So my recommendations are:

If you need JSF 1.1 and want a widget that is JavaScript centric go for jMaki.

If you are using JSF 1.2 use jMaki with the JSF Extensions

That said if one of the other solutions you listed suites your needs please don't feel like you have to use jMaki.

Joined: 2006-08-24

We currently use A4J we are planning on using JMaki for future projects because its 50% faster and it's easier to develop also and the cool thing is we get to use Dojo :P

Currently and this is what we got to see using A4J it takes a load in our appz since it loads the whole page again and again in the backend and only renders the part you want to update and its kinda slow. Like really slow and using JMaki is lightning fast... just click and show.. with A4J is click and .. .. .. .. 5 6 sometimes 15 sec later it updates.

Hope this helps this is just a brief I didnt want to get into technical details.

Joined: 2003-07-31

One of the benefits of using jMaki is that we optimize the loading of Dojo widgets under the covers. This shows the true benefits of having jMaki render the widgets and bootstrapping them.

I'm glad to see that you are getting good results.

Joined: 2003-07-31

Many of the components that have values can be mapped right into Managed Beans using value binding expressions. See the Dojo Calendar, Dojo InlineEdit, Yahoo Calendar, Google Menu Popup, Scriptaculous Inline Edit for examples of these.

jMaki is JSF 1.1 based and uses the PhaseListener approach. This means that if you do updates to your managed beans they updates will happen outside of the normal lifecyle. If you have validatiors for example you are going to have to have to make sure the proper validation on your data. Also if you have view state you are going to have to ensure that gets passed around properly. If your widgets are in a form that is submitted later this is not an issue. More on the JSF approaches can be found at:

That said jMaki is working in conjunction with the JSF Extensions procject ( to make sure that jMaki widgets that have state behave properly in a JSF environment. Currently the best example of jMaki workin with the extensions may be found from the "jMaki, JSF, Standard Components, and AJAX" link on the JSF Extensions Page.