Choosing implementation variants is straightforward if you adhere to a predefined criteria set.
I write about how to evaluate implementations on criteria here:
TLDR: Choose the fastest implementation considering equal robustness. dev.to/functional_js/squeezing-out...
In this case, the loop is many magnitudes faster. Use the loop.
//a.constisPalindrome_loop=str=>{consts=str.toLowerCase();for(leti=0;i<s.length/2;++i){if(s[i]!==s[s.length-1-i]){returnfalse;}}returntrue;};//b.constisPalindrome_spread=str=>{consts=str.toLowerCase();return[...s].reverse().join("")===s;};//@testsconstpalid="A man, a plan, a canal: Panama—!@#$#@%$$%^&&^*()=-_+,.<>/?";//a.timeInLoop("isPalindrome_loop",1e6,()=>isPalindrome_loop(palid));// isPalindrome_loop: 1e+6: 162.986ms//b.timeInLoop("isPalindrome_spread",1e6,()=>isPalindrome_spread(palid));//isPalindrome_spread: 1e+6: 5.494s
Very clear comparison of the actual performance of the two.
I do wonder though why declaring the actual functions as "function Name(arg) { ..." has fallen somewhat out of favor, it just seems such a more natural way to do it given how the English language works.
Then again in most other languages you'd typically see:
returnType FunctionName(args) {
or something similar to that
I don't understand why people still use the "function" keyword, unless you are accessing the "this" keyword, which should be never, except for legacy JavaScript.
Plus I would pick one consistent strategy and go with it, instead of intermingle, "sometimes arrow and sometimes function".
I also don't use single quotes. Everything double quotes.
Then there's none of this, "sometimes this, sometimes that" sprinkled all over the place.
I agree, consistency is key. Which is why on my projects there are always a set of coding guidelines that are enforced in terms of naming, spacing, comments, all that.
I do use the "this" keyword relatively frequently however myself, specifically from within member functions of an object, to access member data or other member functions.
Choosing implementation variants is straightforward if you adhere to a predefined criteria set.
I write about how to evaluate implementations on criteria here:
TLDR: Choose the fastest implementation considering equal robustness.
dev.to/functional_js/squeezing-out...
In this case, the loop is many magnitudes faster. Use the loop.
Very clear comparison of the actual performance of the two.
I do wonder though why declaring the actual functions as "function Name(arg) { ..." has fallen somewhat out of favor, it just seems such a more natural way to do it given how the English language works.
Then again in most other languages you'd typically see:
returnType FunctionName(args) {
or something similar to that
That's a good question, here's my answer to it:
I don't understand why people still use the "function" keyword, unless you are accessing the "this" keyword, which should be never, except for legacy JavaScript.
Plus I would pick one consistent strategy and go with it, instead of intermingle, "sometimes arrow and sometimes function".
I also don't use single quotes. Everything double quotes.
Then there's none of this, "sometimes this, sometimes that" sprinkled all over the place.
I'm a minimalist, and only use a subset of the language.
Here is a list of what I don't use in JavaScript:
dev.to/functional_js/what-subset-o...
Thanks for that response.
I agree, consistency is key. Which is why on my projects there are always a set of coding guidelines that are enforced in terms of naming, spacing, comments, all that.
I do use the "this" keyword relatively frequently however myself, specifically from within member functions of an object, to access member data or other member functions.
That's because of your Object-oriented approach to programming.
I use a functional approach, so everything in that list I linked to in my last post are unnecessary.
Without those constructs, there is almost nothing left but funcs themselves, specifically, arrow funcs.