[philippta]

It's not too diffcut in the browser either. Consider how often you're making copies of your data and try to reduce it. For example:

- for loops over map/filter

- maps over objects

- .sort() over .toSorted()

- mutable over immutable data

- inline over callbacks

- function over const = () => {}

Pretty much, as if you wrote in ES3 (instead of ES5/6)

[staticassertion]

Yes but it's not really fair to expect me to know how to do that. Just because I know how to do it for backend code, where it's often a lot easier to see those copies, doesn't mean I'm just a negligent asshole for not doing it on the frontend. I don't know how, it's a different skillset.

[philippta]

Nobody expects you to know that, but I'm curious to hear how do you know it for backend code but not frontend code. Have any examples?

[staticassertion]

The parent commenter earlier seems to be implying that it's only a matter of not caring.

> care so little about the performance of the code they ship to browsers.

> but I'm curious to hear how do you know it for backend code but not frontend code.

Because I find backend languages extremely easy to reason about for performance. It seems to me that when I write in a language like rust I can largely "grep for allocations". I find that hard to see in javascript etc. This is doubly the case because frontend code seems to be extremely framework heavy and abstract, so it makes it very hard to reason about performance just by reading the code.

[philippta]

That's completely relatable, and also a major point in my original argument. Using heavily abstracted frameworks will automatically cap you performance wise. The only way out is to not use a framework or one that's known to be lightweight. In backend or tooling like with the JS compiler from OP, one tends to not use heavy frameworks in the first place.