Comment by llamataboot | Hacker News Reader

Comment by llamataboot | Hacker News Reader

Parent Full thread

Honestly my hope (and I admit as a full-stack but leaning back-end developer to be biased against JS) is that the future is in things like turbo-stream, stimulus reflex, phoenix liveview etc - or in things like all_futures (essentially an ActiveRecord wrapper around kredis) - that we move towards building reactive-apps by firing off events from the back-end and figuring out how to subscribe to them on the front-end

the amount of confusing boilerplate I've seen to keep updated and maintained when a JS framework is loading front-end state by making API requests against a backend and then trying to figure out how to keep those in sync when we could just be firing off SSR HTML over the wire and/or very thin events that FE components can subscribe to or emit for literally no gain in functionality is beyond me

even better, just add reactive sprinkles over what you need reactive and do the rest with standard MVC/REST patterns, if most of what you are using react for is glorified forms, you don't need react for that! user your reactive sprinkles of notification toasts, and chat channels...

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

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

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

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.

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.

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.

Reply on news.ycombinator.com