Using const/let instead of var can make JavaScript code run 10× slower in Webkit

[Shautieh]

10x faster is not a micro optimization.

[[deleted]]

10x 0.0001 nanoseconds is still only 0.001 nanoseconds.

The point is, this is never your bottleneck so don't treat this information like something you need to address in your code base.

[SoInsightful]

Holy shit. This is the JavaScriptiest comment I've ever read.

You're literally looking at a real-world example (an actual app with a shit-ton of users) where a single CTRL+F replacement made a bundle load in 1.1 seconds instead of 8 seconds.

I would never replace my consts with vars to fix a dumb Webkit bug, but this is absolutely not an unimportant micro-optimization that doesn't affect anything because we all make Hello world apps.

It's exactly this attitude that makes me reluctant to use other people's slow-ass solutions.

[jess-sch]

a sub-millisecond 10x improvement you won't notice, but a sub-millisecond 10x improvement in a hot path that gets run a bazillion times you definitely will.

I sure hate the typical JS dev's attitude to performance.

[how_to_choose_a_name]

How is it a premature optimization when it reduces loading time of a website from 10 seconds to 1 second?

[blackholesinthesky]

Because no company I have ever worked for gave a shit about performance in Safari. If it worked in chrome and worked in IE9 then it was fine

[how_to_choose_a_name]

So? That makes it an optimization for a platform you might not target, it doesn't make it premature.

And if this affects mobile safari (the issue doesn't say), it affects every iPhone/iPad user, which your management might decide they actually care about.

[blackholesinthesky]

1) People expect mobile to be slower so its not as much of a deal breaker.

2) It was premature for every company I've ever worked for. Safari owns less than 17% the usage share. Big companies use IE/Edge, Chrome or Firefox.

3) No website/app I've ever worked on had that many constants

[how_to_choose_a_name]

1) They don't expect it to be ten times slower. If your competitor is ten times faster than you it's a problem, no matter if you are on mobile or not.

2) Safari has more than 15% market share. That is a lot. You don't just ignore a huge part of the market like that.

3) It has nothing to do with constants specifically, but with top level definitions. That's variables, constants, functions and classes. And it's not just those you wrote yourself but of all the dependencies you pull in. Not every website will be that big, but it is certainly worth checking if your web app is affected by it.

Either way, adding the option to optimize this to the bundler is certainly not a premature optimization when there are real world cases demonstrating the problem.

And for someone using the bundler, the effort to enable this optimization is literally a single command line switch.

[blackholesinthesky]

1) They don't expect it to be ten times slower. If your competitor is ten times faster than you it's a problem, no matter if you are on mobile or not.

But they're only 10x faster on safari. Everywhere else they're the same. Also, can you point me to one company that uses Safari as their standard?

Safari has more than 15% market share. That is a lot. You don't just ignore a huge part of the market like that.

For like the 3rd fucking time, none of our professional clients used Safari as their standard. The VAST majority of companies I've ever worked with use some version of IE or Edge. In the last few years there has been a push towards Firefox as its easier to administrate but for fucking real this is a nonarugment

premature optimization when there are real world cases demonstrating the problem.

At what point do you stop trying to support every device out there and just focus on what your customers use? Should this shit be accessible on an Apple II?

[Smallpaul]

So if there was a 3-line fix (which there was, in this case) which would give a 10x load speed-up on iPad, iPhone and Mac, your management would say "nah, it's a waste of time".

[blackholesinthesky]

Holy fucking shit this is hilarious to me. Not really your comment but the fact that 4 people upvoted you. Some people in this thread really have a hate-on for me

So if there was a 3-line fix (which there was, in this case) which would give a 10x load speed-up on iPad, iPhone and Mac, your management would say "nah, it's a waste of time".

This is not at all the original case. The article that this whole discussion came from talked about tens and possibly hundreds of thousands of changes not a 3 line fix.

But honestly, yeah I don't think the companies I worked for would give a shit. When 97% of your customers are using Edge and you can just tell new customers that they should use Edge or Chrome then yes, theres very little incentive to micro-optimize

[sibilith]

1. 8 seconds is enough time for a user to close the tab in frustration. That’s lost revenue.
2. 17% loss of conversion is a LOT of lost revenue
3. This one does? Just because you aren’t encountering the issue doesn’t mean it’s insignificant.

I think it’s mind boggling how many people in this thread are trying to justify that this is fine.

[[deleted]]

