John you should start with Sizzle then, where the basic build will be
something like:
function Sizzle(selector, context){
return Array.prototype.slice.call((context ||
document).quertySelectorAll(selector));
};
Makes sense for every Sizzle based library, famous or home made one, no?
Regards
On Sat, Aug 22, 2009 at 7:32 PM, John Resig jere...@gmail.com wrote:
Additionally, if there is an appreciable difference, it's likely that
we would just change the logic in jQuery itself to only initialize the
specific code branches once (which is something that we should be
doing anyway).
--John
On Sat, Aug 22, 2009 at 2:01 PM, Kevin Dalmankevin.dal...@gmail.com
wrote:
For this idea to be taken seriously, I think you would need to create
such a version and benchmark it VS the all-in-one jQuery.js. IF you
can show significantl performance differences, then perpahs your idea
could gain some traction (though I'm not in favor of it). But if we
are only talking about *a few milliseconds* difference in normal use,
then this would not justify the increased maintenance and code
required at every level - development, testing, documentation, library
linking, etc. IMO, the performance improvemetns would need to be
significant and *noticeable* to justify all this extra work and
complication. Making users add branching logic to every page is not a
small matter.
My 2-cents.
/Kevin
On Aug 21, 4:01 am, ludovic ludothebe...@gmail.com wrote:
@DBj
Not exactly.
Before use, we generate a few browser-specific jquery files, like
jquery.ie7.js, jquery.ie6.js. Theses files are generated server-side
from the current jquery.js file from a support detection database. For
example, for IE6, we already know that the box model isn't supported.
So we replace all occurrences of if( jQuery.support.boxModel )
{ instruction a } else { instruction b } by instruction b.
We still have a jQuery file like we have currently. It can work on a
generic browser as the feature detection is made dynamically. It is a
bit slower as there are more conditions. The file name is jquery.js.
This file is downloaded only if there is no browser-specific jquery
file.
Now, when the page is loading, we can have two policices :
- One based on user agent : if it is a user agent corresponding to one
of our precomputed files, we download the precomputed one, and not
jquery.js. Else, we download the generic file, I mean jquery.js
- Another one based on client-side detection, with for example
!--[if lt IE 7]
!-- Internet Explorer before IE7 --
script src=jquery.2.ie_before_7.js /script
![endif]--
So, what I propose is what you called the ultimate solution and my
precedent message explained how I would generate the different files.
Regards,
Ludovic
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
