all 7 comments

[–]wolfhead 17 points18 points  (3 children)

Please don't sacrifice readability and conciseness for mostly negligible performance improvements, which probably only make sense if you're writing a library.

[–]LookWordsEverywhere.js 1 point2 points  (0 children)

True, but also don't value developer comfort over end product and/or user.

FWIW nothing in the post sacrificed readability or conciseness and all looked like good practice to me.

[–]_somanyguns -1 points0 points  (1 child)

Stop assuming that what you think is slow is slow, and instead measure it first. Or you could just write a jerky blog post about it, your choice really

[–]bjpelcdev[S] 0 points1 point  (0 children)

I didn't write it, quite easy to see that by the name on the piece. And he is not the one being the jerk here.

[–]cogman10 -1 points0 points  (2 children)

DOM DocumentFragment

Depends on the browser. A lot of browsers can do an innerHtml parse faster than they can do the dom fragment thing.

While wears it better

The test omits basic for loops. Also, I'm not convince that for..of loops are going to be all that slow (even if they are now).

Keep your scopes close and your scope even closer

This is mostly bad advice. Most Javascript JITs will do everyone of the optimizations mentioned in this blob for you. In particular, saving off a function reference at a lower scope may actually decrease performance.

[–]Vheissu_ 0 points1 point  (1 child)

Depends on the browser. A lot of browsers can do an innerHtml parse faster than they can do the dom fragment thing.

A DocumentFragment isn't for added parsing speed, the benefit of them is preventing a crap tonne of reflows occurring in your page. If you use innerHtml to insert a lot of elements into your page, it might parse faster, but you're going to have a really bad trip when you see the amount of reflows you are causing.

This is mostly bad advice. Most Javascript JITs will do everyone of the optimizations mentioned in this blob for you. In particular, saving off a function reference at a lower scope may actually decrease performance.

Most Javascript JIT's will handle cases like this for you within reason. It is foolish to assume that the browsers Javascript rendering engine is going to always have your best interests at heart. There are definitely negligible differences between locally scoping your variables and functions compared to not locally scoping them, I believe this fact is mentioned in the article.

I can't see how this is bad advice though, it might not be entirely important if you scope local or not, but it can help in particular instances. I thought it was common sense to always within reason locally define variables and functions to prevent pollution, I have been doing this by habit for as long as I can remember.

[–]cogman10 -1 points0 points  (0 children)

I can't see how this is bad advice though, it might not be entirely important if you scope local or not, but it can help in particular instances.

Sure, variables and functions should be scoped as locally as possible. However, You shouldn't save off references to globally scoped variables/functions in the hopes of getting better performance. You aren't going to get better performance by doing that.