Many people are drawn to new shiny things rather than focussing on things that are robust and reliable. Currently, there are many, many JavaScript frameworks that are vying for attention and another new awesome framework comes out every 3 months. It’s in most developers nature to chase after the latest greatest technology. So what is good for business? Should you be chasing the latest new technology? Why did we choose Ruby on Rails five years ago, and what are the very good reasons to stick with Ruby on Rails in the foreseeable future?
Origins of Ruby on Rails
Ruby on Rails came out about 10 years ago as the “first” MVC (Model View Controller) architecture, database out of the box web framework. MVC architecture meant that any Ruby on Rails developer would know what a custom application was doing because they knew where to look. Having a database out of the box allowed lots of developers to get an application up and running fast because they didn’t have to work through the barriers of setting up a database connection. Before Rails, the option was ‘spaghetti’ PHP applications which had in turn killed off most of the Perl applications that started the internet revolution.
Java, Python and Ruby were all created at the same time. Java was adopted by the enterprise with it’s promise to ‘write once, work anywhere’. The machine which executed the Java language, the JVM, is an awesome piece of technology. Java doesn’t have a huge presence on the web even today. Python was adopted by the Academics but now has excellent frameworks, such as Django. Ruby sat in isolation until Ruby on Rails was born.
So why do we still use Ruby on Rails even though there are many faster, shinier frameworks out there?
Stability and maturity. Rails has been in the software world for a long time now and has proven to be a robust and stable platform. When you have a limited budget, you really want to know that your solution is not going to give you any surprises. So we opt to focus on the project not the technology, and as such, we use a mature solution that we know well with no surprises. We need to be confident in our tools (and experts in them), in order to do what our clients need, as many of our projects are some pretty demanding apps, a lot more complex than a standard shopping-cart app.
On the performance side of things, it’s definitely true that Ruby/Rails isn’t amazing for performance… unless you know what you’re doing. While other languages are certainly natively faster, effective optimisation works wonders in a big Rails app. If you plan ahead and keep performance in mind from the very beginning, rather than an afterthought, Ruby’s performance shouldn’t be an issue. After working on dozens of medium to large applications in Ruby/Rails, I can’t think of one example where the limiting factor was the language or the framework, rather it was the quality of the code. Also, our stacks are built on top of AWS, meaning that it’s quick and relatively cheap to throw more power at an app if it ever does become a problem.
As example, one of our clients has a Ruby on Rails application supporting 50,000 new users per day and over Matenia Rossides0 requests per second (and growing)… Would you consider building an app like that for a major client using a new framework? I’d wager not. Would I build a hobby app with a new framework? Yes, probably. What about an e-commerce/shopping cart app for a client with a limited budget that will run their entire business on it? That’s a hard one…
What about Elixir?
All that said, we are starting to seriously consider Elixir, it’s become one of our favourite topics to argue about. Not because it’s new and interesting, but because it’s fast, concurrent, and quickly maturing and stabilising - Not to mention that the project is headed up by some amazing people that have brought over almost all of the best things from Rails (and none or few of the bad ones). So we’re looking at it, but one of the things holding us back at the moment is the lack of an established ecosystem of gems and developers. That’s not a knock on Elixir; it’s understandable because it’s new, but it means that there’s an inherent risk in going with Elixir (or any new language or framework) for a client project. Is there a library for this feature? Can we guarantee that something huge won’t change in the language/framework necessitating a rewrite? Are there enough developers available for hire that are skilled enough to do really tricky work?
Conclusion
We have one or two upcoming Greenfields apps that we are considering using Elixir/Phoenix for, so it’s definitely in the back of our minds. And our “OpsCare” stack that we have built is deliberately language agnostic, so we don’t have to use Rails. But from a business point of view in early 2016, I think it’s a simple equation: fast to build and deploy + decent performance + stable with no surprises or breaking changes + lots of good developers + lots of plugin libraries + we’re pretty good at it = Rails.
Elixir and Phoenix have the performance benefits, but not the others. It’s likely that they will be the next big thing… but not quite yet.
