Live data from Hacker News

The jQuery Divide:Understand where jQuery ends and JavaScript begins

slideshare.net

71–78 of 78 posts

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#71
post #39

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/

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

#72
post #71

Earlier 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".

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."

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#73

Earlier 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…

Re-running a selector and wrapping an element in the jQuery object aren't even close to the same thing:

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

#74
post #71

Earlier 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."

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?

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#75

Earlier 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

They actually aren't already wrapped. The .eq() method pulls an element out of the collection and wraps it in a new jQuery object.

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#76
post #44

Earlier 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…

The selector engine runs right to left so even if you start with an id but end it with an element it will still be an expensive query. I think the key is to think about your selectors and not go overboard because it's easy.

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#77

I 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.

It does look like an interesting library. It's weird that the community seems so small.

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

#78
post #74

Earlier 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?

You're being disingenuous here. Anybody looking for information about jQuery's selectors will google "jquery selectors" and find that five-word phrase front and center. Or take a look at the jQuery front page and hover over "CSS3 Compliant" to see "Supports CSS 1-3 selectors and more!".

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 .

Post reply on HN