Hacker News new | past | comments | ask | show | jobs | submit login

Then go back and use ASP.Net 2.0 and submit a few mb of view state for every user action. Or Blazor server rendering.



If you are pushing megabytes of state for every user action, you've made plenty of other mistakes along the way

And I know it is more than a straw man. There really were bad sites like that. We have swung to another side of bad code, though.


That's how server-side interaction was in the early 00's with ASP.Net WebForms. This type of interaction is one of the things being proposed as opposed to client-side. And yeah, it definitely was a (very painful) thing. Server-driven Blazor has very similar (poor) behavior today. I know there's other frameworks that do similar things. Which really sucks if you have any latency or bandwidth issues.

Not that I like the idea of several MBs of JS being sent over the wire either... I know that is also a thing, not to mention poor state mgt, which is also a regular occurrence (most angular apps have many state bugs).

Personally, I'm not too bothered by client rendered/driven apps... They can often be split accordingly, and it's reasonable to stay under 500kb JS payload for a moderately sized web application. Not that everyone has as much awareness. I think of the browser as a thick-ish client toolkit as much as it is a rendering platform. That doesn't mean SPA is the right way for everything. I wouldn't do it for a mostly text content site (news, blog, etc). And most of my work is web based applications, not text driven content sites.




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

Search: