I find this "everything old is new again" such a tiring take. Sure, you can do things you could already do in Rails, but without giving up on the things people adopted React for. Like client-side updates without full page refreshes.
If you fool yourself into thinking that a few similarities to what you're used to means that there's nothing new to learn, you're missing out.
(To be clear, I'm not saying that everything new is automatically better, or that even Remix is. I'm saying that it's foolish to dismiss something without trying to understand what it brings to the table that you've not experienced yet.)
I don't disagree, but saying that people adopted React because of things like "client-side updates without full page refreshes" kinda walks right into the GP's trap: doing it it was already possible with Rails several years before React, with PJAX and then Turbolinks.
The reason people adopted React etc was not because of a few specific features, but rather because it was a completely different architecture with different pros and cons.
In practice you can do anything React does 100% on a server by sending a video feed to the client + some thin APIs, but it will have different issues and will solve different problems.
I was already having doubts about adding an example because I was afraid it would derail the discussion by focusing on the particulars of the example rather than the actual point. So I'll leave it at: sure, but that's irrelevant to the point.
My point was that the point of Rails vs React isn't about features but rather about architecture. I agree with you, I'm just trying to strengthen your argument.
Watch the demo, they're not full circle yet. They're intermingling business and presentation logic all over the place. Their data models depend on createPost(), getPost(), and getPosts() style boilerplate methods. It'll be a couple years yet before the JS community reinvents MVC and ORMs (under a really slick name of course), then we'll be full circle.
The broader way to see it is that people are trying to bake reactivity into these old school paradigms that have a lot of good things about them in terms of separation of concerns and working with data, but suck at reactivity.
Intermingling business and presentation logic is fine - even preferred - when they are tightly coupled. Lots of “business logic” is actually just presentation logic anyway.
I don’t think the JS community is going to make the same mistakes Rails did. I for one am glad the days of highly mutative, untyped MVC are coming to an end.
Presentation logic isn't business logic, and mixing both will create severe headaches later on.
The point is more, most apps just don't have any business logic at all! It's very often just some CRUD on some data entities, and the rendering of those entities. CRUD isn't business logic.
Also as much as rails seems so popular, I REALLY don't like rails so this seems to take what's good about it and removes some of the nonsensical opinionated crap. I'm not too much of a fan of node either but it's easier to work with IMO
This evoked a long ago memory of writing programs on a PDP-8/i in jr high (aka middle school) - and while the PDP-8 only had an accumulator (registers, plural - luxury :-) ), you did have to worry about fitting you code & data in 12 bit pages.
Genuine thanks for that memory.
It's hilarious isn't it. That being said, as we all know cobbling Rails + Angular or Rails + Whatever other client side library was always a hack that just used Rails as a JSON REST pump. At that point why not just use Node/Express? And so we come full circle.
I just ran through the tutorial. As someone who also still uses Rails and from reading the comments in this thread, it seems like Remix could be a good improvement over React, but not so much over Rails. (if Rails is your cup of tea)
During the last 20 years I kept using Java and .NET, with occasional dives into C++ when needed, while watching all those caravans pass through my porch ridding into the mountains, it appears there is some gold over there.
There is a lot of overlap between Rails and React, and you probably could use both to make 90% of the apps out there or more, but what really matters is the 5% that you can only make on Rails and the 5% you can only make on React. Plus the different productivity gains you can get on either for different requirements.
If you think there's a "better" solution that will supersede the other for every case, then you probably haven't seen or worked on all kinds of app that benefit from both co-existing.
Be sure you try stimulus and turbo first - you might find it is much better that way. Vue and react both have the same problem - it forces you to move your html into the JS. At that point you have no other choice but to move everything to js the database (vuex), validations, routing, internationalization, etc.
In theory you can just decorate your server side html with vue tags, but in reality that only works for simple hello world demos. Vue wasn't really built for that.
Maybe the next great new thing is react code that gets converted into ruby.
In serious though I really hope that Hotwire can become mature and intuitive enough to completely negate any need for a js framework on top of a rails backend
