It's good with React too when you need more interactivity.

I believe you can do anything React can with Stimulus + Turbo these days. I don't do much FE but I've been tracking Hotwire for some time now.

perhaps for most things but probably not to the extent of something like excalidraw, which uses react

Yes, but in that case, you can use only the complexity where you need it, instead of globally.

You can still use React or whatever on those pages. And for the rest (settings pages, signup pages and all the CRUD pages) you can use standard Rails with Hotwire.

Yes, but there is a whole ecosystem of react components and react developers.

Maybe you can with heroic effort, but you shouldn't. You should build within the constraints of your tools. HW + Stimulus are great - good enough for what most web apps need to do. It gives you "traditional web app, with a bit of realtime updating" - which is the perfect fit for most web apps.

But you wouldn't want to use it for a fully interactive desktop style application with lots of interacting components.

Agree. So unless you have a pretty big budget and you're building Google Maps or Figma you shouldn't use React.

Sadly, everyone things they have such a big budget and they're building the next Figma. Even if you're building a CRUD app. (I'm talking to you previous team of mine).

You can do anything with plain JS too, but that doesn't mean you'd want to. The problem with Hotwire is that you do often have the server round trip in there. That's fine most of the time, it just gets a little harder to understand as the complexity rises. That's not to knock it, I think Hotwire is pretty good.

In what scenario would complexity be higher in a simple UI - server loop? Doesn’t complexity usually arise from having additional logic in the browser and maintaining state separately?

I guess it depends somewhat on how you imagine up something and write it. I was working on some drag and drop UI that had multiple sortable lists and an action area. Figuring the server side and UI at the same time didn't work out. I reversed and implemented the UI with its required state, and then it was easy to transform that state to what the server side required, and vice versa.

Complexity is tricky. Are three simple things more complex than one thing thats harder to understand?

Still decent amount of caveats given the UX expectations of 2023... eg last I checked there was no official support for transition animations

Rails is extremely easy to get started with but after a few years the lack of types on Ruby cripples every single Rails app I've ever worked on. You can have as many unit tests and browser automation tests as possible, but updating any gem is a dice roll despite doing as much due diligence possible. And it's always something extremely trivial like a method changing its parameters without announcing it in the change log for some reason. Something almost any other language would warn you about.

I've been doing Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks. The only advantage Rails still holds is the out of the box batteries included package. But once a TS framework gets this, Rails will be in decline.

Doesn't Ruby have 2 production-ready typecheckers now? I think Ruby officially has something called RBS, and Stripe open-sourced Sorbet.

We evaluated them, it's just not there and it's unclear if it ever will be. DHH, the lead for the Rails project has indicated that Rails will "absolutely not" have a type checker in reply to a tweet asking about it. And a huge amount of work would be required from the Rails team to get type checking to work.

Used to work at a Rails shop, and led an effort to get type safety into the codebase. It was a nightmare that wasted endless time and added plenty of stress.

Sorbet is great on vanilla Ruby code that doesn't try to use too much arcane metaprogramming. It's "okay" on vanilla Ruby code that uses some arcane metaprogramming that humans can reliably reflect in RBS files. In a Rails codebase, which is (IMO) a huge ball of relatively hard to statically analyze magic and quite heavily uses all sorts of tricks for either API ergonomics/skimmability or for performance, it was a mess, and frankly, I had a pretty nightmarish time selling almost any of the feature set beyond (1) ADTs/Enums (2) the subset of Interfaces as exposed by `T::Struct`.

Sorbet is a herculean effort by some extremely talented devs. I don't at all want to discredit that. Tapioca is likewise an impressive DSL-reflection machine on top of RBS files, particularly post-0.8 release. But type safety in a Rails app is, at least in my experience, extremely high cost both upfront and maintenance.

To offer another point of view: I work on a recent Rails app that was set up with Sorbet/Tapioca from the get-go. All Ruby code is `# typed: strict`, and we (I) feel like the ROI is generally positive. It's caught more than one bug, and it's easy to eject from it when it gets in your way.

That said, type safety via Sorbet/Tapioca is ultimately an afterthought in Ruby and the DX suffers from it compared to languages where type safety is baked in. In my limited experience, MyPy in Python was even worse though.

As for RBS, I have literally never seen it used in the wild and I don't know why the Ruby core team bothers with it rather than go all-in on Sorbet.

(your comment made me realized I kept typing "RBS" when I meant "RBI" in a Sorbet context. oops)

Anyway, I did have my strong suspicions that Sorbet would pay off more in a codebase that used it from Day 1. Glad to hear at least one report that indeed, that was the case.

They are terrible. Typescript might have spoiled me, but the type system is bad and the type checkers are even worse.

This is exactly why I’m keeping my eye on RedwoodJS. They are coming for the crown.

Same thing that other people sat about Next.js, about Remix, Nest, Qwik, and the other 10 thousand that "are coming for the crown". In fact, that's the problem.

I've worked with a lot of Rails code bases over the last 10 years and just haven't ever experienced this problem from a types perspective.

Certainly, if you let gems start to get out of date the dependency chains to get them updated can become a task but that's fairly true of any language. It's one of the selling points for moving parts of an app to isolated services too.

Everything is a tradeoff though. I don't know that you can get the Aspect Oriented Programming gains that you get with Ruby and Rails with a more strictly typed language.

Every Rails upgrade is kinda proof of the problem, isn't it?

There is an entire market on Google of companies expert in upgrading Rails, that to me is a bad signal.

(notice, I have almost 15 years of experience with rails)

During the Ruby 1.8.7 to 1.9 transition there was a lot of complexity to things, but it hasn't really been a big problem since then has it?

I dodged that, started getting serious with rails 3 and ruby 1.9+

No,there are still many undocumented breaking changes. I recently upgraded an old app from Rail 4 to 7 that used minimal non-rails stuff and was shocked by the corner cases.

Manu changes to activerecord api go completely undocumented, but they break the code nonetheless

Did you go straight from 4 to 7 or 4, 5, 6, 7?

There is no upgrade guide from 4 to 7,so I did from 4.2 to 5,from 5 to 5.1, from 6 to 6.1 and then to 7.

I actually found a bug that broke my app at version 6 that was resolved in 6.1,so technically my tests were not passing in version 6 and I did an "unsafe upgrade" to version 6.1

> Rails dev for 7 years now but I just don't see it winning over TypeScript/nodejs frameworks

I think you're comparing a language/runtime with a framework here. I also prefer Node and JavaScript over Ruby but I get what you say, and I agree.

I think Adonisjs ticks all the boxes to be that framework in the future. It just doesn't have the community it needs to be 100% successful yet... with more adoption it will get all the missing features, documentation and little annoyances it might have today polished.

But something I'm worried about is if that the fragmentation is just too big at this point. I don't see people agreeing on a single "full stack" framework as it happened in other environments.

I think this happens because most other "big frameworks" were born when there were not that much competition and not that many people on their ecosystems, so there were a lot fewer options and people concentrated around those frameworks and made them grow to what they are today (Laravel, Rails, Django, Spring...).

The "backend JavaScript" ecosystem is a freaking mess. So many competing options, all of them terribly incomplete, all of them claiming to be "full stack" just because they can execute JavaScript on the server... yes, maybe "full stack" but without the battery... it's a lamborghini that you have to put together yourself before being able to use it.