Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
That's a good question. So, we come from Rails. We actually built Avo (https://avohq.io), an admin gem for Rails, so we can say we have tried it that way.
Avo was first a Rails-backed SPA (Rails server and Vue front-end), and it didn't work out that well. Unfortunately, the Rails community didn't take that lightly, and for a good reason. I won't go into too much bike-shedding here, but the most important reason is that you have to maintain two codebases (ruby & JS).
In January, we re-wrote Avo with Hotwire (the JS front-end suite created for Rails), and it went very well. It's a joy to write apps using Rails and Hotwire.
But the fact of the matter is that we need an app that's a bit more dynamic on the front-end than Hotwire can deliver. I mean, yes, we could weave together Hotwire and a few other JS libraries to get what we need, but we'd get the same two codebases and the same two sets of skills you need to run your app.
The reason we chose to go with React is the ecosystem, mostly (*fun fact; I'm sitting here writing this wearing a VueJS hoodie).
Related posts
- Ready System with a Modern Stack and Many Features Using Ruby 3.2, Rails 7.0 and Avo 2
- What are the cons of using something like https://avohq.io/ ?
- Roast my page: Avo - A low-code tool that helps developers create internal tools, admin panels, and CMS-es with Ruby on Rails
- How to bundle assets in a Rails engine
- Avo 2.17 for Rails - Resource sidebar, native field components, custom policies and more