Author of peek here. Honestly, I got burnt out. We stopped using this internally at GitHub for our secondary Rails applications which made it difficult to continue working on. Rails was going through its identity crisis with asset pipelines and I didn't feel like trying to support every available option for people like Sprockets, Importmaps, NPM, Bower, etc. It was nice when there was the paved path and users could generally follow the README and be up and running quickly.
Hey there, sorry if this came across as critique on the project itself or you personally. I get it, priorities change and projects get abandoned by the original maintainers.
My comment was more aiming at the ecosystem at large. Lots of the (RoR) stack in my current day job depends on long abandoned libraries with unmerged fix PRs from years ago and I see this all the time in the Rails ecosystem. Interest in the ecosystem is shrinking and this is one symptom.
It's a fair critique! I still keep kicking the can down the road about revisiting the project and modernizing it. The ecosystem has moved along so much since I last revisited it I'll need to take a fresh look at it, accepting the PRs that are currently open is likely out of the question.
> Interest in the ecosystem is shrinking and this is one symptom.
I think the interest in the ecosystem is still very strong, there is just more publicity and marketing around the newest frameworks and capturing peoples attention. Rails is more than ever the best place to go zero to one, and still scaling past 100M at GitHub.
There are so many libraries that are largely feature complete. For example, Devise doesn't need anymore features. There is some traction of going the more lazaronixon/authentication-zero route which is a generator for owning the code rather than having everything live in a gem. This is just one specific example. Rails is moving more and more third party things in house showing it matured in the ecosystem and can move into core Rails.
I find myself reaching to a gem as a last resort if at all possible these days.
I don't think this is quite right. I've done a survey a few months ago when deciding what to use for a new project (primarily comparing Ruby and Go). What I saw was many people rallying around the top useful libs out there. I also saw numerous brand new libs showing up, fixing mistakes of their predecessors. And each time I compared a popular Ruby project with a popular Go one, I'd find consistent activity from multiple maintainers in the former. And a lot of initial activity that completely dies down in the latter.
The overall feeling I got is that Ruby on Rails has gotten a lot more "getting shit done", "don't waste time" mode, — many businesses depend on it. Libs became higher quality compared to the early playful years.
Rails isn't dead. In fact Hotwire and Stimulus have breathed some new life back into the community. With Rails 7 there's new and interesting changes happening like the normalize method for normalizing data before it's persisted to the database, the new testing coverage, and the new encrypted credentials, which can replace devise as it's easier to extend. STI is still awesome and concerns help DRY up the code. I know it's not the new kid on the block anymore, but if you code into a Rails way of doing things it's still crazy fast for rapid development.
Ruby is a very beautiful language both in logic and consistency. Rails is a mature framework. The ecosystem is very much alive albeit not “exciting” anymore and at the end of the day people use what they know. The 2010s have produced a large number of Rails developers. For the majority of CRUD apps Rails (or Laravel or Django) are just fine thus there’s no need to really make a switch. Finally, React can power a lot of things but in my experience it is far from offering the right integration and rapid development speed that something like Rails or Laravel come with.
> But in 2024 things like react and typescript exists.
Avoiding this stuff is one point on the list. I know I'm being a little snarky, but it's true. If you're building a fullstack app with fullstack devs you can avoid a lot of complexity that stuff brings.
These are nonstarters for me. It seems like vercel has corrupted react beyond recognition, and other full-stack frameworks like Remix just do a lot of `rigamarole` to mimic a fraction of what an older fullstack framework like rails/django/phoenix can do.
frontend is desperately trying to catch up to backend.
backend is trying to capture frontend to seduce people back, and they're getting there with freakishly good UX like phoenix liveview and rails 8's morph.
Rails is practically unusable for anything that requires concurrency inside of serving one request. If you have all your data in the database that your rails app connects to everything is great. If you need to call out over the network to 12 different services to serve your request or want to do computationally intensive things, etc, another language with support for concurrency is a better choice imho.
[1] - https://github.com/peek/peek