←back to thread

Clojure: Realtime collaborative web apps without ClojureScript

(andersmurphy.com)
170 points bko | 4 comments | 08 Apr 25 18:40 UTC | HN request time: 0s | source
Show context
andriusbartulis ◴[11 Apr 25 08:12 UTC] No.43651521[source]▶
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.

replies(2): >>43652737 #>>43652758 #
1. dominicrose ◴[11 Apr 25 11:45 UTC] No.43652758[source]▶
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.

replies(1): >>43653196 #
2. lukev ◴[11 Apr 25 12:49 UTC] No.43653196[source]▶
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.

replies(2): >>43654796 #>>43654870 #
3. Capricorn2481 ◴[11 Apr 25 15:17 UTC] No.43654796[source]▶
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

4. recursivedoubts ◴[11 Apr 25 15:21 UTC] No.43654870[source]▶
you might want to consider fixi, our ultra-minimalist implementation of general hypermedia controls:

https://github.com/bigskysoftware/fixi