This is the first post in a new "flare tag" we're trying out: #healthydebate.
This tag is a place to create posts with the expectation of a debate. If you enjoy debating software topics or watching in on others debate, you might like this tag. I also hope it will encourage more disagreements to congregate in places where everyone has opted in with the understanding that this is a debate.
Of course, everyone must remain respectful. The code of conduct is important and always enforced throughout the whole site.
Have fun!
On to my topic: Rails is doing awesome!
The ecosystem around Rails remains incredibly strong, and the organizations involved will push the tech forward.
This announcement got me particularly excited:
GitHub being on the bleeding edge of Rails is HUGE. Shopify has been leading the way of late, and I feel like this new involvement will push things even further ahead. Rails has done a great job of staying conceptually aligned and avoiding feature creep and complexity creep.
Whether or not you like the Rails API, the ecosystem remains strong.
Ruby is a weird choice for sprawling web frameworks, it sure seems like a toy scripting language, but things have just worked with Rails. The humans involved have pushed things forward.
Rails remains one of the best choices and is only getting stronger. Feel free to debate me on this!
Others are welcome to take on this debate on my behalf. It's a community debate. I'm not sure how much I actually care to take part in the conversation. We shall see. 😋
Happy coding!
Top comments (44)
What i love the most about Rails/Ruby is the top-notch quality of documentation.
I don't know how good your favorite language is, what i care first is documentation.
Because without good documentation, how good knowledge can be shared and improved ?
I've been doing Qt in the past and title of top notch documentation (in my personal opinion) is still with Qt.
With Rails you have to read up comments and issues on GitHub.it feels like documentation is a bit behind from actual usage...
I also feel like error messages have been really improving over time.
I said this thing by having little experience with "non-toy languages", what i see is non-existing or very bad quality of documentation. They said: Type is documentation. It's not an excuse for not having a good documentation to welcome and share knowledge among community. It made me sad.
I've always like Rails a lot but its always been a chore to configure and host it for a production environment with Apache/Other Webserver. Has this part been improved any lately?
Though maybe the answer is DigitalOcean:
digitalocean.com/community/tutoria...
I think it has improved a lot, but I agree that this is still not a strength.
Rails can also be a real pain to get setup in development if anything goes wrong especially outside of the Mac ecosystem.
What does dev.to use for its production setup? I've used Apache2 with the Passenger Apache module and RVM. I then use Capistrano to deploy new releases of the Rails app.
Works well once I figured out how to get it all working, but has me concerned it will be hard to re-create when I have to update the operating system down the line.
For what it's worth, I've had a positive developer experience with Linux.
They run on Heroku using puma
We run on Heroku using Puma because several years ago I was pulling my hair out trying to get my Rails server working and found Heroku and got everything set up in about ten minutes.
Haven't looked back since. Others in the industry have caught up to Heroku in this regard, so I can't say I'm hooked for life, but I've defaulted to them ever since. So when this was a solo project I just went with what I knew.
I agree with Dave.
I use
rbenvfor Ruby version control on Linux where it has been a joy to learn Ruby/Rails.😄 A shout-out to ActiveStorage! Rest in peace paperclip, carrierwave and others 💀
I love ActiveStorage too, I use it on my personal website and on all new projects at work.
But one major shortcoming I found, and something I hope will be addressed/changed in future versions, is that images cannot be cached by CDNs. I have CloudFront and CloudFlare caching static assets, but I had to exclude images because ActiveStorage generates 5 minutes-lived URLs from the backing service, and after 5 minutes if the cache tries to refresh itself it returns a 404 error.
As you can see in this issue on GitHub, it is a common concern.
Yeah I faced the same issue with no success :(
How did you work around it?
Seems like ActiveStorage was planned for files rather than for images :/
Well... I didn't ahah
We're just avoiding caching images, inefficient but at least it works. I hope they'll fix it soon
dev.to is still on carrierwave 😱
Promise we'll get to 5.2 soon!
Carrierwave is still much better than ActiveStorage in some circumstance. You don't need two extra queries to get assets of an object, f.e.
Even though I am pretty anti big framework, a part of me wants to live in that kind of ecosystem for the fun of it, loads of people cant be that wrong huh
The last biggish framework I used was a while ago when ASP MVC came out
Do you have any recommended reading material for someone who's been programming a long time but not done a lot of ruby and basically no rails?
Back when I did this sort of thing, it was the Hartl book that was always recommended.
Wait, you're not going to break up Dev.to into microservices anytime soon?
Why would they, I see no real benefits in turning this website into microservices.
It is a rather small-focused platform, with a small team developing it and no real concerns in terms of scalability.
I was being facetious. There is nothing wrong with monolithic apps.
We worked with a few consultancies leading up to the open source announcement, mostly for a security audit.
I recall one convo where I was describing the system and I said "it's a Rails monolith", and their immediate automatic response was "so you'll want help breaking it up into microservices".
I was like "What, no! I love our majestic monolith". We do use a handful of external services (ours and SaaS), and none of it makes our process simpler. If anything we want to pull more stuff into the core codebase over time.
There are a lot of valid architectures, and monolith is absolutely one of them.
It is amusing to me because a microservice architecture is just a monolith broken up into smaller apps. For a startup, it makes no sense to put the extra planning and context switching onto the team just to have a more trendy setup. As DHH said, embrace the majestic monolith!
I'm a frontend dev who just started building with Rails. I haven't had this much fun since I learned React.
I love how quickly you can scaffold apps. The community is also very welcoming.
@tux0r I take you for a Rails non-believer.
Fairly common here, especially among web companies that sprang up between 2008 and 2015 or so. I think it's definitely fading as a popular starter choice. Node, Go and Elixir definitely took a huge bite out of its popularity.
I think to embrace Rails one needs to embrace the "manifesto". I was learning Ruby and Rails a few years back and decided to give up just because it was too magical and its convention was very "dictatorial" to me. I went straight back to Python.
As I've grown more as a developer and had a few more languages in my toolbelt, coming back to Ruby and Rails wasn't so bad. Things started to make more sense and fall into places. (Symbols make sense to me now that I've known Clojure. Lack of parentheses aren't a stranger any more now that I've known Ocaml) I think Ruby (and Rails as a derivative) is a great attempt of an expressive language that's not too mind-bending (as in many functional ones) and yet very simple and even human-friendly.
Reading up the Rails Doctrine by DHH is a pretty good way to befriend Rails. Rails is really pleasing if one can start thinking less about perfection and idealism in a tool and more about shipping.
To be fair, I do see the benefits of microservices in the right scenario.
They allow for small, independent teams to focus on simple, testable and disposable bits of a greater application and this can help reduce time-to-market and embrace continous delivery when building complex and intricated systems.
I worked on a not-quite-microservices-but-still-service-oriented project and it was fun, bits of the application can go online without worrying about the others (we used message queues to decouple them). But it surely was complex to handle and maintain compared to a monolithic application.