views:

120

answers:

3

A thing that I noticed about most JavaScript frameworks is that the most common way to find/access the DOM elements is to use CSS selectors.

However this usually requires the framework to include a CSS selector parser, because they need to support selectors, that the browser natively doesn't, foremost the frameworks own proprietary extensions.

I would think that these parsers are large and slow. Wouldn't it be more efficient to have something that doesn't require a parser, such a chained method calls?

Some like:

id("example").children().class("test").hasAttribute("href")

instead of

$("#example > .test[href]")

Are there any frameworks around that do something like this? And how do they compare with jQuery and friends in regard to performance and size?

EDIT: You can consider this a theoretical discussion topic. I don't plan to use anything other than jQuery in any practical projects in near furure. I was just wondering why there aren't any other, possibly better approaches.

+3  A: 

Notice how much longer that is. Everyone uses CSS-style selectors for a reason.

jQuery's Sizzle library has been optimized for parser speed, so you shouldn't worry too much.

SLaks
Well, I don't think that shortness is always better. I think my example is much better readable. And I know Sizzle is fast, I was wondering whether a non-parser solution would be even faster - and smaller.
RoToRa
The jQuery version is at least as readable, if not more so, if you know CSS (which you should).
DisgruntledGoat
+2  A: 

DOM traversal and manipulation are some of the most helpful functions in current popular JavaScript frameworks because of the way they efficiently handle cross-browser issues. If you are working with the DOM, you will eventually need that functionality, and anything you write yourself is bound to be less efficient than the best methods.

In terms of speed, I would imagine the slight performance hit from parsing the selectors would be offset by the optimization inherent in the engine. If you rely on the programmer to specify the path (i.e. your example), you may be missing out on optimization opportunities that you didn't know existed. In your example for instance, let's say that it's ultimately faster right-to-left (find all class="test" with hrefs first, then check parents). You would be relying on the programmer to memorize these optimization quirks.

Andrew
I don't think cross-browser comes into this. As I see it, parsing is only the first step. After understanding/parsing the selector the elements need to be found and I would say both approaches would use similar (the same?) way to do that. The main difference would be understanding the selector (string parsing on one side, objects and methods calls on the other).
RoToRa
$("div span:first-child") works in IE6, despite the CSS pseudo selector not being implemented. That's what I mean by obfuscating cross-browser issues. Not sure what you mean?
Andrew
What I'm saying is: The parser does the same thing, no matter what browser it's running in and no matter what features that browser supports. Even though Firefox (for example) supports `:first-child` the selector still needs to be parsed by the library, because the library has no way to determine that the browser supports the selector until it has been parsed. In my theoretical library would have instead a method `.firstChild()` which could immediately utilize the features of the browser without having to parse anything.
RoToRa
Ah, gotcha. Updated answer above.
Andrew
i dont think obfuscate is the right term to use here
mkoryak
Good point. Thanks.
Andrew
@Andrew I understand what you mean. For example, the selector `div#some-id` can be optimized to first look for an element with the ID and then check if it's a DIV, instead of first getting all DIVs and then finding the one with the right ID. You are saying a developer using my library would have to know that it's better to use `id("some-id").tag("div")` than `tag("div").id("some-id")`. I actually was thinking about exactly this kind of optimization and wondering if there is an "easy" way to implement the library to have both expressions do the exactly the same (optimized) thing. ...
RoToRa
(Continued from above) I believe it is, but I'm still working on it in my head.
RoToRa
+1  A: 

From what I've read these libraries (or JQuery atleast) use the browser native capabilities where possible. This means that you can use css selectors with minimal impact by sticking to simple id's and classes where possible.

Personally I haven't noticed any speed issues from these libraries at all. When building web apps, virtually all your speed issues come from network communications, so the best way to increase the responsiveness of your application is to reduce the number of queries you make to the server.

For example, I'll use JSON to pass and store more data in one go (even if some of it may never be needed), rather than making lots of little queries.

As hinted at by SLaks, css selectors make code readability and long term maintenance much easier and reduce coding time. And as Andrew says, these libraries also deal with the cross-browser issues for you, resulting in a much lower rate of hair loss.

AllenJB