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
