I would in concept describe those as server rendered SPAs requiring a continuous high quality, high bandwidth, low latency connection. As per navigation they classify as a "hybrid" - a complex version of Turbolinks - where client state is managed server side.
The term SSR keeps being used in a variety of ways.
In many contexts it implies firing up client side JavaScript on the server to generate markup and state to be sent to the client which then takes it and runs with it.
I personally avoid using "SSR" to mean "Classic SSR".
«The Rails Hotwire» reference here should probably be «Hotwire Turbo Streams». Since Hotwire is written in TypeScript and can run with several types of backend (like Django, with turbo-django).
«Turbo Streams deliver page changes over WebSocket, SSE or in response to form submissions using just HTML and a set of CRUD-like actions.»
I would in concept describe those as server rendered SPAs requiring a continuous high quality, high bandwidth, low latency connection. As per navigation they classify as a "hybrid" - a complex version of Turbolinks - where client state is managed server side.
The term SSR keeps being used in a variety of ways.
In many contexts it implies firing up client side JavaScript on the server to generate markup and state to be sent to the client which then takes it and runs with it.
I personally avoid using "SSR" to mean "Classic SSR".
«The Rails Hotwire» reference here should probably be «Hotwire Turbo Streams». Since Hotwire is written in TypeScript and can run with several types of backend (like Django, with turbo-django).
«Turbo Streams deliver page changes over WebSocket, SSE or in response to form submissions using just HTML and a set of CRUD-like actions.»
turbo.hotwired.dev/
Based on the this "NEW MAGIC" was renamed to Hotwire in December 2020. I have no doubt that the implementation continued to evolve.
The point really is the order of emergence: