[ZephyrBlu]

Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though.

Managing any (Literally any) client-side state is also easier with a framework. I'd rather use Preact than write vanilla JS for basic state management.

[spinningslate]

> Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though.

I've heard this before, and just don't get it. I have, can, and do create view "components" in both Django and Jinja2. They're just templates. Templates that get included in other templates. I've never (never) got to a point where I thought "darn, I want to abstract out this foo thing as a component, but can't". When I really want front end interactivity - like charts - then I'll use a JS library or a web component. With htmx, I can even do partial page updates.

None of that requires the very significant overhead that React/Angular/whatever bring.

>I'd rather use Preact than write vanilla JS for basic state management.

I'd rather use the backend. Because it owns the state, and cache invalidation is one of the two hard things [0].

[0]: https://www.martinfowler.com/bliki/TwoHardThings.html

[ZephyrBlu]

If you think templates are a substitute for components there is very little to discuss. Templates hide hierarchy, are not easily composable, are not easily shareable (Can you publish a set of templates on NPM?) and cannot easily have complex self-contained logic.

Another big upside of JS components which does not exist in templates is typechecking.

Templates are good if you don't have complex hierarchies and have relatively simple layouts that aren't very dynamic, but they're not the same as components.

JS frameworks have relatively low overhead compared to the total size of most sites. React is ~50kb gzipped. There are also of plenty lightweight options.

> I'd rather use the backend. Because it owns the state, and cache invalidation is one of the two hard things

The backend does not own UI state. If I need to filter or sort a collection I don't want to make a request to the backend. If I need to make a selection I don't want to wait for the backend to respond before the UI updates. And so on.

[arrowsmith]

> The backend does not own UI state.

It does with Phoenix LiveView. And for stuff that shouldn't need to talk to the backend I find Alpine.JS to be a comfortable option that's very lightweight and several orders of magnitude less complex than React.

[yurishimo]

How have you found the latency to be? Are you shipping in multiple regions? Is this something you think about actively? I know there are ways to optimistically update if you want, but that sort of defeats the purpose imo. (I say this as someone extremely interested in Elixir/Phoenix)

[christophilus]

I tried something like liveview way back in the day (10 or 15 years ago) and latency was the killer. It’s probably much better these days with 5G and more efficient refreshing (we did full page refreshes, IIRC). But this is still the reason I won’t use liveview or an equivalent. If you do run into latency issues, you’re in for a world of pain if your entire application is architected incorrectly.

[arrowsmith]

I get that those are the benefits. All I'm saying is that, in my opinion, the benefits you get from building a SPA are not worth the increased complexity it adds, at least for most of the projects I've encountered in the real world.

[ZephyrBlu]

I can believe that. For a lot of projects the complexity probably causes more issues than it solves.