There, I said it. Even though most of my professional experience is working in the Ruby on Rails environment, I rarely like to admit that. Not consciously, but sub-consciously I’m affected by the industry notion that Rails is a framework for n00bs and that Ruby can’t be used for anything serious. It hasn’t been my experience, but the Hacker News mindset on Rails eats at my insecurities.
However, hanging out at Railsconf, where I'll be giving the talk How We Made Our App So Fast it Went Viral in Japan, I'm feeling very excited about this 15-year-old framework I use every day.
I am a perfectly capable software developer who can code outside of Rails just fine. But Ruby on Rails is how I stay efficient. It’s what lets me translate what is going on in my brain and turn it into pixels before I lose my train of thought. Rails makes a lot of tradeoffs—They call this magic. It's the things the framework does without making it clear in the file what it is doing. But all technology makes tradeoffs, and Rails remains so lovely for those who use it well.
I’m not a Rails absolutist or apologist—I like to acknowledge its many warts. Perhaps that’s why I don’t introduce myself as a Rails developer. I have always seen our Rails app, dev.to as an eventually not Rails app. Maybe not this year or next, but I feel like eventually it will be the dev.to codebase, a portion of which is based on Rails. But I don’t understand why more people don’t start projects with Rails regardless of their notions of what a perfect finished app looks like. It’s the ultimate starter project software and it can scale as far as you feel like scaling it. In startup land I feel like Silicon Valley moved past Rails because it was no longer fashionable—and lost a lot of productivity in doing so.
I recall a blog post about a new company that had some non-technical momentum which was completely derailed by taking a simple idea and writing it in Go microservices. I cannot remember where I found the post, but the story was telling. They scratched their work and took a week or two with Rails to make up for months of lost productivity overthinking the problem.
Startups should be the ones embracing the fast productivity Rails offers and not rejecting it out of vague future concerns—or fashion.
I got back to Rails in order to create dev.to because I was getting burnt on a complicated application and I needed to get back to an environment where I could wrap my head around the whole thing. What started as therapy turned into momentum because things were moving fast and the website fit the greater project’s needs in that small changes could be implemented in a timely fashion. But speed isn't about being sloppy, it's about working with an opinionated framework that seeks to have all the tools you need remain within grabbing distance when you need them. If you cannot get past the phase in a project where a few people need to be quick and productive early on, you won't have scaling problems, you'll have never-launched problems.
And it’s not just small projects like mine that benefit from the Rails environment. Any large company is filled with small projects—or at least they should be. Rails remains the standard of productivity in most web development environments.
Rails is not the only “simple” framework. There have been many new inspired projects, but it is the most mature simple framework. It’s evolving nicely, staying just behind the bleeding edge of web development and introducing good new features along the way. Rails 5.2 looks nice and I'm happy with the state of things.
I’m Ben and I am a proud Rails developer.
Many times as a mobile developer I have to work on apps without the API ready that was crucial for the feature I was implementing. Either the backend was developed by another team that was not entirely in sync with us or our backend team had no chance to implement those endpoints earlier. For this reason, I was not able to satisfy the Definition of Done but it does not mean that I have implemented the UI only.