4 ms·

>The try/catch is a very costly operation. You should write your code in such a way that exceptions are not uncertain. I believe all major JavaScript engines n

>The try/catch is a very costly operation. You should write your code in such a way that exceptions are not uncertain. I believe all major JavaScript engines now optimize try/catch. And SharedArrayBuffer is now disabled by default due to Spectre. I don't see it coming back soon either. Also, I dislike this article because it recommends these things "always". "Always use forEach", "always avoid delete", "always...". Not to mention it's yet another v8 specific set of optimizations.

davedx 9y ago
Yep, try/catch is optimized since node v8. The biggest takeaway from the latest batch of optimizations I read about is this: Write idiomatic JavaScript code! Secondly: Just because you're working with a dynamic language doesn't mean you should abuse it. Don't write functions with weirdly changing parameter arities, or dynamically change the types of variables. Finally: These things are all hints and micro-optimizations by themselves. Don't prematurely optimize at the cost of readability and maintenance. Profile and only fix things that need fixing!
metalshan 9y ago
Try/catch point is an in-general thing. Irrespective of language. Always better to handle errors by yourself. I was not aware of the browser deprecation of Shared array buffer. But this (or something like this) is a part of the ECMA proposal which is in stage 4. https://github.com/tc39/ecmascript_sharedmem https://github.com/tc39/ecmascript_sharedmem I said using forEach (or in-builts) are always a good practice. Now like you have to. For an example, if you have an array with no holes in it, for is better performant then forEach.
- Klathmon 9y ago
  >Always better to handle errors by yourself. I disagree, using try/catch/finally for their intended purpose (exceptional cases) is going to be preferable to trying to replicate their function on your own. Even if just from a semantic standpoint (is semantic the word i'm looking for here? it feels wrong...). >But this (or something like this) is a part of the ECMA proposal which is in stage 4. I really dislike the idea of true shared memory for the extreme vast majority of cases, and i'm not particularly happy about it's inclusion into browsers, so take what I say here with an appropriate amount of salt. I personally think spectre is only the first of many many problems it will bring if fully integrated. Transferable objects are a much cleaner and safer pattern to use in most cases, and they are here today in all major browsers. I do admit that having shared memory available is a massive bonus to some kinds of problems, but I feel the net impact will be negative. That being said, until a fix for spectre is either in hardware, or they find a way to solve it in software that doesn't destroy SharedArrayBuffer's performance, it's not coming back. And I don't see those happening within a few weeks/months in all honesty. >I said using forEach (or in-builts) are always a good practice. That was only one example of many in the article that I felt was making advice which works on one engine (v8), in a well-defined set of situations (sparse array, hot code paths, no async/await in the case of forEach), into a general truth. Not many things are universally true, and spelling out the when, why, and where you should apply this advice will go a long way toward teaching others rather than just giving people a list that they can haphazardly apply. Like your advice to avoid for...in. If you are iterating over enumerable properties, there is no reason to avoid it. It's slow, because that operation is slow, and most attempts to do it yourself more quickly will either fail, or will have edge cases that may introduce bugs. It's good advice in hot-path code, but shouldn't be universally followed. Especially when the alternative to a few lines of well-understood code is a mess of if statements, key lookups, and undefined/null checks.
- mschuetz 9y ago
  I find "for of" to be much more legible than "forEach". Not much difference in general but the "for" the beginning immediately tells me that there is a loop here, whereas I have to read more thoroughly to identify something as a loop in the forEach case. // for ... of for(let node of nodes){ console.log(node); } // forEach nodes.forEach(node => { console.log(node); });
  - Klathmon 9y ago
    For...of is fantastic and I use it quite often (especially in async/await codebases as it doesn't create a new function context!) However it is slow currently in all major browser engines. For fast-path code, you should reach for something else (like a for(;;) loop), but for most other loops I always tend to reach for for...of for it's ease of use and compatibility with iterators makes it a pleasure to use!
    - mschuetz 9y ago
      Are you sure about that? "for of" is something that I'd expect a js compiler to handle exactly the same way as forEach. I'd see how it might have been slower right when it came out but browser vendors are quick in optimizing their compilers. At least https://jsperf.com/for-vs-foreach/293 https://jsperf.com/for-vs-foreach/293 shows that there is no significant difference in for of vs forEach in my version of chrome. There is an insignificant difference acoording to which forEach is actually slower. (One forEach case in that benchmark is only faster because it does something different.) Edit: looking at the comparison at the bottom, it seems like forEach is actually significant slower than for of since chrome 61.
      - Klathmon 9y ago
        Ya know what I'm not as sure as i thought I was. I'm really glad that for...of isn't nearly as slow as it was when it was first profiled it. Thanks for that!
      - olliej 9y ago
        Lots of work went into making the perf of for(of) fast - after the initial “make it semantically correct” bits. There are many reasons it is faster, but it also has the nice property of working sensibly on any iterable object rather than forEach that only iterates by index, and has an annoying ‘if (index in object)’ in the loop.
- adrianN 9y ago
  In Python try..except is very idiomatic.
  - jakelazaroff 9y ago
    I wish JavaScript had Python's exception handling. There's no real way in JavaScript to catch only exceptions you're expecting, other than checking the error manually and re-throwing if it doesn't match.
- theandrewbailey 9y ago
  > For an example, if you have an array with no holes in it, for is better performant then forEach. Do you mean it's faster? (Don't use performant: use fast or faster instead.)
  - mercer 9y ago
    I might be wrong, but 'faster' strikes me as a more ambiguous word. In this context it would be clear, but I can see how consistently using performant would help in clarifying what this 'faster' you're talking about is.
userbinator 9y ago
Also, I dislike this article because it recommends these things "always". "Always use forEach", "always avoid delete", "always...". Look on the bright side: at least the article isn't titled "best practices"...
- jbreckmckye 9y ago
  Or "curated".

davedx 9y ago

Yep, try/catch is optimized since node v8. The biggest takeaway from the latest batch of optimizations I read about is this: Write idiomatic JavaScript code! Secondly: Just because you're working with a dynamic language doesn't mean you should abuse it. Don't write functions with weirdly changing parameter arities, or dynamically change the types of variables. Finally: These things are all hints and micro-optimizations by themselves. Don't prematurely optimize at the cost of readability and maintenance. Profile and only fix things that need fixing!

metalshan 9y ago

Try/catch point is an in-general thing. Irrespective of language. Always better to handle errors by yourself. I was not aware of the browser deprecation of Shared array buffer. But this (or something like this) is a part of the ECMA proposal which is in stage 4. https://github.com/tc39/ecmascript_sharedmem https://github.com/tc39/ecmascript_sharedmem I said using forEach (or in-builts) are always a good practice. Now like you have to. For an example, if you have an array with no holes in it, for is better performant then forEach.

Klathmon 9y ago
>Always better to handle errors by yourself. I disagree, using try/catch/finally for their intended purpose (exceptional cases) is going to be preferable to trying to replicate their function on your own. Even if just from a semantic standpoint (is semantic the word i'm looking for here? it feels wrong...). >But this (or something like this) is a part of the ECMA proposal which is in stage 4. I really dislike the idea of true shared memory for the extreme vast majority of cases, and i'm not particularly happy about it's inclusion into browsers, so take what I say here with an appropriate amount of salt. I personally think spectre is only the first of many many problems it will bring if fully integrated. Transferable objects are a much cleaner and safer pattern to use in most cases, and they are here today in all major browsers. I do admit that having shared memory available is a massive bonus to some kinds of problems, but I feel the net impact will be negative. That being said, until a fix for spectre is either in hardware, or they find a way to solve it in software that doesn't destroy SharedArrayBuffer's performance, it's not coming back. And I don't see those happening within a few weeks/months in all honesty. >I said using forEach (or in-builts) are always a good practice. That was only one example of many in the article that I felt was making advice which works on one engine (v8), in a well-defined set of situations (sparse array, hot code paths, no async/await in the case of forEach), into a general truth. Not many things are universally true, and spelling out the when, why, and where you should apply this advice will go a long way toward teaching others rather than just giving people a list that they can haphazardly apply. Like your advice to avoid for...in. If you are iterating over enumerable properties, there is no reason to avoid it. It's slow, because that operation is slow, and most attempts to do it yourself more quickly will either fail, or will have edge cases that may introduce bugs. It's good advice in hot-path code, but shouldn't be universally followed. Especially when the alternative to a few lines of well-understood code is a mess of if statements, key lookups, and undefined/null checks.
mschuetz 9y ago
I find "for of" to be much more legible than "forEach". Not much difference in general but the "for" the beginning immediately tells me that there is a loop here, whereas I have to read more thoroughly to identify something as a loop in the forEach case. // for ... of for(let node of nodes){ console.log(node); } // forEach nodes.forEach(node => { console.log(node); });
- Klathmon 9y ago
  For...of is fantastic and I use it quite often (especially in async/await codebases as it doesn't create a new function context!) However it is slow currently in all major browser engines. For fast-path code, you should reach for something else (like a for(;;) loop), but for most other loops I always tend to reach for for...of for it's ease of use and compatibility with iterators makes it a pleasure to use!
  - mschuetz 9y ago
    Are you sure about that? "for of" is something that I'd expect a js compiler to handle exactly the same way as forEach. I'd see how it might have been slower right when it came out but browser vendors are quick in optimizing their compilers. At least https://jsperf.com/for-vs-foreach/293 https://jsperf.com/for-vs-foreach/293 shows that there is no significant difference in for of vs forEach in my version of chrome. There is an insignificant difference acoording to which forEach is actually slower. (One forEach case in that benchmark is only faster because it does something different.) Edit: looking at the comparison at the bottom, it seems like forEach is actually significant slower than for of since chrome 61.
    - Klathmon 9y ago
      Ya know what I'm not as sure as i thought I was. I'm really glad that for...of isn't nearly as slow as it was when it was first profiled it. Thanks for that!
    - olliej 9y ago
      Lots of work went into making the perf of for(of) fast - after the initial “make it semantically correct” bits. There are many reasons it is faster, but it also has the nice property of working sensibly on any iterable object rather than forEach that only iterates by index, and has an annoying ‘if (index in object)’ in the loop.
adrianN 9y ago
In Python try..except is very idiomatic.
- jakelazaroff 9y ago
  I wish JavaScript had Python's exception handling. There's no real way in JavaScript to catch only exceptions you're expecting, other than checking the error manually and re-throwing if it doesn't match.
theandrewbailey 9y ago
> For an example, if you have an array with no holes in it, for is better performant then forEach. Do you mean it's faster? (Don't use performant: use fast or faster instead.)
- mercer 9y ago
  I might be wrong, but 'faster' strikes me as a more ambiguous word. In this context it would be clear, but I can see how consistently using performant would help in clarifying what this 'faster' you're talking about is.

userbinator 9y ago

Also, I dislike this article because it recommends these things "always". "Always use forEach", "always avoid delete", "always...". Look on the bright side: at least the article isn't titled "best practices"...

jbreckmckye 9y ago
Or "curated".