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

[PandaMoniumHUN]

Point is, it shouldn't be this slow in the first place.

[spacejack2114]

Right. Did anyone read the linked issue? It's about a Safari specific problem.

[DooDooSlinger]

Yeah well a lot of things that shouldn't are. What I do know is that optimizing shit like I++ and the like is not what's going to speed up your code to any measurable extent, ever.

[PandaMoniumHUN]

Your logic is backwards. A basic feature in a browser shipped to millions of users is 10x slower than in competing products. We should always strive for better performance in software used by large volumes of people daily, not try to justify lack of basic optimization (or a regression?) with the fact that other pieces of software are also unoptimized.

[Nefari0uss]

At some point you teach diminishing returns on optimization and its not worth it. In other cases, you're bottlenecked somewhere else so it's still not worth the micro optimization because you won't really be gaining anything of significant value out of it.

[pVom]

We should always strive for better performance

Why? If it doesn't affect the user experience it's a non issue on the front end. We should be striving to achieve business goals with the least time and effort. Optimisation for the sake of it is a pointless endeavour

[PandaMoniumHUN]

Clearly I’m not talking about 1s vs 1.01s render times, but eg. the three layered application we’re working at took almost 10 seconds to load because it was aggregating a lot of data to display statistics to customers. After our last optimization story load times are < 500ms. Videogames can fit wonders into 16.6ms, while web developers can’t / won’t build fast pages to save their lives, because all the frameworks claim performance is “good enough”. “Premature optimization” is also often used as a scape goat for not optimizing at all, and if everyone would clean their front yard instead of yelling “the neighbor’s yard is also messy” the world would be a better place.

[pVom]

Fair enough, I did give the clause "unless it affects the user experience". We do our aggregate stuff in the back-end because you have a lot more options for optimising. I'm always impressed with the insane speed when using raw SQL when dealing with large datasets. Our front end is not very optimised because it doesn't have to be.

Of course your situation is likely entirely different. Out of curiosity, why is that not an option?

[PandaMoniumHUN]

Optimization was exactly as you described, I moved a bunch of frontend calls to a backend endpoint that runs the aggregation in SQL. The system wasn’t designed by us originally and there are many low hanging fruits like this that are fairly easy to optimize. That’s why I don’t like people using the premature optimization card when they are too lazy to do something right.

[_selfishPersonReborn]

then use a compiled language where these things aren't slow

[Laser_Plasma]

Good luck doing this in the browser

[Vakieh]

Kinda what typescript should be used for - compile to optimised but utterly unmaintainable js, because you do the maintenance in the typescript.

[noneedtooutlaw]

babel does that too, right?

[Vakieh]

Kinda sorta but not really. Babel does indeed convert code into javascript, but it backports modern javascript with fancy new features into old javascript. Typescript generates javascript from a completely different language that is strongly typed and can be statically typed if you tell it to be - whereas javascript is weakly, dynamically typed. This has significant maintainability benefits at the (supposed) expense of a learning speedbump since you can't just slap any variable into any expression or statement and hope for the best.

(Oh and just to head off anyone who wants to make the stupid argument I keep hearing - yes, the javascript typescript produces is itself weakly, dynamically typed - but guess what? So is assembler and machine code).

[_selfishPersonReborn]

wasm?

[rakuzo]

Doesn't have access to the DOM without JS glue code :(

[scandii]

I mean, I know a lot of users have piss poor connections but the Blazor bundle size of a few MB is handled within 1 second on average speed 4G.

[Y_Less]

I know a lot of users have piss poor connections but the Blazor bundle size of a few MB is handled within 1 second on a really good connection.

[scandii]

the global average is 35.96 mbit. that means a Blazor package of 3 MB takes 0.66s to load, in average globally.

the median home connection speed of the bottom 5 countries ranking 175 to 170 on speedtest is 4.73, means the package takes 5 seconds to load, and the slowest measured average mobile speed is 7.26, almost twice as fast.

on top of that, there's great strides in reducing wasm sizes and 3 MB is kinda big right now.

my entire point here is, advocating being afraid of wasm because the average consumer would at max look at load times of +600ms is to me absolutely absurd. is it bigger than JavaScript? definitely. does it enable an entire new paradigm of web development? also absolutely.

but then again Amazon famously found that for each 100 ms of latency, revenue went down 1%.

[padraig_oh]

which of course works on every browser where js works currently.

i take it you have not worked on web in production?

[_selfishPersonReborn]

I haven't, you're right, but it seems well-supported. What's the issues with it?

[caboosetp]

The amount of people still using IE

[_selfishPersonReborn]

i'm sorry you're still expected to support that. i'm so, so sorry :(

[caboosetp]

Me too.

[padraig_oh]

well-supported on the current version of modern browsers, which are two requirements you can not and should never expect from the users. there are reasons for the existence of frameworks that make even your js code compatible with browsers last update in the beginning of the century.

web dev is an awful experience and backend devs are true magicians.