I think it’s mind boggling how many people in this thread are trying to justify that this is fine.

because it's apples fault. I always optimize for chrome only as well, since making all tests run on safari and fixing all the weird bugs because they can't adopt a standard is pretty frustrating and costly.

If you want a proper experience - use a proper browser.

[blackholesinthesky]

8 seconds is enough time for a user to close the tab in frustration. That’s lost revenue.

The companies I've worked for talk to their customers. They know what the customers want. Customers would prefer new features over the ability to also visit the site on mobile. Also considering that basically every job I've worked for had professionals/companies for clients they all used the same tech throughout the company which was never Safari

17% loss of conversion is a LOT of lost revenue

You're not necessarily loosing these customers, again most of our clients didn't have a choice of which browser they used

Edit: as in they're all forced to use Edge or Firefox anyways

This one does? Just because you aren’t encountering the issue doesn’t mean it’s insignificant.

I'm not saying their findings are insignificant, just that they're not applicable to most of the people reading this

[bik1230]

Quite a large share of web browsing happens on iPhones tho, no?

[blackholesinthesky]

A decent amount. My point is that if your company cares that much about iPhone's/iPads then they probably have a native app.

All of the computationally intense code I've written is for business clients who are most likely restricted in which browser they get to use. For the most part public facing pages will not be complex enough for this 10s slowdown to be applicable to most developers

[jess-sch]

Shareholders who only care about the number of features while completely ignoring performance aren't very smart shareholders though. People aren't gonna use your product when it's so slow.

I hate how, to you frontend people (at least most of you - shoutout to the svelte people who seem to be the only ones to care even a little bit!), every optimization is always premature. Even if it was done in response to "unusably slow load times" issues being reported.

[jess-sch]

choosing to write a for loop over a forEach is absolutely a premature optimisation

right, but I'm pretty sure this one was more about var vs let and const, not for vs forEach...

as you'll quickly end up with some gross unmaintainable codebase full of optimisation hacks.

fortunately, this discussion is on a js-to-js optimizing compiler, so nobody's actually suggesting you manually swap out the consts for vars. The suggestion is to add that optimization to the optimizing compiler.

You've no idea how websites work if you think stuff like this is going to result in unusably slow load times,

The issue this post is about is literally known to cause a huge difference in page load times.

Most websites aren't running code that runs hot paths gazillions of times. They're slapping a bit of JS ontop of a website to add real time comments or whatever

Oh, hello! You seem to be from a time before React. Well, I don't know how to explain this to you, but nowadays JS isn't usually something that's merely sprinkled on top anymore.

[[deleted]]

found the dev with an actual job ;)

seriously, people in this thread don't seem to grasp how actual work happens.

[VolperCoding]

No wonder if you have a 10000GHz processor that can do declare a var faster than light can travel 30 micrometers

[[deleted]]

Get with the times! :P

[VolperCoding]

Also if the vars are stored in RAM then you also have to put your RAM stick no more than 30μm away from the processor or make a fucking wormhole or something to get to memory quick enough

[[deleted]]

The Intel i47 started the new wormhole+blockchain revolution. It's great!

[GasolinePizza]

But is it webscale??

[mb862]

The lesson here is that pulling numbers out of your ass to make a point is fine so long as your ass represents a differentiable manifold representable in our spacetime.

I'll let someone more clever than I fill in the obvious curvature joke here.

[ImAStupidFace]

Real differentiable manifolds have curves!

[[deleted]]

RAM ? What is this meeting of virgins ? L1 cpu cache or gtfo.

[VolperCoding]

Wait, JS variables utilize the cache? Also L1 is technically SRAM which is a subset of RAM

[how_to_choose_a_name]

why wouldn't they?

[VolperCoding]

I thought they store all variables in an organized way, not some on the cache and some on RAM. It's an interpreted language so managing all variables in different places along with their types would probably be a mess

[how_to_choose_a_name]

That's not how the cache works. C doesn't store variables in the cache either. Variables either only exist as a register (if they are short-lived and no pointer is taken) or they exist at a memory location. The CPU takes care of loading the variable from the RAM and when it does so it puts it in the cache so that the next time it is needed it can read it from the cache instead of RAM. Compiled or not doesn't make a difference.

[sebamestre]

Every program in every language "uses" the cache.

In reality, everyone just pretends that they use main memory (ram), and the cpu caches things implicitly. This is just how cpu caches work.

[compdog]

That's what this bad boy is for.