Live node lists make all dom mutation slower, so while it might look faster
in your benchmark it's actually slower elsewhere (ex. appendChild).
Do you have a real application where you see querySelector as the
bottleneck?
On Apr 27, 2015 5:32 PM, "Glen Huang" <curvedm...@gmail.com> wrote:
> I wonder why querySelector can't get the same optimization: If the passed
> selector is a simple selector like ".class", do exactly as
> getElementsByClassName('class')[0] does?
>
> > On Apr 28, 2015, at 10:51 AM, Ryosuke Niwa <rn...@apple.com> wrote:
> >
> >
> >> On Apr 27, 2015, at 7:04 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> >>
> >> On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang <curvedm...@gmail.com>
> wrote:
> >>> Intuitively, querySelector('.class') only needs to find the first
> matching
> >>> node, whereas getElementsByClassName('.class')[0] needs to find all
> matching
> >>> nodes and then return the first. The former should be a lot quicker
> than the
> >>> latter. Why that's not the case?
> >>
> >> I can't speak for other browsers, but Gecko-based browsers only search
> >> the DOM until the first hit for getElementsByClassName('class')[0].
> >> I'm not sure why you say that it must scan for all hits.
> >
> > WebKit (and, AFAIK, Blink) has the same optimization. It's a very
> important optimization.
> >
> > - R. Niwa
> >
>
>
>
