Hi Krishna, thanks for your comments. I'll try to address what you said:
But this is putting more rules on you to do stuff. There are already so many rules and frameworks to learn.
This is so true, if I have a gripe about java development is how much stuff people needs to learn just to get on the tracks of it. However, I think once Jawr has been set up it needs very little maintenance in terms of configuration. Also, in most cases the config file would be around 10-20 lines, so no huge descriptors here. As for the tag libraries, I don't think they should take more than two minutes to learn. So a lead developer may take care of writing the descriptor, and everyone else only needs a couple minutes to learn how to use the tags and the development mode.
...encourages to use only two modules in page (assuming the browser limit as 2). But real life scenario is far from this. In some scenarios, you might want 10 different files out of 10 different modules, but at the same time not the whole modules.
You can use as many modules in a page as you need to. Jawr helps you load as little files as possible per page by creating bundles. The modules live in these bundles. Of course you will not need them all at once, but think that, once a user has loaded a bundle once, it will be cached. Jawr serves files using many techniques to force the browser to cache the bundles.
For example: if page A uses modules Foo and Fuz, and page B uses module Bar and Fuz, what happens is:
* User visits page A, downloads a bundle with Foo and Bar. Bar is not used.
* User visits page B, Bar and Fuz are retrieved from cache, the page loads very quickly since the bundle is not downloaded again.
So even if a bundle contains modules not needed by a page, it is better to keep things together. If you made a different bundle for every page, this is what would happen:
* User visits page A, downloads a bundle with Foo and Fuz.
* User visits page B, downloads a bundle with Bar and Fuz.
You just lost any chance of retrieving Fuz from the cache. Instead, the user downloaded it twice. If you scale this to a whole application, you are not really going to have good performance.
Better idea would be to let the developer supply list of all js files needed on a jsp (lets say abc.jsp) to the taglib and concatenate&compress it at runtime.
Actually, you can do that exactly using the
pack:tag. You might want to check it out. I coded Jawr because I wanted to implement an external, dynamic mapping of reusable bundles. With the pack tag, if I want to reuse a bundle I must repeat its definition on every page that uses it. And if I add a new module to the bundle, I must go over every page and change it. With Jawr, I only need to place a new file under a mapped dir and it is automatically added to a bundle. Otherwise, the pack:tag is a nice, stable alternative and supports many minification tools.
What I mean by this is, output the name of the newly concatenated, compressed js file (or may be two files) into JSP. So that way, everything is taken care of the first time and this framework is out of picture for subsequent requests.
There is aproblem there: as far as I know, you can't create new files inside a WAR archive and let the web container serve them. So you whatever you create, it must be created under a temporary directory, and you must use a servlet to read and serve whatever you created (or otherwise cache it and serve from memory, which Jawr supports).