Comment by andriusbartulis | Hacker News Reader

Comment by andriusbartulis | Hacker News Reader

andriusbartulis

There are two main high-level approaches for architecting web application client state:

1. Client-heavy state management (separate client application)

2. Client-light state management (thin client)

The state has to be tracked and managed somewhere. In most web applications, that state is persistable - at some point, it will end up in a DB of some kind.

As such, we already have to handle it on the server side, regardless of whether we also choose to separately manage it on the client side or not.

So the question at the end of the day is: Do I want to separately manage the application state on the client side, when I am already managing it on the server side?

In a lot of situations, the pragmatic answer would be "No". Why? Because managing the state in two places causes duplication, synchronisation issues, diverging logic issues, and so on. We are increasing the accidental complexity of our solution. Maintainability becomes slower, riskier and more expensive.

For some applications, the extra complexity might be worth it. In most web applications I have worked with (eCommerce, internal business tools, booking systems, online calculators, business dashboards), it is not.

And "let's keep all state and processing on the server" does not anymore mean no real-time or highly interactive features. With SSE and fast HTML fragment merging, we can enjoy highly interactive and performant web applications with almost no client-side application state management.

It still means less real-time and less interactive and likely more costly. Separating front and server is not a bad thing even if it brings some kind of duplication.

With .cljc files you can avoid the duplication anyway.

I've had quite my fill of "real time" and "interactive" web pages. Slow, bloated, terrible UX as often as not.

Even Datastar/HTMX might be too much. Server-side HTML can get you very, very far in most applications. It's faster, lighter, and looks and feels cleaner.

Case in point: do you really prefer a heavy, real time interactive message board like the default interface of Reddit? Because we're talking on HN, which is super fast, light, usable, and completely server-side.

Htmx is the exact opposite of what they're talking about. There are two concepts here: how you render and where you keep state.

HTMX is real time in the sense that it updates over the wire, but you're still keeping all state on the server side.

I don't want to reload the page to open a drawer. You'll notice HN isn't exactly mobile friendly because that requires hiding enough options that you need drawers or other ways to shrink and expand. You can do that with CSS, but that's still state, just state localized to that page load.

And there are sites that have unavoidably complex session state. You can have a resource that's on half the pages but is expensive to compute. I don't want to load it every time when almost none of it changes. I don't want to cache it on the server if it's a big payload

There's a world of difference between no state and over bloated SPAs

you might want to consider fixi, our ultra-minimalist implementation of general hypermedia controls:

https://github.com/bigskysoftware/fixi

In eCommerce, saving the cart on client side and doing optimistic updates in case client network is unstable is a standard feature.

Reply on news.ycombinator.com