react-rails VS handbook

The current gem does not help you with this however since it is designed for SPA frameworks. If you wish to take this approach, you can build your own system or use Gems like react-rails and turbo-mount. Turbo Mount uses Stimulus to mount components, and is more robust if you are using Hotwire in your ERB views.

> But what if you want to use React?

Then just use React. There's nothing stopping you and it's well supported.

You can use either https://github.com/rails/jsbundling-rails

or https://github.com/reactjs/react-rails

Personally would also go with a No Build set up. i.e. https://hotwire.io/ and import maps.

One is to add a gem: react-rails or react_on_rails for example. But there is a way to have a simple integration without using these gems.

https://github.com/reactjs/react-rails here is the functionality and simplicity that I would be kind of looking for. The option for it to exist in Django ecosystem is not that outlandish and I wouldn’t be too ignorant of it having to make sense or not make sense to everyone :)

You can however use reactjs with rails, there is a gem for it https://github.com/reactjs/react-rails

The react-rails library is one of the most popular Ruby gems to integrate React with Rails. It provides generators for components, testing helpers, and view helpers to render JavaScript code inside the views.

I'd checkout https://github.com/reactjs/react-rails

As of the writing of my comment, 2 days ago:

https://github.com/basecamp/handbook/commits/master/

37signals went even further, they build products for themselves first:

That's definitely true at the organizational level, and it's an argument with some merits.

In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it!

My preference is to work on mixed-skll teams that can ship a feature independently of any other team. I really like the way Basecamp describe this in their handbook: https://github.com/basecamp/handbook/blob/master/how-we-work... - "In self-sufficient, independent teams".

The link: https://github.com/basecamp/handbook/pull/106

https://github.com/basecamp/handbook/blob/63e97c8210465a5e7f1731eac76e6d9d9e20d29b/benefits-and-perks.md#profit-sharing

No more paternalistic benefits. (Benefits like fitness allowances, wellness allowances, and notably not mentioned in their blog post, charitable donation matching. Instead that's changing to 10% profit sharing. As an aside from yours truly, this means those benefits only will do as well as the company does. Company has a year with a loss? Whoops! No profits to share.).