DEV Community

JavaScript/Typescript Tips compilation 2021🚀

Kingkor Roy Tirtho on August 03, 2021

I'll be discussing the newest JavaScript/Typescript tips which also includes ES2020 additions & Typescript's new type related additions in this...

Read full post

Keff • Aug 4 '21 • Edited

I agree with the +, it should not be used that often, if ever.

But, it's not always about speed, I think he was just showing other less common methods, that are useful in some scenarios. Though I have tested and It's quite a lot slower, around 27%. Benchmark here

Though this post was not about performance, I think it's always good to advise people.

Stephen Rayner • Aug 4 '21

You mean advise* people. Thank you dot the feedback

zulvkr • Aug 5 '21 • Edited

I'm still on the edge of converting to parseInt parseFloat sect. But their behavior to convert '23 somestring' to 23 still off putting to me.

Looks like a possible silent failure for edge cases

Edit: I found an actual case, bennadel.com/blog/3803-i-prefer-th...

I am not saying + is better overall, but it has better behavior in this case

Kingkor Roy Tirtho • Aug 5 '21

I've updated the post to point out the potential problems that can occur for using + instead of parseInt/parseFloat. Also mentioned the performance penalty for for_of loop with Array.entries so that everyone stays informed...

Thanks to all of you, who've corrected this out. You guys rock💪

Kingkor Roy Tirtho • Aug 4 '21

Yeah, I saw the difference. for_of is almost 20%-30% slower than forEach. It makes sense as Array.entries has to take an iteration to map out the index. I wonder why there's no native way of getting the index in for_of without a performance penalty🤔! for_of is so much more readable & mitigates the callback hell at least a little bit

Also I wouldn't really recommend anyone to use + instead of perseInt or parseFloat. Just mentioned as it is also doable too

Thank you so much for your corrections❤️

James Thomson • Aug 4 '21

If you wanted an index to reference, but want to use for...of you'd be better off (performance wise) using a variable to track it.

const array1 = ['a', 'b', 'c']; let i = 0; for (const element of array1) { console.log(element,i); i++; }

zulvkr • Aug 4 '21

A counter argument.

I feel + for number conversion is extremely common in JS and readable. The behavior meets expectation well, it can be float or integer when I don't care.

It looks intentful, since everyone know JS type coercion.

I will give code a pass.

sesay • Aug 6 '21

not sure, why i would do this

```const moods = ['good', 'better', 'best']

for ([idx, mood] of moods.entries()) {
console.log(${index}. ${mood})
}```

In my opinion looks a little bit more complicated

Keff • Aug 4 '21

That's true, I can agree with that. The example was a weird use-case, but entries has some uses though.

Funny, on my test benchmark I realized that a regular for is slower than forEach in that particular example, wich surprised me a bit. I'm guessing the engine is doing some optimization, which are not done for regular fors...

Randall • Aug 4 '21 • Edited

I agree, + to convert something to a number is a hack. It also converts empty string to 0, which can lead to bugs. Better to use Number.parseInt() (or parseFloat) and then do a NaN check.

Joseph Odunsi • Aug 4 '21

That optional function call. Thank you

Kingkor Roy Tirtho • Aug 4 '21

Ah, that one really made me amazed when I found it accidentally while optionally chaining objects where one of the property was actually a method😅

James Thomson • Aug 5 '21

For sure! Not much point in using for...of in this use case when a for will do just fine, but I'd also never do a for...of with arr.entries() so there's that too 😂

Demeno • Aug 4 '21

It always bothered me that the override keyword wasn't required, I'm definitely adding this noImplicitOverride: true setting to our project now that I know it exists.