Is this satire? Rage bait? Why would you ever do this?

Just make a normal website!! You've invented an MPA with extra steps!

▲ mikestorrent an hour ago | parent | next [-]

Then you'd have to focus on making a website someone gives a shit about, with content worth pursuing. Instead, one can just retreat into the engineering ivory tower, making an ever purer object that ever fewer people can understand or care about.

▲ x0x0 6 hours ago | parent | prev [-]

Responsive site built via server-side render, with a particular benefit for partial page updates. 90% of the benefit of an SPA but 10% of the code: no api, no moving of system of record for state back and forth between database and browser (it's always db), etc. And you can avoid react.

A common use case: eg in Rails, a user has a table open. you can stream new records to the top of that table as they are created in ~5 lines of ruby (a broadcast on the model, and put the table rows in a turbo_frame with a turbo_stream_from somewhere on the page).

There are real limits to this -- you have to hold the update dependency graph in your head -- but the benefits are huge for small to medium amounts of responsiveness.

My experience has been great with Rails/Turbo and htmx.

▲ frollogaston 5 hours ago | parent [-]

I get how there's virtually no API if your client is simply rerendering the entire page each time it gets a ws message, but the article glosses over the partial page updates and just says "place the HTML where it belongs." How would that work? You'd need some kind of API for the client to request page parts and/or the server to tell the client where to place them.

▲ x0x0 4 hours ago | parent [-]

no api. The way it works is thus (rails, because it's what I regularly use):

The system is called Turbo. A turbo_frame is just a custom html element. You can largely use it instead of a div.

Turbo's js watches for navigation events (link clicks, form submits) that originate inside one of these elements, and instead of letting the browser do a full navigation, it:

1 - makes the request itself, against the usual rails routes. It uses your normal routing, sessions, cookies, etc.

2 - Intercepts the html response and looks for a <turbo-frame id="..."> that matches the id of the frame that triggered the request

3 - Swaps just that element's contents into the page.

more concretely: suppose I have a list of people in a flex table. I wrap the people table in a turbo_frame so I can prepend to it, and wrap each person in a turbo_frame so I can update it. My page can look as so:

    turbo_frame "people", class: "person-table flex flex-row" <-- the overall list
      turbo_frame person_1, class: "person-row flex flex-col"
        the row for person 1
      turbo_frame person_17, class: "person-row flex flex-col"
        the row for person 17
      turbo_frame person_12345, class: "person-row flex flex-col"
        the row for person 12345

etc.

If the user edits a form for person 12345, that is wrapped in turbo_frame person_12345.

The browser makes the request itself, grabs the response, pulls out the contents of turbo_frame person_12345 (and NB: the response can be a whole page or just this fragment), then swaps that in for the existing person_12345.

It's designed so you can make your normal MPA with page navigations and reloads for editing a table row or whatever, make a small set of updates to the html, and have this work almost entirely for free. It sounds too good to be true but I've been using it for years and it often really is that easy.

edit: for server-initiated updates, I can broadcast to select listeners:

1 - replace a turbo_frame (person_12345 was updated externally, and I want to just swap out) 2 - prepend (eg for a css table, put my new person_12345 row in front of other rows; 3 - append (same, but at bottom)

	▲	frollogaston 13 minutes ago \| parent [-]
		This is kinda what I was expecting, but there is a whole library handling it for you. I just noticed the article mentions LiveView which probably does something similar.