After reading a blog post provocatively called “Today I accept that Rails is yesterday’s software” I felt the need to reply. I’m not sure why, I’m not going to convince anyone of anything, definitely not the author of that post. I want to reply because Rails is my current platform of choice, and let’s be honest, seeing a blog post with a title like that getting passed around makes you squirm a little. I think it made me squirm in a good way, because it caused me to step back and evaluate what I’m doing, and why. Enough with the back story, on with the show…

It always comes back to the tools. Everyone blames the tools. And there is good reason for that. Tools empower us. Tools hold us back. Tools excite us. Sharp tools allow us to stab ourselves. Dull tools don’t allow us to get much done. Some tools are optimized for safety. Some are optimized for speed. Some tools are optimized for flexibility, others push you down a happy path. But at the end of the day, they are tools. The only value they have is in what you can create with them. Your tool can be safe, efficient, shiny, but if no one uses it, it is just a dead lump of code.

These tools we have allow us to create amazing things. Many of these tools are quite complex. They try to hide a lot of that from us, but at the end of the day, modern web applications are complex beasts. Anyone involved in the creation of a web application knows that there are so many moving parts and pieces involved that it is mind boggling. There is no way you could fit everything you need to build a website into a single framework, even a framework as large as Rails or Django.

And you would never want it that way, everyone needs to do something different. You need a framework that is optimized for what you’re trying to do. The framework is there to provide us with a doctrine and the ecosystem that builds up around it is what makes it powerful.

What are you optimizing for?

Everyone is optimizing for something different. Is Rails a good choice for every shop? No way. Is it a good choice for your shop? I don’t know. What are you optimizing for? Are you a big team that is looking for safe tools which allow you to reliably refactor and give you a lot of compile time safety? Then Rails would be a terrible choice. Are you a small/medium development shop who needs to be able to stand up and maintain an application easily while leveraging a huge amount of community code/knowledge to get that done? Then a framework like Rails/Django/Laravel might be just the thing you need.

Alternatively maybe all of your developers know Python, then go with Django! The whole point is that you should pick tools/techniques that fit your team, don’t just grab the newest hippest tool off the shelf unless it solves some very concrete problems you currently have, or you are going to feel some pain. Maybe a lot of pain. And I don’t mean the kind of hand-wavey “we can do better” type problems, I’m talking about solid technical problems that you can put your finger on.

Looking for something better, or just different?

In the post I mentioned above it sounds like the author has a lot of frustration with his tooling. I’m sure that is something that everyone has experienced. I can’t speak to his exact issues, we don’t seem to have many of the same issues, but that doesn’t mean they don’t exist. Just as an anecdote though, I have often found that developers working in a framework for years get a ‘boiling the frog’ moment where they just accept poor ergonomics in their environment for years until someone new comes along and points them out, or they just lose their mind and flip out. Once you look for a solution, you’ll often find that it was a problem in your workflow all along, because more often than not, broken tools don’t stick around in the open source world. Can’t say the same thing for other ecosystems though.

The whole point is, don’t throw out the baby with the bathwater. These frameworks are complex. Software is complex. Sometimes they don’t play well together, but if you’re running into silly problems with your tools then you should be looking for solutions, not to throw everything out and reboot. If you’re a consultant, then those types of reboots can more easily occur, and are often very lucrative, but they are rarely good for your clients.

My problems aren’t your problems.

I constantly find myself waxing to other developers about how we, as a group, seem to be stuck in the mindset that all developers have the same problems. The tools and frameworks that Facebook, Twitter, Google, etc… use must be the best, and because I want to be the best, I must use them. Well guess what, you don’t have the same problems they do. They have a virtually unlimited amount of developer time, you probably don’t.

Would I ever tell you to not use Elixir/Phoenix, Node.js, Revel, Iron, etc…? No, of course not, I don’t know what your problems are. But what I would tell you to do is to thoroughly evaluate each one based on your needs. What libraries do you need? What are you willing to write yourself? What is the longevity of the tools? What tools are available to you for deployment/hosting/management/troubleshooting? What is the skill-set of your team? These are all critical questions to ask when evaluating a platform, and if you’re not asking them then you probably don’t know what you’re getting yourself into.

Yesterday? Today? Tomorrow?

Is Rails yesterday’s software? Sure. So is PHP. So is C#. So is Python. So is every web framework that has come before. It is mature. It doesn’t mean that it isn’t today’s software, or even tomorrow’s. It just means that it has been around for a while. Are there better platforms out there? Depends on what you’re doing. Are there better frameworks for what we do? Probably not. But I don’t know you and your problems, you have to make these decisions on your own. Taking ownership of that is always scarier than listening to a bunch of loud consultants and bloggers proclaiming that they have the future in their pocket.

It takes all kinds.

I tend to be harsh sometimes on developers who always jump on the new shiny tool, but the reality is that we need those people (even if I don’t want to have to maintain their projects). We need the trailblazers, because if we didn’t, there wouldn’t be a trail for the rest of us to follow. If Rails didn’t have those people 10 years ago then it wouldn’t be anywhere near where it is now. It never would have been able to push through those tough early years where running, deploying, hosting, and maintaining a Rails app was a really painful process. This is where a lot of these frameworks are now, and that is exciting. I really hope to see many of them mature into stable/reliable platforms and ecosystems. And one day, for what I do, another framework will pop up that will be a better choice than Rails. And I’ll probably move on to build amazing things with that framework.

But guess what, when that time comes, there will be somebody writing a blog post telling me my new platform is old news and I’ll quietly close my browser, fight the urge to write a blog post, and get back to work. Just like I should have done today.