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.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
Great article. Totally agree
Would you sincerely recommend a rail stack to someone just starting?
I think there are many frameworks out there that can do what your team is doing but you are correct in that you should stay using Rails if that is what the whole team knows and works best in. I also think you should probably be still learning new languages and frameworks because you never know, you might be missing out on even better tools. They all have issues though just like Ruby and Rails, nothing is ever a perfect fit.
“Everyone blames the tools. And there is good reason for that.”
It’s because when I keep everything else the same (team, requirements, etc) and change just the tool, and the results change, it stands to reason that it was probably because of the tool.
Insights are very astounding. Couldn’t stop until reading the last word.
“it stands to reason that it was probably because of the tool.” – @Tim
Correlation does not imply causation, and we all need to be a little more clear about it, and we also need to understand our reasons for changing tools.
What if you were using [stack], but your entire team were better [language] developers which said stack was not written in? Changing stacks to something your developers were better at would improve results, but is that because the tool wasn’t good as it’s job or simply not the right tool for your team?
What if the problem you’re trying to solve is better solved with another tool? Sure that makes the new tool better, for that problem, but dies it make the new tool better for all other problems?
I’ll also admit, often times the tool is the problem. Sometimes it was great and (de)evolves out of relevance.
That said, most of the articles I read describing why a tool is bad are usually opinion pieces written from a single perspective, not inclusive of other use cases. This in itself isn’t bad as long as that’s made clear, but so many people assume their perspective is the only/best one.
I started programming in art school, where they mostly taught Lingo the programming language of Director. While I was in school Flash started to be included in browsers and I learned ActionScript because there wasn’t enough jobs programming Lingo and Flash was easy. I have mostly done some form of graphics programming since but in this relatively short amount of time (16 years or so) I have seen technologies go from hot future technologies, to building a career off of something that seemed stable, to needing to come to terms with the idea that there is no future and I need to move on.
The thing is, some people can’t move on, they invest too much and they become stuck because their life is defined by all they have learned to that point. This relationship will hold true with any community of people that have invested large amounts of their time in something. There will always be Fortran developers. It is a great language and large stable projects have been created in it. These projects were built with a different idea of what is important. More modern technologies don’t align with these old ideas.
Being a Rails developer for the foreseeable future wouldn’t be a bad thing. There is nothing wrong with this and you are right we need these people, but you have to understand that as time goes by others will slowly build stronger arguments about why their new technologies are superior. The more you close your blinders the less you are opening yourself up to learning what will one day be the future.
Awesome post. Thanks Justin
Being a Rails developer for the foreseeable future wouldn’t be a bad thing. There is nothing wrong with this and you are right.
You hit the nail on the head – great post, Justin!
Especially for people starting out, it makes so much sense going with a framework/toolset that’s well established and has a huge open source knowledge base, just like Rails.
Leave a comment