2 ms·

What about apps that have no backend? What about apps that should work both online and offline?

lawrencechen 5y ago
^ What about Figma? Photoshop? Not everything is only a CRUD app.
mst 5y ago
Those are very different applications and the trade-offs involved are completely different. In the -common- case OP seems to me to have a valid point.
- rezonant 5y ago
  For forms-over-data business applications, sure it's fine. It's tradeoffs around the system use cases, potential/realized functionality, and team. But I think that serving to public users with server-driven MVC for an application that goes beyond a pure content app has immediate and obvious limits in terms of what can practically done, and the more you try to overcome those limits the more you simply rebuild what is already available in the SPA side of things. It's also inherently monolithic, meaning that if you want or need to support a mobile/native app for your public-facing app, you'll now need to develop a new "interface" (an API), when you should have already done that to enable the web app in the first place. Is it really worth skipping API/UI separation on day 1 when you know it's going to be needed on week 2? You might say, it's fine, we're going to just make API calls for the Javascript, but then you've got an inconsistent availability of the functionality, and the second you hand that to another team to consume you will have wished you had simply built out all of the needed functionality directly in the API anyway.
llamataboot 5y ago
I'm not saying there are no use cases for a JS framework, and I have a few I like, just that the switch to rails api only/separate react app has in almost every case I've seen added tons of complexity without a clear win
- rezonant 5y ago
  Imagine you have a Rails controller with a form template and you want to have a section of the form show or hide based on the setting of other form elements, obviously without reloading. Can you do it? Yes. Does Hotwire/Stimulus make this possible? Yes. Can it be done in a nice easy to use way? Yes. If you stretch beyond what Hotwire/Stimulus can let you do, do you have to completely switch over to the "frontend engineering" path of single page applications (React/Angular/Vue/Svelte/etc)? Also yes. Are the primitives you use in Hotwire/Stimulus in any way connected to the ones you'd use if the use case got even a little more complex? Absolutely not. Why not just have one set of primitives that work for all applications? It's not like having some frontend templating logic or reactive forms or whatever is going to actually be harder than just doing it in Rails if you are familiar and comfortable with both. If you aren't comfortable with both, then that's fine.

^ What about Figma? Photoshop? Not everything is only a CRUD app.

mst 5y ago

Those are very different applications and the trade-offs involved are completely different. In the -common- case OP seems to me to have a valid point.

rezonant 5y ago
For forms-over-data business applications, sure it's fine. It's tradeoffs around the system use cases, potential/realized functionality, and team. But I think that serving to public users with server-driven MVC for an application that goes beyond a pure content app has immediate and obvious limits in terms of what can practically done, and the more you try to overcome those limits the more you simply rebuild what is already available in the SPA side of things. It's also inherently monolithic, meaning that if you want or need to support a mobile/native app for your public-facing app, you'll now need to develop a new "interface" (an API), when you should have already done that to enable the web app in the first place. Is it really worth skipping API/UI separation on day 1 when you know it's going to be needed on week 2? You might say, it's fine, we're going to just make API calls for the Javascript, but then you've got an inconsistent availability of the functionality, and the second you hand that to another team to consume you will have wished you had simply built out all of the needed functionality directly in the API anyway.

llamataboot 5y ago

I'm not saying there are no use cases for a JS framework, and I have a few I like, just that the switch to rails api only/separate react app has in almost every case I've seen added tons of complexity without a clear win

rezonant 5y ago
Imagine you have a Rails controller with a form template and you want to have a section of the form show or hide based on the setting of other form elements, obviously without reloading. Can you do it? Yes. Does Hotwire/Stimulus make this possible? Yes. Can it be done in a nice easy to use way? Yes. If you stretch beyond what Hotwire/Stimulus can let you do, do you have to completely switch over to the "frontend engineering" path of single page applications (React/Angular/Vue/Svelte/etc)? Also yes. Are the primitives you use in Hotwire/Stimulus in any way connected to the ones you'd use if the use case got even a little more complex? Absolutely not. Why not just have one set of primitives that work for all applications? It's not like having some frontend templating logic or reactive forms or whatever is going to actually be harder than just doing it in Rails if you are familiar and comfortable with both. If you aren't comfortable with both, then that's fine.