3 ms·

The fact that most js frameworks willfully ignore #2 has been one of the reasons I've avoided them. Doing a lot of DOM manipulations in code feels about as eff

The fact that most js frameworks willfully ignore #2 has been one of the reasons I've avoided them. Doing a lot of DOM manipulations in code feels about as efficient as making tons of system calls to an OS. Much better to do a few larger writes than many small ones. I've become a big fan of JST: http://code.google.com/p/trimpath/wiki/JavaScriptTemplates http://code.google.com/p/trimpath/wiki/JavaScriptTemplates . Send over template snippets as strings and use JST to put them together. With far fewer innerHTML replacements along the way.

edw519 17y ago
I feel the same way but never knew how to say it. If I need a complex algorithm that will run once a month and someone has already written an open source solution, then sure. But if I need something that must be efficient and runs thousands of times per day, then maybe I should roll my own. I guess the formula could be: WriteYouOwn if DevTimeSaved < (TxnTimeSaved * TxnsPerDay)
sachmanb 17y ago
The newer browsers (Chrome, Firefox 3.5 and such) use JIT JavaScript VMs. For that reason, I think it's not worth investing the effort of avoiding jQuery and going through all this effort for performance gains. It is highly likely that the browsers will optimize these kinds of things at compile time, and these kinds of problems will go away much like contemporary compilers reduced the need to make every string a constant and such (they are made into constants at compile time for you). There's plenty of other performance things to think about, though, but it doesn't seem to be worth it to me to chase this one.
- richcollins 17y ago
  It is if you care about the 70% of people online that use IE. I doubt IEs DOM will be speeding up any time soon.
- bsaunder 17y ago
  You're probably right now. I started down this road in 2006 when the JavaScript VMs weren't there yet with performance. At the time, it was a night and day difference (from don't blink to good-golly-what-are-you-doing). Also, I tend to like the declarative style of templates vs. the imperative style of code for my presentation layer.

edw519 17y ago

I feel the same way but never knew how to say it. If I need a complex algorithm that will run once a month and someone has already written an open source solution, then sure. But if I need something that must be efficient and runs thousands of times per day, then maybe I should roll my own. I guess the formula could be: WriteYouOwn if DevTimeSaved < (TxnTimeSaved * TxnsPerDay)

sachmanb 17y ago

The newer browsers (Chrome, Firefox 3.5 and such) use JIT JavaScript VMs. For that reason, I think it's not worth investing the effort of avoiding jQuery and going through all this effort for performance gains. It is highly likely that the browsers will optimize these kinds of things at compile time, and these kinds of problems will go away much like contemporary compilers reduced the need to make every string a constant and such (they are made into constants at compile time for you). There's plenty of other performance things to think about, though, but it doesn't seem to be worth it to me to chase this one.

richcollins 17y ago
It is if you care about the 70% of people online that use IE. I doubt IEs DOM will be speeding up any time soon.
bsaunder 17y ago
You're probably right now. I started down this road in 2006 when the JavaScript VMs weren't there yet with performance. At the time, it was a night and day difference (from don't blink to good-golly-what-are-you-doing). Also, I tend to like the declarative style of templates vs. the imperative style of code for my presentation layer.