Hey Matt -
Thanks for the post. It looks like you've spent a lot of time really
considering the issues. I agree, choosing a library is non-trivial.
I'll try to answer a bunch of your questions, be sure to let me know
if I missed any.
> 1) There seems to be a lot of emphasis on using selectors and
> pseudo-selectors to access everything. It makes code short and simple, but
> is it really the most efficient?
"most efficient"? The absolute fastest way to traverse the document
would be to write pure DOM code, by hand. Short of that, jQuery is
incredibly fast. We've been in a friendly competition with Dojo and
Ext over the speed of our selectors. We're all getting to the point of
not being able to become any faster. I think that's pretty reasonable
:-)
In short, we can never be as fast as unadulterated DOM code, but we're
very close - so close that you'll be hard pressed to find a noticeable
difference.
> 2) Why encapsulate elements in a jQuery object rather than extending
> HTMLElement? Using the latter, you gain the ability to use built-in methods
> and properties of the elements, and you only have to worry about hacking it
> to work for IE (but hopefully not IE8!).
A couple reasons:
1) This functionality does not exist in IE, nor is it completely
duplicable in IE. For example, look at this piece of code taken from
the official Prototype documentation:
// this will error out in IE:
$('someElement').parentNode.hide()
// to make it cross-browser:
$($('someElement').parentNode).hide()
We pride ourselves on complete cross browser stability. We'll take
consistency and speed over pure "features" any day. You should never
have to write an ugly cross-browser hack when using jQuery - and
that's a big thing to consider. Since HTMLElement doesn't afford us
that ability (yet), we've stayed away.
2) Assuming that we could get some form of HTMLElement to work, the
entire concept is "leaky". Attaching properties to elements at runtime
means that you have to remove them before the elements are removed
from the DOM; otherwise you get memory leaks (another thing we try to
avoid).
3) Attaching properties to DOM elements is really really slow. Doing
speed tests comparing this technique against storing elements in an
array, and iterating over them on a case-by-case basis, the array
(jQuery) way is always faster.
4) Finally, and perhaps most importantly, it simply doesn't embody the
jQuery philosophy. jQuery is designed to match a set of elements. This
set can have 0 elements, or a hundred - it makes no difference to
jQuery. For example:
$("div.foo").hide();
There could be no divs on the page - or no divs that have that
particular class, I don't know that, nor do I have to worry about that
being the case.
And again with finding elements by ID:
$("#test").css("color", "red");
There may be no element like that on the site, but you don't have to
worry about that. Whereas, in most other libraries you'd have to write
something like this:
var elem = $("test");
if ( elem )
elem.css("color", "red");
We definitely tend to opt for simplicity on this point.
> 3) Some of the functions in jQuery seem to be "magic" in that they do and
> return a lot of different things depending on how they are called. This
> seems very Perl-ish to me, and that's one of the things that ended up making
> Perl so insanely incomprehensible to many. Why overload so many methods,
> rather than giving them their own understandable names?
Some of these came from some of our early growing pains. .load() can
mean two different things, as does .toggle(). These were mistakes, but
"clarifying" them is really rough (as it would require a fairly harsh
API change to some very-popular features). That's not to say that they
won't be changed some day (jQuery 2?).
However, the design decision to pick concise names in favor of "truly
explanatory" names does have a taste of Perl, to be honest. I guess
that's just how we've gone along - it's what we particularly enjoy.
> 4) Any chance of a jQuery-lite, without all the css selector logic? Or is
> that kind of Sonny without Cher?
We've been considering it - however, it's hard to gauge what's open
for removal, and what's not. Instead, we're probably going to try and
provide a really-strong download page that'll let you add/remove
particular sub-features that you want (for example, if you didn't want
basic XPath support, you could remove it.) That's in the works right
now.
In the meantime, the selector logic is, effectively, the strong core
of jQuery - it's what makes it what it is, as a library. Frequently,
developers will find themselves in the "Give an ID to everything on
the page" mindset, but that's not what we're about. It's all about
building a flexible selector that can work on semantic content - no
extra crufty attributes, or repetitive code, required.
> 5) What is the max compressed file size you want to stay under? Will plugins
> and other extensions be pulled into the main source file at some point? Or
> is the goal to keep the current core functionality as-is and depend on
> plugins for any extended functionality? Is there any concern that the
> framework will become fragmented (again, like Perl) so developers never know
> which set of plugins (modules) they need to do the job?
We're never going to go above 20kb (promise). Plugins will never
forcefully be in the main source, instead, we're going to provide ways
to bundle plugins together with jQuery, compressing them both into a
single file. We're really big on keeping the core lean, and tight, and
using plugins to extend that functionality. There is a concern over
fragmentation, we're looking to alleviate this in a number of ways:
- A solid plugin repository
- The ability to rate, and comment on, plugins
- Effective multi-category categorization of plugins
- Finding, and recommending, similar plugins
In addition, we'll probably even provide guides for some of the most
popular "groups" of plugins. For example, we already have a bunch of
"Lightbox"-like plugins, all slightly different (but in important
ways).
Work is already under way concerning the plugin repository - you can
expect to see something very soon.
> 6) Finally, can anyone comment on introducing jQuery into a team of web
> developers with low to moderate javascript experience, building webapps or
> web sites that could run into the millions of dollars? Is jQuery robust
> enough and easy enough to deploy that it's an easy win?
It's absolutely possible. jQuery has already been deployed at a number
of large-scale web sites, no problem:
http://docs.jquery.com/Sites_Using_jQuery
We have some really great introductory tutorials - I find that people
will often "just get it" after I demo something like Table Row
Striping or building an accordion menu.
http://docs.jquery.com/Tutorials:Accordion_Menu_%28Screencast%29
http://docs.jquery.com/Tutorials:Zebra_Striping_Made_Easy
We currently have about 40 English tutorials (generally ranging from
Beginner to Intermediate) located here:
http://docs.jquery.com/Tutorials
Personally, when teaching new users, the more familiar a user is with
CSS, the more likely they are to really understand what jQuery is all
about - and this says nothing about their level of JavaScript
knowledge. We constantly have complete beginners writing excellent
code.
In fact, just this evening (on IRC - irc.freenode.net#jquery) a
non-JavaScript programmer, and brand new jQuery user, showed me a
complete plugin that he wrote - it was functional and very impressive.
I think that if you can go from having no JavaScript knowledge, to
extending a library, then you have a pretty good situation going.
Hope I've answered everything that you had in mind - let me know if
you have any more questions!
--John
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
