Not really sure this simplifies anything tbh, you’re just moving it into a Rails-gem-specific DSL that you’ll have to learn. At least with a Vue/React app consuming an API, any JS dev can work on the Vue/React side, even if it’s not perfect in how it works
Wondering why they released this: https://github.com/hotwired/stimulus-rails. Is this a hint that future rails will part ways with webpacker and move back to the asset pipeline?
I think “new magic” sounds about right in that DHH is extending the reach of Rails’s “magic” into the frontend. I do think people can be very productive with this framework, if you learn it. But it does kind of feel like I already understand how SPAs work – regardless of backend – and this is an alternate evolutionary path for frontend development that’s still mostly dependent on Rails.
As a side note to my comments of this, this seems extremely valuable in web applications where you need the dynamism of modern apps without being forced to write ton of JS code.
I cannot talk about if this scales or not, but its a great idea to deliver a product with a few resources and only truly worrying about scalability or performance about this when the time comes.
If you are doing an app for a few users this is great.
If you are building a product that can potentially attract millions of users but you dont have the budget nor the time to have a dedicated front team then this might be a good idea. Why? Because if you reach a point where you start having a few hundred thousands of users then it means you can try to convince investors that your product has enough potential and in that point in time you can swap to a more client sided solution if its required or just scale your app horizontally with that budget.
Has anyone got form submissions working properly with Turbo? Simple post -> redirect works fine, but if you want to do server validation and re-render the original HTML with errors, Turbo throws an error that a redirect is expected. I’ve played around with using turbo-streams but it seems quite buggy and I’m running into several issues (e.g. on some forms it works, on others literally nothing happens…i.e. the correct response is returned, but Turbo does not update the target element. ). It’s also impossible to switch off form submissions with Turbo, like you can with links. Turbolinks required a bit of JS to get it to work with forms, but at least it didn’t go out its way to just break them wholesale.
Overall this release seems a bit..meh. Some interesting ideas, but it feels like it’s been built around the needs of the Hey project, and you quickly run into its limitations even building basic stuff. Definitely not production-ready, unless of course you want to build a Hey clone. If you are already using Turbolinks I’d hold off upgrading for a while.
Does anyone else feel like this is just as confusing as writing a regular SPA?
Not really sure this simplifies anything tbh, you’re just moving it into a Rails-gem-specific DSL that you’ll have to learn. At least with a Vue/React app consuming an API, any JS dev can work on the Vue/React side, even if it’s not perfect in how it works
Wow, this looks amazing.
Wondering why they released this: https://github.com/hotwired/stimulus-rails. Is this a hint that future rails will part ways with webpacker and move back to the asset pipeline?
Seems like this would be a replacement for Stimulus Reflex. It’ll be interesting to see the differences between the implementations.
https://docs.stimulusreflex.com/
I wonder how it would work with Github’s view_component [1]. Does anyone have experience using Turbolinks/Stimulus with view_component ?
[1] https://github.com/github/view_component
I think “new magic” sounds about right in that DHH is extending the reach of Rails’s “magic” into the frontend. I do think people can be very productive with this framework, if you learn it. But it does kind of feel like I already understand how SPAs work – regardless of backend – and this is an alternate evolutionary path for frontend development that’s still mostly dependent on Rails.
This is amazing.
As a side note to my comments of this, this seems extremely valuable in web applications where you need the dynamism of modern apps without being forced to write ton of JS code.
I cannot talk about if this scales or not, but its a great idea to deliver a product with a few resources and only truly worrying about scalability or performance about this when the time comes.
If you are doing an app for a few users this is great.
If you are building a product that can potentially attract millions of users but you dont have the budget nor the time to have a dedicated front team then this might be a good idea. Why? Because if you reach a point where you start having a few hundred thousands of users then it means you can try to convince investors that your product has enough potential and in that point in time you can swap to a more client sided solution if its required or just scale your app horizontally with that budget.
Has anyone got form submissions working properly with Turbo? Simple post -> redirect works fine, but if you want to do server validation and re-render the original HTML with errors, Turbo throws an error that a redirect is expected. I’ve played around with using turbo-streams but it seems quite buggy and I’m running into several issues (e.g. on some forms it works, on others literally nothing happens…i.e. the correct response is returned, but Turbo does not update the target element. ). It’s also impossible to switch off form submissions with Turbo, like you can with links. Turbolinks required a bit of JS to get it to work with forms, but at least it didn’t go out its way to just break them wholesale.
Overall this release seems a bit..meh. Some interesting ideas, but it feels like it’s been built around the needs of the Hey project, and you quickly run into its limitations even building basic stuff. Definitely not production-ready, unless of course you want to build a Hey clone. If you are already using Turbolinks I’d hold off upgrading for a while.