What's with the "accept" only button for cookies on this website. If you drill down through the cookies link it explains in over verbose detail how you can disable tracking for individual cookies and each cookie has a unique disabling strategy even down to a suggestion to install some plugin. This is certainly not in line with EU rules on cookie banners.
There's so many ways this benchmark can go wrong that there's pretty much no way I can trust this conclusion.
> All the loops call a dummy function DATA.doSomethingWithValue() for each array element to make sure V8 doesn't optimize out something too much.
This is probably the most worrying comment - what is "too much?" How are you sure it doesn't change between different implementations? Are you sure v8 doesn't do anything you don't expect? If you don't look into what's actually happening in the engine, you have no idea at this point. Either you do the real work and measure that, or do the fake work but verify that the engine does what you think it does.
There are a lot of "probably"s in the article. I was also suspicious that the author didn't say they did any pre measurement runs of the code to ensure that it was warmed up first. Nor did they e.g. use V8 arguments with Node (like --trace-opt) to check what was actually happening.
Firefox is optimized against speedometer and similar "real world" benchmarks. This is a list of highly artificial benchmarks. Mozilla could attempt to optimize it for these benchmarks, but it wouldn't do much to make the web browsing experience better.
+1 on this... the spend outside of development is kind of fascinating as a while IMO. That they let Thunderbird languish for so long, they pretty much nuked XULRunner, and a bunch of pretty cool tech along the way.
You probably still don't want to risk it in a tight loop. Relying on those optimizations may not be the most reliable choice when you think about all the different JS engines, platforms, system load, operating systems...
I tested Firefox, Safari and Brave on macOS. Results are totally different for each. "for loop, positive" seems to be the only safe bet. Safari was very slow on everything, Brave and Firefox were slow on `for … of`.
I'm surprised by the huge variance. Can these results be trusted?
The way the array is constructed at least leads to holey arrays in V8. Perhaps similar in other implementations. The performance characteristics between different array types may vary significantly as well. Still, the traditional for loop, counting upwards seems to be fastest for me across Chrome and Firefox on Linux. For-of is slowest by a wide margin.
There is always going to be a big gap between a browser that had a particular optimization, and one where it is absent.
But, browsers are an odd case where optimizations often prove not to be worth it on real world websites. The cost to optimize can easily exceed the savings.
I know. Which is why I completely got rid of airbnb rules in my personal projects or projects that I control. I wasted so much time fighting those stupid rules instead of actually writing code.
The AirBNB JS style guide is kind of like a relic in time from the transition to ES6 etc. Leave it in the past. Their only argument for not supporting eg. "for-of" is because of "legacy" browsers not supporting it. Maybe a salient argument at the time of writing (these issue threads are nearly 10 years ago), but certainly not today.
It’s mostly the argument of a single guy (ljharb), who has very strong and weird opinions.
There were several extremely long and unproductive GitHub discussion with him posted to HN before, where he sent unsolicited and unwanted PRs to lots of projects that tanked performance by orders of magnitude and introduced tens of dependencies (he wrote himself), to ensure that projects would be backwards compatible with completely irrelevant targets they never supported in the first place (like Internet Explorer 1.3 under Windows 95 or something along those lines).
When projects did not want to take these contributions, he played his TC39 authority card, and when that did not help became more and more incoherent in his ramblings.
My take is that this guy actually wants to and thinks he is doing good, while actually having lost the plot a while ago.
> Their only argument for not supporting eg. "for-of" is because of "legacy" browsers not supporting it.
Not really, their rational is written in the document I linked --
Why? This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side effects.
// bad
let sum = 0;
for (let num of numbers) {
sum += num;
}
sum === 15;
// good
let sum = 0;
numbers.forEach((num) => {
sum += num;
});
sum === 15;
Which is... ridiculous. None of this is actually immutable, as "sum" is constantly being modified. A real FP purist would be using "reduce" in the "good" example. Otherwise, forEach is not better than for-of in terms of readability or maintainability in any way.
In addition, I think an issue is that for a long time, when you use ESLint CLI to create a new config file, airbnb is the default option, which ends up making it used very widely, even after the config itself is in maintenance mode. They were only removed in 2024: https://github.com/eslint/create-config/pull/108
Their rationale is written here, May 21 2021 final comment on the closed issue from the creator themself. Even in 2021 this was a dubious argument to make given the browser landscape, and they are clearly just frustrated to be challenged on this topic. They think legacy browsers are forever and furthermore readability of .forEach() is better anyway:
> in the latest version of all browsers. Despite marketing, no browsers are "evergreen" according to the google analytics of major websites I've been able to review over the last couple years. (Nothing but safari will likely ever support PTC - which is not an optimization - so that's not really relevant to discuss) Performance isn't important, readability is.
In the specific example, both have side effects... if you really wanted to avoid them, you'd use .reduce, and even then, depends on the amount of data. More often than not, if you're doing these kinds of things in JS on in-memory data, you're probably doing something wrong and have bigger concerns imo.
I say this as someone who loves JS since before The Good Parts book.
There's lots of little annoyances like this, but I just gave up and accepted it. I think this kind of highlights what is actually right about it: it lets everyone move past discussing such details in perpetuity.
> lets everyone move past discussing such details in perpetuity
That's definitely a reasonable attitude towards coding standards generally. However, in this case, there are "better" eslint rules out there that flags real, serious issues but still allows you to be productive, which is what I end up using.
AirBnB doesn't use this config and you probably shouldn't either. Much of this was based on Jordan Harband's opinions in 2016. He's likely changed his mind since then. Perhaps not. But I bet he'd tell you to do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter.
> do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter
Too bad ESLint has been recommending airbnb as the style until 2024. You can't expect everyone to start with nothing and hand pick every rule themselves. Doable for a large organization, not possible for a personal project.
Airbnb doesn't really follow that guide internally anymore. There's a lot of weird in there. I wish they'd publish the actual internal style and lint rules instead.
Is anyone really dealing with this much data in-memory in JS? I'm just curious, as I've been at this for about 30 years now, and the only times I've dealt with this much data, it's mostly been in streaming/etl type work, where you aren't using it all in-memory at once.
Personally, I like the for-of syntax as well as for-await-of... I kind of wish there was a promise-based version of forEach, as sometimes this syntax sits better, though I'm more inclined to use map, find, etc. over forEach. If I'm not using the indexer value, then there's not much point in using arr[i] over the for-of.
Also, in practice, I've RARELY found the need to optimize how JS is used outside refactoring a recursive algorithm when there's risk of a stack overflow.
Increasingly yes. A modern browser on a good laptop can crunch on GBs of data in a browser tab at once. This makes all sorts of data analysis and visualization tasks feasible in a client-side web app where previously you would have needed a detected database server somewhere.
Take a look at the https://kepler.gl/ demos to see quite how sophisticated this stuff can get now - millions of geospatial data points rendered entirely clientside via WebGL.
Thanks... the vast majority of my own experience has been a combination of line of business, banking, security and govt applications outside of scientific heavy circles, so was a genuine question, despite the downvotes.
The author here, I ran another test here https://jsben.ch/QCXCY . https://jsbenchmark.com/ seems to have issues with longer running code.
1500 repeats, for me for-of is now on par with classic for. As I said, for-of loops are not optimized as easily and reliably because v8 has to prove certain things to be able to do so. For-of's default is iterator protocol, and its more sensitive to deoptimization.
100% / 92% / ~32% (forget exactly on this one) for for-of, classic, forEach for me, on a Ryzen 5700 AMD desktop. Other things running, not a fantastic test, but I did turn the cooling system up ahead of running. This defied my expectations & I had to try & see!
Side note, I am fantastically glad to see at least some kind of online javascript benchmarking site is alive again. https://jsperf.com was so good to us for so many years. Obviously there's flaws but the way that it not just was a benchmark site but also would record folks results & aggregate them was incredibly incredibly incredibly fantastically sweet.
Got similar results but then tested on an older win10 i5 system (8+ years old?) chrome 145 and get variable results but classic is always about twice foreach or forof and foreach often performs 2x better than forof. I fear this might be more connected to CPUs than anything.
Weird. If V8 produces different optimized codes for different loops, this might be true on some CPUs. But when I get 100% convergence when increasing the repeats, this becomes a bit suspicious. Also, it might be some timing difference related to initial warmup or some adjustments in V8 for specific CPUs (including some power saving). I also ran on Pixel 3a , both classic and for-of were 100%, foreach was ~9% (on Windows 11 and AMD Ryzen 5000U was the same, except foreach was 62.96%).
I created another benchmark https://jsben.ch/sdaEM . The difference is that doSomethingWithValue now assigns the passed value to some variable. I think the optimizer could still notice that the function was dummy and do weird things, but not sure 100%. So I store in a variable to prevent this. Now the tests run slower, but still both classic and for-of tend to be 100%. forEach is sometimes slower, sometimes on par with the other 2 (on both AMD Ryzen 5000U Laptop and Pixel 3a).
Could you please run this test on your mentioned machine? Also could you gradually increase the number of repeats in each test case and see if there is some convergence? Also make sure the tab and the browser window are active during the benchmark. Otherwise the browser / OS might give less priority to the task. And BTW, can you also test on Chrome 143 and even Chrome 144 (it will be released tomorrow)?
And it's still worse, and has to rely on contrived setups to almost reach parity. People will insist on using a new language construct, even if it's objectively worse than the standard. What's so hard about a conventional for (let i ...) loop?
At least for of is better than forEach (ill never forgive crockford for goading people into this functional-lite code with horrible runtime footprint), but these things are fetishes.
This was added to the language 10 years ago. So while it's "newer" than a plain old for-loop, it's definitely not "new". It was designed to work with Symbol.iterator. This is the mechanism whereby one can iterate anything that implements the Symbol.iterator interface.
As far as why folks won't just do simple for-loops, it's the same reasining every language tends to implement a "foreach", because there are annoying off-by-one errors lurking in the < vs <=. Of course one could argue that developers should be smart enough to handle this. But that's an argument even older than for-loops.
These barely if ever happen for simple iterations, it's an idee fixe. Off-by-one sneak in when trying to do something special, and then a for-on loop is useless anyway.
> Symbol.iterator interface
I get it, but it's unnecessary abstraction to overgeneralize a vanilla array to an iterable.
anyway, for..of is not an issue, it's alright. I think if there's one main point i'm trying to make, is that devs will write objectively worse code base on gut wants (in this case, obsession to use higer level abstractions to iterate over an array).
I almost always try to cap my API results to 10001 items, so it's known if there's "more", depending on the interface(s) used. And when there are more, there's usually other pattern problems with the UX that I'm just kicking a can down the road on at that point.
Even then, far less than an amount one needs to be concerned of, for "performance"
> This site uses cookies. By continuing to use this website, you agree to their use.
Careful, you are in violation of the GDPR. You can’t simply say “I’m going to set non-essential advertising cookies, deal with it or get out” (I checked your policy to confirm you are using non-essential cookies), you can’t set any cookies until the user agrees, and have to provide a way to reject them that is at least as simple as the way to accept.
In fairness, at least this way it allows you to make an informed choice to leave immediately if you so wish, thus avoiding leaving more behavioural data or the like. The banner is not compliant, but it is better than doing it silently.
If they didn’t care about those laws, they wouldn’t need the notice. Since they do, they do.
Why are you even mad? This doesn’t affect you, it is not directed at you, and is trying to be a helpful clarification to the author. If they care about compliance, presumably they care about doing it right.
> Despite what many EU citizens may think, EU laws don't apply to the world.
I’m a EU citizen living in the EU and have never encountered or heard of anyone with that belief.
> The GDPR applies to:
> a company or entity which [...]; or
> a company established outside the EU and is offering goods/services (paid or for free) or is monitoring the behaviour of individuals in the EU.
Now imagine running a forum or any other service from outside of the EU, on the open web. Does the EU think GDPR applies to you?
All that means is that if you operate in the EU, you must follow EU rules. Which isn’t weird at all, it’s perfectly normal that if you wish to operate in one place, you follow the rules of the place. You are free to not operate in that place and not follow the rules.
In other words, that doesn’t mean “EU laws apply to the world”, it means “EU laws apply to whoever operates in the EU”.
Multi-billion dollar companies have GDPR-violating cookie banners, and nobody cares.
In the case of blogs like this, they don't really care about compliance, it's just LARPing. "Serious websites have cookie banners, so I'll put a cookie banner too!" It's the same as putting "no copyright infringement intended" into your YouTube video description.
> Multi-billion dollar companies have GDPR-violating cookie banners, and nobody cares.
Not true. In fact, those banners are in general way more compliant than before due to the work of organisations like https://noyb.eu/. They have also successfully led numerous initiatives to fine those companies and fix non-compliance.
Usually at this point is when someone comes along to move the goalpost to “but those aren’t very affective”, or “but they still do it”. Sure, argue against malicious compliance and results all you want, I’m simply pointing out that it’s not true at all that “nobody cares”. Enough people care enough that entire organisations exist with that mission.
> In the case of blogs like this, they don't really care about compliance, it's just LARPing.
Maybe. If they don’t care, they can simply ignore my advice. If they do care, they can follow it. Either way, there is no situation in which my sharing of the law is negative.
What's with the "accept" only button for cookies on this website. If you drill down through the cookies link it explains in over verbose detail how you can disable tracking for individual cookies and each cookie has a unique disabling strategy even down to a suggestion to install some plugin. This is certainly not in line with EU rules on cookie banners.
lol and the first time you click the theme change button it goes through a series of tracking redirects ending in some crypto app (at least on mobile)
I didn’t believe this so I tried it. It’s true. Wild.
So it's ads masquerading as cookie consent?
There's so many ways this benchmark can go wrong that there's pretty much no way I can trust this conclusion.
> All the loops call a dummy function DATA.doSomethingWithValue() for each array element to make sure V8 doesn't optimize out something too much.
This is probably the most worrying comment - what is "too much?" How are you sure it doesn't change between different implementations? Are you sure v8 doesn't do anything you don't expect? If you don't look into what's actually happening in the engine, you have no idea at this point. Either you do the real work and measure that, or do the fake work but verify that the engine does what you think it does.
There are a lot of "probably"s in the article. I was also suspicious that the author didn't say they did any pre measurement runs of the code to ensure that it was warmed up first. Nor did they e.g. use V8 arguments with Node (like --trace-opt) to check what was actually happening.
u can compile to v8 turbofan final bytecode and use ai to analyze and compare the instructions.
Only until you work with a type array (Int32Array, Float64Array, etc), then it becomes 10x slower: https://jsperf.app/doyeka/11
A better point would be V8 execution of JavaScript's for-of loops is fast.
We should not make assertions based on a language name, when there are so many implementations to chose from, https://zoo.js.org/
Spider monkey being under 24k while v8 and JavaScript Core kiss 60k is alarming. Why are we so far behind?
Firefox is optimized against speedometer and similar "real world" benchmarks. This is a list of highly artificial benchmarks. Mozilla could attempt to optimize it for these benchmarks, but it wouldn't do much to make the web browsing experience better.
Basically lack of human resources to make it great, note that Firefox is already around 3% market share, and Mozilla keeps having other priorities.
Mozilla has their priorities ass backwards and does anything except what prople actually want: developing Firefox.
+1 on this... the spend outside of development is kind of fascinating as a while IMO. That they let Thunderbird languish for so long, they pretty much nuked XULRunner, and a bunch of pretty cool tech along the way.
No wonder my Firefox feels sluggish compared to Chrome on M3. Sigh.
Thanks, that's a good picture and history of JS engines.
It’s like the “…in mice” trope for medical study headlines, but with “…in V8” instead.
> to make sure V8 doesn't optimize out something too much
A bit more explanation of “something” and ”too much“ would have been educational
For-of loops are fast enough, most of the time.
You probably still don't want to risk it in a tight loop. Relying on those optimizations may not be the most reliable choice when you think about all the different JS engines, platforms, system load, operating systems...
The old and famous jsperf.com is available under .app again. Here is a for/while comparison f.ex.: https://jsperf.app/doyeka/5
I tested Firefox, Safari and Brave on macOS. Results are totally different for each. "for loop, positive" seems to be the only safe bet. Safari was very slow on everything, Brave and Firefox were slow on `for … of`.
I'm surprised by the huge variance. Can these results be trusted?
The way the array is constructed at least leads to holey arrays in V8. Perhaps similar in other implementations. The performance characteristics between different array types may vary significantly as well. Still, the traditional for loop, counting upwards seems to be fastest for me across Chrome and Firefox on Linux. For-of is slowest by a wide margin.
There is always going to be a big gap between a browser that had a particular optimization, and one where it is absent.
But, browsers are an odd case where optimizations often prove not to be worth it on real world websites. The cost to optimize can easily exceed the savings.
On Safari are results were within 3% of each other. On Brave "for loop, negative" was 84% faster than "for of".
This small sample (2 browsers on macOS) align with my expectations of "Good luck optimizing JavaScript that has dozen of different implementations".
Funny enough, for-of is not allowed in Airbnb eslint config, and you are expected to use forEach instead:
https://github.com/airbnb/javascript/issues/1122
https://github.com/airbnb/javascript/issues/1271
Because the style guide thinks "forEach is cleaner than for-of". (No I did not make that up.)
https://github.com/airbnb/javascript?tab=readme-ov-file#iter...
No way this is not a satire.
https://github.com/airbnb/javascript/issues/1122#issuecommen...
https://github.com/airbnb/javascript/issues/1122#issuecommen...
They don't seem to like generators either, which is even stranger. Why block the usage of features which might be useful in some cases?
I know. Which is why I completely got rid of airbnb rules in my personal projects or projects that I control. I wasted so much time fighting those stupid rules instead of actually writing code.
i have pretty strict rules for the code bases at work and one is to use for..of
The AirBNB JS style guide is kind of like a relic in time from the transition to ES6 etc. Leave it in the past. Their only argument for not supporting eg. "for-of" is because of "legacy" browsers not supporting it. Maybe a salient argument at the time of writing (these issue threads are nearly 10 years ago), but certainly not today.
It’s mostly the argument of a single guy (ljharb), who has very strong and weird opinions.
There were several extremely long and unproductive GitHub discussion with him posted to HN before, where he sent unsolicited and unwanted PRs to lots of projects that tanked performance by orders of magnitude and introduced tens of dependencies (he wrote himself), to ensure that projects would be backwards compatible with completely irrelevant targets they never supported in the first place (like Internet Explorer 1.3 under Windows 95 or something along those lines).
When projects did not want to take these contributions, he played his TC39 authority card, and when that did not help became more and more incoherent in his ramblings.
My take is that this guy actually wants to and thinks he is doing good, while actually having lost the plot a while ago.
very interesting thread
i used to be like ljharb, changing company/stack made me live in python for loops but then i miss composable operators ..
> Their only argument for not supporting eg. "for-of" is because of "legacy" browsers not supporting it.
Not really, their rational is written in the document I linked --
Which is... ridiculous. None of this is actually immutable, as "sum" is constantly being modified. A real FP purist would be using "reduce" in the "good" example. Otherwise, forEach is not better than for-of in terms of readability or maintainability in any way.In addition, I think an issue is that for a long time, when you use ESLint CLI to create a new config file, airbnb is the default option, which ends up making it used very widely, even after the config itself is in maintenance mode. They were only removed in 2024: https://github.com/eslint/create-config/pull/108
Their rationale is written here, May 21 2021 final comment on the closed issue from the creator themself. Even in 2021 this was a dubious argument to make given the browser landscape, and they are clearly just frustrated to be challenged on this topic. They think legacy browsers are forever and furthermore readability of .forEach() is better anyway:
> in the latest version of all browsers. Despite marketing, no browsers are "evergreen" according to the google analytics of major websites I've been able to review over the last couple years. (Nothing but safari will likely ever support PTC - which is not an optimization - so that's not really relevant to discuss) Performance isn't important, readability is.
ref: https://github.com/airbnb/javascript/issues/1122#issuecommen...
In the specific example, both have side effects... if you really wanted to avoid them, you'd use .reduce, and even then, depends on the amount of data. More often than not, if you're doing these kinds of things in JS on in-memory data, you're probably doing something wrong and have bigger concerns imo.
I say this as someone who loves JS since before The Good Parts book.
There's lots of little annoyances like this, but I just gave up and accepted it. I think this kind of highlights what is actually right about it: it lets everyone move past discussing such details in perpetuity.
> I just gave up and accepted it
> lets everyone move past discussing such details in perpetuity
That's definitely a reasonable attitude towards coding standards generally. However, in this case, there are "better" eslint rules out there that flags real, serious issues but still allows you to be productive, which is what I end up using.
AirBnB doesn't use this config and you probably shouldn't either. Much of this was based on Jordan Harband's opinions in 2016. He's likely changed his mind since then. Perhaps not. But I bet he'd tell you to do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter.
> do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter
Too bad ESLint has been recommending airbnb as the style until 2024. You can't expect everyone to start with nothing and hand pick every rule themselves. Doable for a large organization, not possible for a personal project.
https://github.com/eslint/create-config/pull/108
Airbnb doesn't really follow that guide internally anymore. There's a lot of weird in there. I wish they'd publish the actual internal style and lint rules instead.
That's the biggest one that turned me off of their entire rule set... IIRC similar for for-await-of iirc.
Is anyone really dealing with this much data in-memory in JS? I'm just curious, as I've been at this for about 30 years now, and the only times I've dealt with this much data, it's mostly been in streaming/etl type work, where you aren't using it all in-memory at once.
Personally, I like the for-of syntax as well as for-await-of... I kind of wish there was a promise-based version of forEach, as sometimes this syntax sits better, though I'm more inclined to use map, find, etc. over forEach. If I'm not using the indexer value, then there's not much point in using arr[i] over the for-of.
Also, in practice, I've RARELY found the need to optimize how JS is used outside refactoring a recursive algorithm when there's risk of a stack overflow.
Increasingly yes. A modern browser on a good laptop can crunch on GBs of data in a browser tab at once. This makes all sorts of data analysis and visualization tasks feasible in a client-side web app where previously you would have needed a detected database server somewhere.
Take a look at the https://kepler.gl/ demos to see quite how sophisticated this stuff can get now - millions of geospatial data points rendered entirely clientside via WebGL.
Thanks... the vast majority of my own experience has been a combination of line of business, banking, security and govt applications outside of scientific heavy circles, so was a genuine question, despite the downvotes.
But still just 85% of a conventional cached loop (34 vs 40 ops/s per the last test).
The author here, I ran another test here https://jsben.ch/QCXCY . https://jsbenchmark.com/ seems to have issues with longer running code. 1500 repeats, for me for-of is now on par with classic for. As I said, for-of loops are not optimized as easily and reliably because v8 has to prove certain things to be able to do so. For-of's default is iterator protocol, and its more sensitive to deoptimization.
100% / 92% / ~32% (forget exactly on this one) for for-of, classic, forEach for me, on a Ryzen 5700 AMD desktop. Other things running, not a fantastic test, but I did turn the cooling system up ahead of running. This defied my expectations & I had to try & see!
Side note, I am fantastically glad to see at least some kind of online javascript benchmarking site is alive again. https://jsperf.com was so good to us for so many years. Obviously there's flaws but the way that it not just was a benchmark site but also would record folks results & aggregate them was incredibly incredibly incredibly fantastically sweet.
Got similar results but then tested on an older win10 i5 system (8+ years old?) chrome 145 and get variable results but classic is always about twice foreach or forof and foreach often performs 2x better than forof. I fear this might be more connected to CPUs than anything.
Weird. If V8 produces different optimized codes for different loops, this might be true on some CPUs. But when I get 100% convergence when increasing the repeats, this becomes a bit suspicious. Also, it might be some timing difference related to initial warmup or some adjustments in V8 for specific CPUs (including some power saving). I also ran on Pixel 3a , both classic and for-of were 100%, foreach was ~9% (on Windows 11 and AMD Ryzen 5000U was the same, except foreach was 62.96%).
I created another benchmark https://jsben.ch/sdaEM . The difference is that doSomethingWithValue now assigns the passed value to some variable. I think the optimizer could still notice that the function was dummy and do weird things, but not sure 100%. So I store in a variable to prevent this. Now the tests run slower, but still both classic and for-of tend to be 100%. forEach is sometimes slower, sometimes on par with the other 2 (on both AMD Ryzen 5000U Laptop and Pixel 3a).
Could you please run this test on your mentioned machine? Also could you gradually increase the number of repeats in each test case and see if there is some convergence? Also make sure the tab and the browser window are active during the benchmark. Otherwise the browser / OS might give less priority to the task. And BTW, can you also test on Chrome 143 and even Chrome 144 (it will be released tomorrow)?
OP forgot to mention that speed is relative ;)
And it's still worse, and has to rely on contrived setups to almost reach parity. People will insist on using a new language construct, even if it's objectively worse than the standard. What's so hard about a conventional for (let i ...) loop?
At least for of is better than forEach (ill never forgive crockford for goading people into this functional-lite code with horrible runtime footprint), but these things are fetishes.
>new language construct
This was added to the language 10 years ago. So while it's "newer" than a plain old for-loop, it's definitely not "new". It was designed to work with Symbol.iterator. This is the mechanism whereby one can iterate anything that implements the Symbol.iterator interface.
As far as why folks won't just do simple for-loops, it's the same reasining every language tends to implement a "foreach", because there are annoying off-by-one errors lurking in the < vs <=. Of course one could argue that developers should be smart enough to handle this. But that's an argument even older than for-loops.
> here are annoying off-by-one errors
These barely if ever happen for simple iterations, it's an idee fixe. Off-by-one sneak in when trying to do something special, and then a for-on loop is useless anyway.
> Symbol.iterator interface
I get it, but it's unnecessary abstraction to overgeneralize a vanilla array to an iterable.
anyway, for..of is not an issue, it's alright. I think if there's one main point i'm trying to make, is that devs will write objectively worse code base on gut wants (in this case, obsession to use higer level abstractions to iterate over an array).
Items you loop are 99% under 1000 items.
I almost always try to cap my API results to 10001 items, so it's known if there's "more", depending on the interface(s) used. And when there are more, there's usually other pattern problems with the UX that I'm just kicking a can down the road on at that point.
Even then, far less than an amount one needs to be concerned of, for "performance"
> This site uses cookies. By continuing to use this website, you agree to their use.
Careful, you are in violation of the GDPR. You can’t simply say “I’m going to set non-essential advertising cookies, deal with it or get out” (I checked your policy to confirm you are using non-essential cookies), you can’t set any cookies until the user agrees, and have to provide a way to reject them that is at least as simple as the way to accept.
The site might as well just silently use cookies and save the banner if it's going to ignore GDPR or EU anyway.
In fairness, at least this way it allows you to make an informed choice to leave immediately if you so wish, thus avoiding leaving more behavioural data or the like. The banner is not compliant, but it is better than doing it silently.
Meh... not sure if Armenia is part of the EU or not. At least there's some notification.
It's a personal blog of someone living in Armenia. What's the EU going to do?
Despite what many EU citizens may think, EU laws don't apply to the world.
Just wait
https://en.wikipedia.org/wiki/Accession_of_Armenia_to_the_Eu...
If they didn’t care about those laws, they wouldn’t need the notice. Since they do, they do.
Why are you even mad? This doesn’t affect you, it is not directed at you, and is trying to be a helpful clarification to the author. If they care about compliance, presumably they care about doing it right.
> Despite what many EU citizens may think, EU laws don't apply to the world.
I’m a EU citizen living in the EU and have never encountered or heard of anyone with that belief.
> I’m a EU citizen living in the EU and have never encountered or heard of anyone with that belief.
See 4chan vs OSA.
EU is similarly trying to legislate for the world, and it will work until someone calls on their bluff.
I'm in EU most of the time and like most benefits of GDPR (right to access and delete? Great!) But sometimes they overplay their hand.
> See 4chan vs OSA.
OSA is a UK legislation. The UK is not in the EU.
> EU is similarly trying to legislate for the world, and it will work until someone calls on their bluff.
That’s an opinion. The Brussels Effect is real, but that’s not the same as “many EU citizens think EU laws apply to the world”.
Is it an opinion?
And try to check EU GDPR territoriality and tell me whether you're of a different opinion:
https://commission.europa.eu/law/law-topic/data-protection/r...
> The GDPR applies to: > a company or entity which [...]; or > a company established outside the EU and is offering goods/services (paid or for free) or is monitoring the behaviour of individuals in the EU.
Now imagine running a forum or any other service from outside of the EU, on the open web. Does the EU think GDPR applies to you?
All that means is that if you operate in the EU, you must follow EU rules. Which isn’t weird at all, it’s perfectly normal that if you wish to operate in one place, you follow the rules of the place. You are free to not operate in that place and not follow the rules.
In other words, that doesn’t mean “EU laws apply to the world”, it means “EU laws apply to whoever operates in the EU”.
> EU is similarly trying to legislate for the world, and it will work until someone calls on their bluff.
Any source for that?
GDPR only applies to companies having a branch in the EU or offering services targeted at EU citizens: https://commission.europa.eu/law/law-topic/data-protection/r...
You might have missed the second branch of that "or":
> a company established outside the EU and is offering goods/services (paid or for free) or is monitoring the behaviour of individuals in the EU.
If you serve traffic to the EU (like any website on the open web as originally intended) you fall into that.
Multi-billion dollar companies have GDPR-violating cookie banners, and nobody cares.
In the case of blogs like this, they don't really care about compliance, it's just LARPing. "Serious websites have cookie banners, so I'll put a cookie banner too!" It's the same as putting "no copyright infringement intended" into your YouTube video description.
> Multi-billion dollar companies have GDPR-violating cookie banners, and nobody cares.
Not true. In fact, those banners are in general way more compliant than before due to the work of organisations like https://noyb.eu/. They have also successfully led numerous initiatives to fine those companies and fix non-compliance.
Usually at this point is when someone comes along to move the goalpost to “but those aren’t very affective”, or “but they still do it”. Sure, argue against malicious compliance and results all you want, I’m simply pointing out that it’s not true at all that “nobody cares”. Enough people care enough that entire organisations exist with that mission.
> In the case of blogs like this, they don't really care about compliance, it's just LARPing.
Maybe. If they don’t care, they can simply ignore my advice. If they do care, they can follow it. Either way, there is no situation in which my sharing of the law is negative.
JesuS, so many different ways for looping in a language is insane. And Racket takes it to the next level...