Do we need JS framework?

Back in 2010, we had a few options for rich front end interactions. RailsUJS got us a little bit of the way there, but was severely lacking. Turbolinks back then often caused problems with other javascript libraries and was often something that I would disable when creating new applications.

Fast forward to today, and that isn't the case much anymore. Today, with Stimulus and Turbo, we are able to create rich interactions on the front end. Even with Turbo alone (with streams and frames) we can accomplish a lot of rich interactions without needing to write any javascript ourselves. While some may benefit from using a heavier frontend framework like React, Vue or Angular, the benefits are fewer and fewer today than they were back then.

Perhaps if there was a larger company who had a whole department around design and frontend stuff, it could still make sense to use React and the Ruby on Rails side was simply providing an API. But often enough, this isn't the case for small to medium size companies (and even a lot of large ones). I've seen some medium sized companies today that are still stuck in this mindset that Ruby on Rails cannot handle rich interactions and they're still developing Rails/Frontend Framework(Angular/Vue/React) together on the same team and their velocity is slower than had they stuck with what Rails provides today. Another benefit is that there is a vast library of existing components for React that could be appealing to some to use those instead of having to create their own implementations.

Regardless, on a new application, my preferred route is the "Rails Way" using what is provided by default. Over the past several years (ever since Stimulus was released), I lost any desire to explore frontend frameworks and with the release of Turbo, this was solidified. 

I agree 100%. What about having monolith app? Please share your experience? I have everything on the same app. APIs, several role base users for the frontend (ERB). It works like a charm. The only issue i experience now is the fact we still don't have any 
turbo:after-stream-render event in turbo. This ias a major issue for me since i use several jquery based libraries.
 

I've gone down the monolith with  Backbonejs, Angular, and React. Using just Stimulus and Hotwire is a breath of fresh air. Though, to your point, it can be difficult when you run into those "edge cases" where you need something to happen that the framework doesn't have available. There is some great discussions about this on this GItHub issue https://github.com/hotwired/turbo/issues/92 as well as some potential solutions. 

I've ran across some of the issues that you're describing too. Specifically, when there is something like ChosenJS that you want to have rendered from a Stimulus controller, but cannot invoke the chosen() function because of the whole jquery stuff. Some of the solutions in the link above could help address these issues, but what I've done in the past is work towards moving away from the jquery libraries in favor of something with vanilla JS. However, I can empathize with people who have heavily invested in one JS library that is used throughout their application.

In my case the company needs an app and a website. Does it make sense to have monolith app with hotwire and turbo for the web version and a react app binded on the api namespace of the monolith?

That can be a tough decision. It greatly depends on what the application needs to do (or have access to) on the phone's hardware and also availability if the user is not in cell/wifi range. If internet access is not a concern as it is a core requirement then a Turbo Native approach could be the easiest path. This way you wouldn't need to maintain the API as well as a full fledge mobile interface as the ActionViews would be used. Alternatively, if there aren't many requirements for the hardware of the device (no need for NFC, camera, GPS, etc), you may be able to get away with a PWA. 

Honestly, I would explore these two routes first before jumping to a React Native approach.

This is why i said we need an app. They app relies on some hardware stuff. That's the reason why i would like to propose monolith with front and back Rails. API for react app. We won't be stuck by React development since Rails developpers velocity is much more higher.

PS: It is a banking app

Yea, I'm sure they have some pretty strict regulations with that kind of stuff. Turbo Native has come very far with integrating with hardware so you can use all of the hardware components that you need to, but you also would have to create the iOS app and Kotlin app. But it's still a lot less work than a React Native app or a standalone app. Hybrid is the current flavor of the "rails way". However, if that isn't an option to go hybrid due to requirements or policies, then React Native, Xamrin or similar could still be an easier route than a standalone Android and standalone iOS app.

I completely agree with your perspective on the evolution of front-end development within the Ruby on Rails ecosystem. In the early days, integrating rich front-end interactions was indeed a challenge, and tools like RailsUJS and Turbolinks had limitations that often led to frustration. However, with the introduction of Stimulus and Turbo, Rails has significantly improved its capabilities for handling complex front-end interactions without the need for heavy JavaScript frameworks. The combination of Turbo Streams, Frames, and Stimulus has made it possible to create dynamic, real-time applications while maintaining the simplicity and maintainability of the Rails stack.

As you mentioned, for many small to medium-sized companies, the use of a frontend framework like React or Vue can add unnecessary complexity and hinder development speed, especially when Rails itself provides the tools needed to create sophisticated applications. For developers building hybrid apps—those that combine native and web technologies—these frameworks can seem like overkill, adding unnecessary overhead when simpler solutions like Turbo and Stimulus are sufficient. This approach also aligns well with mobile app development strategies, where leveraging web technologies within hybrid apps can streamline the process and reduce the need for separate mobile-native codebases.

The approach of sticking with the "Rails Way"—leveraging Turbo and Stimulus—feels like a more efficient and sustainable solution for most use cases today. It’s great to see how the Rails community has embraced these innovations, and it’s clear that, for many developers, this new approach offers a compelling alternative to traditional front-end frameworks for building hybrid apps.