[flagged]
Again, this is a different spin on doing things. Rails preaches abandoning the over-complexity of the client-side in the browser and pushing work to the server.
I personally love it. I'm sure someone who is as fast in React as I am in Rails is laughing reading this.
And htmx is worth exploring. As is HTML over the wire tools across various languages.
Rails remind me of Perl's metaprogramming beauty (code is almost literature or even art) but also its worst sides (unique situational DSLs for everything and then some more, with TIMTOWTDI). It takes a lot of research to figure out where things are coming from because everyone seem to really love metaprogramming the whole kitchen sink, magically converting :symbols to ClassNames to autogenerated helped methods to generated attributes. And nothing is ever implicitly imported in the file you're looking at. Surely, it's all pretty simple after you learn how the particularly selected gem is used, but almost incomprehensible before you do. E.g. I just struggled for good 15 minutes before I learned that expose(:foo) is from a `decent_exposure` gem (and read that gem's source to understand how and why it does all its magics) - and there seem to be hundreds if not thousands of such gems in any sufficiently large and old Rails project.
Oh, TIL that Rails doesn't implement If-Match at all (only If-None-Match for GET and HEAD through some Rack middleware). Every other toolkit I've used had something for that.
Rails is built with developer happiness in mind. JS though became the answer to all questions for reasons that are beyond me. You can’t escape it entire so I try to limit how much I have to use it.
Although it's more the "Laravel of js" than the "Rails of js".
P.S: Yes, I know Nest.js and I don't like it and don't think it's better or even closer to the developer experience you get with Adonis.
Could you expand what you mean?
A lot of problems arise when you want to use it to build a "full stack" application with just Next.js and no "real" backend framework. Many people will tell you Next.js is "full stack" because it can execute JavaScript in the server. For me that's not "full stack"... Maybe when I say "full stack" I'm actually meaning "batteries included" because that's what I need when I'm building a "full stack" application.
For any non trivial application, you'll need things such as authentication, authorization, migrations, orm, background jobs, translations, logging, error reporting, rate limiting, security guards (cors, brute force attacks, etc, etc, etc). Most, if not all of these things come out of the box in real "full stack" frameworks such as Laravel, Django, Rails or Adonis.
A few months ago I had to deal on a Next.js application which needed server side rendering, internationalization and data validation. Making the error messages from the server show correctly and making the i18n library work together with the authentication, the SSR, the half-assed orm/wrappers around prisma, etc.... it... worked... but you end up looking at the code and asking yourself "Why am I doing this?... Adonis.js or Laravel would do it for me already".
Of course some people here will say "but there's a library for each one of those things in the Next.js ecosystem"... yes, but picking the right ones, integrating them so they work in a seamless, secure and battle proven way, keeping it up to date, maintainers abandoning them, trends making them out of fashion, etc, etc it becomes a TON of (business wise) useless work.
So Next.js for the frontend? Great. Next.js for a non-trivial full stack application or for your backend? Sure, but you're not using the right tool, it's like trying to put a screw with a hammer. Might work. Just far from ideal.
I suppose what you have to learn and add is relative to what you already know and have, isn’t it?
What reason is there to learn Ruby and Rails and Hotwire and streams and turbo frames and whatever the next churn is just to avoid rendering some html with javascript?
No one is suggesting the industry immediately adopt some random new library, except for Rails fans who constantly demand everyone abandon a de facto standard like React and use their new toy.
The problem is what happens next. Do you reload the entire page each time the user makes any kind of change?
I must've dreamed up the dozens of times I did.
Unless you mean you still need JS to build the modal, which is true but I doubt GP was implying that you shouldn't use JS whatsoever. You don't need a SPA to build a modal.
If you know in advance that you will never have complicated combinations of states, then sure, go ahead and use alpine (vanilla DOM element creation makes very unreadable code) or if you won't even need to create elements don't use anything... but the situations where you really know your application won't evolve that way are very rare next to the situations where you merely don't yet know that it will.