Why Such framework doesn’t get as much love as full front end framework ? They are working fine in real world. Any similar ( apart from hey and basecamp ) real life example ?
IMHO, Turbolinks is not as effective as a "real" frontend framework.
Frontend development work is like managing a huge state machine. You make a modification here, a value changes here, and the whole frontend apparatus shifts to reflect this.
ReactJS got this right, particularly because you can closely couple it with Redux or Flux.
Things like Turbolinks (or jQuery or HTMX) require you to manage this state on your own and any sufficiently complicated project becomes very untenable very quickly.
This has gotten more and more apparent as they keep adding features to Turbolinks. State management is still a pain.
this is turbo, not turbolinks, so your critique is misplaced. turbo moves state management back to the server, using subregions (turbo frames) for flexible targeting and websockets to push (html, not json) state to the client with low latency.
in doing so, turbo relegates javascript to its original mission of enhancing the frontend (e.g., stimulus as a companion to turbo), not being the frontend. js is much better at this limited role than being a general-purpose app language. the sooner we can move past the unwieldy patchball that is react (and angular, node, yarn, webpack, endless transpiling/bundling pipelines, etc.), the better.
The responsibility of state management shifts from client to server. Which is my opinion is a better option. No need to understand/maintain two different applications.
> Why Such framework doesn’t get as much love as full front end framework ?
Mainly because the paradigm shift away from SPA's is just beginning.
Whoever convinced everyone that maintaining two applications (one front-end, and one back end) is somehow more efficient could make a killing selling bridges.
a lot of hypermedia baby was thrown out with the poor-user-experience bathwater when we transitioned from web 1.0 to SPAs, and it's great to see hypermedia-oriented libraries making a comeback
one aside: I see a lot of either/or thinking around these two options, either you go full SPA or you go full hypermedia. I believe it is more profitable to think in terms of functionality for a given part of your application: sure, if you have a client-state part of your application, maybe a complex reactive library is the right thing. But you probably have a setting page as well, where a hypermedia-oriented solution might be much simpler and just as effective. Why not take the complexity saved there and reallocate it elsewhere in your app?
9 comments
[ 200 ms ] story [ 727 ms ] threadFrontend development work is like managing a huge state machine. You make a modification here, a value changes here, and the whole frontend apparatus shifts to reflect this.
ReactJS got this right, particularly because you can closely couple it with Redux or Flux.
Things like Turbolinks (or jQuery or HTMX) require you to manage this state on your own and any sufficiently complicated project becomes very untenable very quickly.
This has gotten more and more apparent as they keep adding features to Turbolinks. State management is still a pain.
in doing so, turbo relegates javascript to its original mission of enhancing the frontend (e.g., stimulus as a companion to turbo), not being the frontend. js is much better at this limited role than being a general-purpose app language. the sooner we can move past the unwieldy patchball that is react (and angular, node, yarn, webpack, endless transpiling/bundling pipelines, etc.), the better.
Mainly because the paradigm shift away from SPA's is just beginning.
Whoever convinced everyone that maintaining two applications (one front-end, and one back end) is somehow more efficient could make a killing selling bridges.
a lot of hypermedia baby was thrown out with the poor-user-experience bathwater when we transitioned from web 1.0 to SPAs, and it's great to see hypermedia-oriented libraries making a comeback
one aside: I see a lot of either/or thinking around these two options, either you go full SPA or you go full hypermedia. I believe it is more profitable to think in terms of functionality for a given part of your application: sure, if you have a client-state part of your application, maybe a complex reactive library is the right thing. But you probably have a setting page as well, where a hypermedia-oriented solution might be much simpler and just as effective. Why not take the complexity saved there and reallocate it elsewhere in your app?