Earlier quoted context omitted.
One can always argue "you're doing it wrong". People say the same about ror and perl. But in my experience, even with a good mvc and object model, and world-class folks, complex applications in jquery tend to become hard to maintain. I believe part of the reason is the tight coupling of state and events to the DOM. I'm also very skeptical of the dozen-odd undocumented "extensions" to the selector language. They are u…
it's documented here http://api.jquery.com/first-selector/
The jQuery Divide:Understand where jQuery ends and JavaScript begins
71–78 of 78 posts
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#72Earlier quoted context omitted.
it's documented here http://api.jquery.com/first-selector/
Undocumented as in "we included it in our 'CSS3-compliant selector engine' but do not mention anywhere that it is not actually part of the CSS3 spec, just something we thought was cool".
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#73Earlier quoted context omitted.
I don't want to appear snarky, but as you admit yourself ("I dont have any data on it") you don't know if creating a jQuery object is expensive or not (to be fair, I don't know either) - so why all the extra complexity if you don't know whether the thing you are trying to avoid (creating instance of jQuery during event handlers) actually causes problems or not?
Well given that a lot of the "pro" jQuery tips say that one should avoid rerunning the selector in favor of some sort of memoization: $('.class').doSomehting(); $('.class').doSomethingElse(); $('.class').thirdThing(); in favor of var ele = $('.class'); ele.doSomething(); ele.doSomethingElse(); ele.thirdThing(); I would only assume that re-querying with the jQuery object inside of event handlers has the same adverse e…
https://github.com/jquery/jquery/blob/master/src/core.js#L67
Wrapping elements in event handlers is completely fine.
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#74Earlier quoted context omitted.
Undocumented as in "we included it in our 'CSS3-compliant selector engine' but do not mention anywhere that it is not actually part of the CSS3 spec, just something we thought was cool".
http://api.jquery.com/category/selectors/ "Borrowing from CSS 1–3, and then adding its own, jQuery offers a powerful set of tools for matching a set of elements in a document."
Now that we've gone all the way down the pedantry slide, have you anything of value to contribute, or was that it?
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#75Earlier quoted context omitted.
Shouldn't the second one be: var d = $('div'), a = $('a'); a.each(function(i, el){ d.text(d.text() +' '+ a.eq(i).text() ); }); Using eq(i) rather than index(i)?
I feel like this should have been the first replay to my rant. The nodes are already wrapped in the jQuery object, just need to use eq to access them by index. I've never seen that before, thanks
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#76Earlier quoted context omitted.
Well given that a lot of the "pro" jQuery tips say that one should avoid rerunning the selector in favor of some sort of memoization: $('.class').doSomehting(); $('.class').doSomethingElse(); $('.class').thirdThing(); in favor of var ele = $('.class'); ele.doSomething(); ele.doSomethingElse(); ele.thirdThing(); I would only assume that re-querying with the jQuery object inside of event handlers has the same adverse e…
Interacting with the DOM is what's slow. It's especially slow if the native querySelectorAll method isn't available because any non-trivial selections necessitate iterating over the DOM tree. That's why you don't want to re-query a selection multiple times. That's also why it's recommended that all selections start with an id. The size of the tree to iterate over can be quickly reduced using the native getElementByID…
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#77I don't see it mentioned very often, but google's closure-library has some really phenomenal patterns for building maintainable javascript. Its worth checking out Michael Bolin's book, Closure: The Definitive Guide, which goes in depth of the Component and Control frameworks. I've been using the library for 2 or 3 years now, and I am always surprised to see it has such a small community.
Here is Michael's blog: http://blog.bolinfest.com/
And the HN discussion from when it was first open sourced: http://news.ycombinator.com/item?id=924426
Compiler : http://code.google.com/closure/compiler/
Library : http://code.google.com/closure/library/ (UI / widgets)
Templates: http://code.google.com/closure/templates/
Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins
#78Earlier quoted context omitted.
http://api.jquery.com/category/selectors/ "Borrowing from CSS 1–3, and then adding its own, jQuery offers a powerful set of tools for matching a set of elements in a document."
Yes, you've found the five-word phase that mentions that there are extensions in the selector engine. There is no documentation on which things are, or are, not, extensions. Now that we've gone all the way down the pedantry slide, have you anything of value to contribute, or was that it?
If you want to pick on something that claims compatibility, try Sizzle itself - http://sizzlejs.com/. In that case, you'll find a summary of alterations right at the top of its documentation https://github.com/jquery/sizzle/wiki .