5 ms·

Honestly, who cares? If your bottleneck is really your JS library, you need to re-evaluate what it is that you're doing. In a practical situation, you would nev

by nkohari 17y ago

Honestly, who cares? If your bottleneck is really your JS library, you need to re-evaluate what it is that you're doing. In a practical situation, you would never manipulate thousands of DOM elements at once. Benchmarks are fun, but largely irrelevant.

noarchy 17y ago
This was my own thinking. If this is another one of those "runs .1 seconds faster in the benchmark tests", then I am not really impressed. On how many websites are you really going to notice this?
bumblebird 17y ago
There's some pretty sluggish websites out there due to poor use of js libs. Browse them on a phone or netbook and it all adds up. You'd certainly manipulate hundreds of DOM elements at a time, consider say a twitter stream, where each post has "10 seconds ago" marker, and they all need updating.
- DougBTX 17y ago
  The bottleneck in that situation would be finding the elements, not updating them. If there is any worry about performance, the change would be to cache that list of elements rather than searching again and again, regardless of the library used. (Unless your library was very clever, and could cache the results for you. I'm not sure what browser support there is for ondomupdated events, which you would need to watch for this to work in a general fashion.)
flatline 17y ago
Okay, sure, for a document-based website with a few bells and whistles. If you want to build one of these new-fangled "web apps" that I hear so much about, you will absolutely need to manipulate hundreds or thousands of DOM elements and do so fast and consistently across god-knows-how-many versions of - to make the list short - IE, FF, Safari, Chrome, and Opera. There is a major push for JavaScript optimization going on industry-wide, and the libraries are a crucial component of this.
- nkohari 17y ago
  First, I own one of those new-fangled web apps (http://agilezen.com/ http://agilezen.com/). It's built on jQuery, has a fairly complex Javascript-driven UI, and nowhere do I manipulate hundreds or thousands of DOM elements. Second, I wasn't arguing against libraries -- I was saying that the difference in performance is probably not what you want to use to decide which library to use.

by nkohari 17y ago

noarchy 17y ago

This was my own thinking. If this is another one of those "runs .1 seconds faster in the benchmark tests", then I am not really impressed. On how many websites are you really going to notice this?

bumblebird 17y ago

There's some pretty sluggish websites out there due to poor use of js libs. Browse them on a phone or netbook and it all adds up. You'd certainly manipulate hundreds of DOM elements at a time, consider say a twitter stream, where each post has "10 seconds ago" marker, and they all need updating.

DougBTX 17y ago
The bottleneck in that situation would be finding the elements, not updating them. If there is any worry about performance, the change would be to cache that list of elements rather than searching again and again, regardless of the library used. (Unless your library was very clever, and could cache the results for you. I'm not sure what browser support there is for ondomupdated events, which you would need to watch for this to work in a general fashion.)

flatline 17y ago

Okay, sure, for a document-based website with a few bells and whistles. If you want to build one of these new-fangled "web apps" that I hear so much about, you will absolutely need to manipulate hundreds or thousands of DOM elements and do so fast and consistently across god-knows-how-many versions of - to make the list short - IE, FF, Safari, Chrome, and Opera. There is a major push for JavaScript optimization going on industry-wide, and the libraries are a crucial component of this.

nkohari 17y ago
First, I own one of those new-fangled web apps (http://agilezen.com/ http://agilezen.com/). It's built on jQuery, has a fairly complex Javascript-driven UI, and nowhere do I manipulate hundreds or thousands of DOM elements. Second, I wasn't arguing against libraries -- I was saying that the difference in performance is probably not what you want to use to decide which library to use.