Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The web is a front-end environment, where users expect 60fps, but where developers violate pretty much all the rules.

> Zero-copy is the default, not the optimization:

the amount of fluffy mapping, destructuring, temp scope-creation, ... that is the norm now for JS/TS devs is excruciating. how did this become the norm? do it once it doesnt matter, but every single layer in the app doing this and things become jittery. you first take the hit at creation time, and then another time at GC. stop doing that! Pass references around to objects, not recreate them each time at some function boundary.

> Entity as pure identity.

Stop json.stringifiyng every thing! how many hashThing() implementations i have seen that are essentially Json.stringify. stop it!

> Cache locality by default.

a little less clear for web dev, much is missing in terms of primitives. but do think about it. if anything, it's good hygiene. fixed typed array does make sense, dont mix&match types in your array, ...

Save the web, think like a videogame dev!



Well, it's certainly not going to get better given that most of new Web code is by now probably written by LLMs. Which definitely aren't trained to write performance-oriented JS/TS.


lol another example of how things can always get worse.


The only "performance" that anyone actually cares about is the "P" in "KPIs".

Isn’t it funny, btw, how "performance" can also meant "acting out a fictional narrative"? Just a thought…


You forgot dynamic property creation/lookup instead of using a constant "shape" that JS engines can actually JIT optimize away.

And then there's the more detailed version of that where people write {x: 0, y: 1} in one spot and {y: 1, x: 0} in another and do not seem to realize that this under the hood they just sabotaged the ability of every JS engine out there to fully optimize any code related to it. Which also extends to situations where functions take objects that happen to share some properties as parameters: if you can put the shared properties first and in the same order in the object creation, it will result in better optimized functions.

(but tbh I think that as long as we don't fix the bloat that is tracking libraries first, all of this is optimizing the wrong thing)


> Pass references around to objects, not recreate them each time at some function boundary.

Non-primitives are always pass-by-reference. There's no mechanism to pass a non-primitive by value except edge-cases like giving ownership of a buffer to another process.

> destructuring

What about it? What backs the assumption that destructuring is inherently worse than dot and/or bracket syntax? Is there a behavior you think is unique to destructuring? Or maybe a specific report from one engine years ago?


> Non-primitives are always pass-by-reference.

it's a good thing. pass objects by reference.

> Is there a behavior you think is unique to destructuring?

depending on exact syntax, will collect values in another array or object. it's often used as the mirror-pattern of using named variables, which allocates an object for each function call.

in isolation these are not inherently wrong, at scale they start to add up. and should not be used in tight loops.


> pass objects by reference.

It’s not an option. That’s how JS must behave.

> depending on exact syntax, will collect values in another array or object

Not in JS. Maybe you are referring to rest syntax? That is not specific to destructuring i.e. functions accept rest parameters.

> which allocates an object for each function call.

No, in JS non-primitives MUST be pass by reference.


You're being pedantic and doing gotcha argumenting.

Pass objects by ref, I said that to underscore its better than create new objects. I get it, its the only way, but theyre still passed by ref.

Yes, [a,b,...rest] =... is restructuring and creates new object.

Named params create new objects, it's better to pass args individually, the ref creation under the hood is not comparibly impactful.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: