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

> Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose).

Yet this is what all the JS people were saying in 2014 - 2015 when everything started to become SPA. They argued this is what the users want. That's been used to justify all this stuff for a very long time if you're on Twitter. When it gets traction within Twitter it leaks into orgs. It's the same argument that's used now for all the SSG,SSR,hydration,edge and whatever other buzzword.

The internet is miserable because of all these React sites. I know first hand because my wife has a Chromebook. Yet developers won't listen because they think 6x cpu slow down is good enough to test with on their $4000 Mac book pro.

If users really don't care that much about performance then why aren't we just rendering html and sending new html on every interaction. That's much easier to do, performs pretty well from a CPU/Memory standpoint.

We've taken on a lot of complexity over the years in defense of the users. The argument I go back to is what is "good enough" and the developers/product/design I've worked with don't know what this word means.




Rerendering on the backend can actually be faster than doing AJAX calls because the BE has to send a lot more data than if it's server rendered.

I


How is "server rendered" different form "rerendering on the backend"?


Rerendering should be Rendering, however they aren't different. They are the same.

Server rendering can carry less of a payload to the FE but you aren't sending unnecessary data.


Absolutely agree. Thank you btw for bringing up some of the recent history. People forget so easily




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: