undefined | Better HN

0 pointstomnipotent10mo ago0 comments

You absolutely did. It was common practice to stuff things in cookies or query strings to retain state between trips to the server so that some JS could do its job.

Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.

0 comments

stavros10mo ago

Right, but validation logic and state transferred by the server isn't in-memory state. The fact that the pages completely reload on each request clears a lot of cruft that doesn't get cleared on pages whose lifetime is tens or hundreds of views.

tomnipotentOP10mo ago

Every SPA I come across, especially when using React, uses persistent state so that in-memory changes are synced to cookie/localStorage/server so they survive refreshes. Every popular state management library even supports this natively. And all of that state combined still requires less memory than any of the images loaded, or the JS bundles themselves.

actsasbuffoon10mo ago

I absolutely loathe that. State is the source of most bugs. If the page crashes then refreshing it should clear out the state and let me try again.

Anecdotally, it seems like I encounter a lot more web apps these days where refreshing doesn’t reset the state, so it’s just broken unless I dig into dev tools and start clearing out additional browser state, or removing params from the URL.

Knock it off with all the damn state! Did we forget the most important lesson of functional programming; that state is the root of all evil?

2 more replies

j / k navigate · click thread line to collapse