Hi,
> In my May 2 2007 11:21 post I mentioned a jQuery port of JSAN making
> it a plugin to jQuery. the code in that post is the entire contents
> of the file jqjsan.js which comes out to 1,116 bytes in an
> uncompressed state. The compressed jsPax is 1,654 bytes. But as you
> pointed out they are really getting at the same end result.
But you need jQuery loaded before you can use it, correct? That means, you
need a fiew bits more than just 1116 bytes that are initially loaded. JsPax
doesn't need anything to be loaded before.
> Because the load of $.jsanUse is done async:false I can
> use it's methods immediately after the request instead of the function
> in jsPax's $using.
On the other hand jsPax can load multiple Libraries in parallel:
$using(['jQuery','my.other.lib','yet.another.lib'], function() {...});
Then jsPax starts three XMLHttpRequests and executes the function as soon as
all three packages are completely loaded with all dependencies. The browser
can do his best efforts to optimize the requests. He can pipeline the
requests in one connection, he can use multiple connections or a combination
of that.
If you use very many small libraies which depend on even more small libraries,
your performance will noticably increase with jsPax.
> Of course the app 'pauses' during the load, but
> this has not caused any complaints from the users as the files are
> small enough to typically load in < 100ms.
I guess that depends on the connection your user uses. Try the same with a
connection with a long round trip time - e.g. dialup GSM connection.
My experience is that most people don't complain about a bad user experience
as long as they don't know that it could be done better.
> The plugin I showed there supports altURLs that are not the same as
> the namespace and a flag to use the -min version of a file.
I have thought about features like that when I developed jsPax. I came to the
conclution, that the cases you need them are so rare, that they don't justify
a bigger package.js. Whenever you really need it, you cann create a package
to handle that.
> Because
> it is using the XHR+eval approach it does not yet support js files
JsPax uses XHR+eval as well. If the Browser doesn't have a XHR-implementation
it tries to use DOM to create a script tag. The Reason why I chose XHR+eval
is, that there are Safari Versions that don't eval scripts that are added via
DOM.
> JSAN was created about a year before jsPax
> http://use.perl.org/~schwern/journal/24112 and I first used it in a
> commercial project in January of 2006.
I knew JSAN before I created jsPax, but there were some reasons why I did not
use it:
1. It uses synchronous XHR, which means the browser can not really optimize
the calls - I was creating a complex set of small libraries for a specific
Application.
2. It doesn't have a fallback for Browsers without XHR - the Application I was
developing could not accept that.
3. It has a lot of stuff in the API that is not absolutelly necessary for a
package system and thus unnecessarily makes the core Library unnecessarily
big.
4. I don't like the API that results form the synchronous loading. I much
prefer the callback when all needed Libraries are loaded.
> I have used it in almost every
> project since, and this is really the main reason I talk about it over
> anything else.
I have used jsPax in various professional applications now. I guess that there
is a stalemate here.
> I was drawn to the idea of a plugin for jQuery since that
> would allow it to use some of the functionality jQuery has built in like
> $.ajax
I do use jQuery plugins as jsPax packages. I use jQuery itself as a package -
there are some pages where I don't need jQuery, but other libraries.
Christof
