myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject Re: jsf-uncompressed.js in dev mode does not work out entirely
Date Fri, 25 Jun 2010 20:39:17 GMT
Hi Werner

I think we should activate it with a web config param. Debug using the real
scripts in firefox is really useful. The idea could be provide a
jsf-uncompressed.js file with all scripts as default on dev mode, but have a
config param like



2010/6/25 Werner Punz <>

> Hello
> I have been doing some performance tuning for the last day on our jsf.js
> scripts. So far things look good, the performance seems to be slightly
> faster (about 5-15% on a modern browser) than Mojarras under my testing
> conditions, except for one area.
> jsf-uncompressed.js does not work out as it should.
> Here is a small description: We use jsf-uncompressed.js to load the other
> scripts dynamically in dev mode.
> This works except for some things.
> To load the scripts and have them displayed properly in the debugger the
> loading must be done over appended script elements in the head, to load them
> and have them run, a script load via xhr and eval afterwards suffices.
> The problem now with the head method is, it fails in slight details on many
> browsers, especially if the scripts become bigger. In Chrome, you cannot
> rely on the loading order that way (known issue since 2008)
> In IE I have similar sideefects. What I would propose is following. Since a
> normal include works (and script loading afterwards happens over the
> reliable but not debuggble load - eval method)
> It might be possible to work it out over chains which trigger the next load
> upon an event finish, but for now this is overkill.
> I ran tests with the script src method over Firefox, IE in all its recent
> incarnations and Chrome based browsers and only on Firefox it ran reliably.
> We go back to step one as Leonardo proposed and have the build process
> bundeling all our files into one big jsf-uncompressed js file.
> I think for 2.0.1 this is the best solution.
> The scripts themselves if they encounter a src= tag are not affected since
> I fall back on the reliable method of synchronised xhr get with added eval
> for that part.
> I sure will revisit that part later this year, but for now having one big
> uncompressed file should be ok to keep the users happy.
> I think there are other issues more important, to tackle, than a non
> specced dynamic loading mechanism which keeps the files apart.
> Werner

View raw message