react-rails VS live

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

Looks like there are a couple of attempts but my google fu didn't really yield a winner.

https://github.com/while1malloc0/hotwire-go-example

https://github.com/jfyne/live

if that's the case, there is definitely an opening on the market for such tech.

As someone who's been writing web apps since DHTML days, Livewire/Turbo feels like we've finally reached the future.

You can see all those “live-” attributes in a small example above. We just say: “ live-click=’tempUp’ “ and Live implementation makes all bindings to our backend code and makes a websocket call for the appropriate Go handler.

LiveView implementation for Go raised the same type of feelings in me when I went through this for the first time.

And here it is, where LiveView programming concepts help us in a great way. LiveView uses websockets to create a persistent connection between the client and the server, which enables the server to push updates to the client in real-time. This allows developers to build interactive user interfaces that can update dynamically in response to user actions or changes in the application state, without the need for traditional page reloads or AJAX requests. LiveView programming style is based on this excellent Live project that is an implementation of the LiveView approach in Go.

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me. I would use https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion having many years of experience in both kinds of web apps.

I've been working on a Go implementation if you fancy trying it out

https://github.com/jfyne/live

I built it because I love building highly interactive web pages, but the current state of JavaScript leaves me cold. I got really excited when I saw what Phoenix was doing with LiveView and thought I could see the light at the end of the tunnel. There are already a couple of projects also inspired by LiveView (GoLive, live), but I had my own vision that I wanted to realise.