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 optimization works wonders in a big Rails app. If you plan ahead and keep performance in mind from the very beginning, rather than as 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 400 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?
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.
Tips on Adapting to Remote Work
Reducing Developer Friction With Rails 6’s Actionable Errors
What makes a good developer a great developer?
reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.
We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.
Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.
The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.
The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.