Written by Gavin Morrice on April 20th, 2015 16:42
I can still remember how my face lit up with delight at the laptop screen in front of me. This was back in 2008 — I was sitting in my small apartment in Ålesund, Norway. It was the first time I tried Ruby on Rails and I was like a dog with two tails.
I downloaded Rails and started working through some basic tutorials. It quickly became apparent that Rails enabled me to achieve in minutes what would have taken me days to do previously.
Had I known how much of an impact that afternoon would have had on my life, I probably would have taken a selfie.
Today, that friend and I make a living from crafting websites and apps, and we use Ruby on Rails for most projects. In this post, I’ll highlight why.
It’s no coincidence that almost every new tech startup is built using Rails these days. Rails development is fast. To be clear, I mean that the time required to develop a functioning and slick website in Rails is far less than the time it would take if you used another framework, sometimes by orders of magnitude*.
To list all of the reasons why Rails development is more productive than other languages and frameworks is outside of the scope of this post, but I’ll give you an example…
One of the underlying philosophies of Rails is “convention over configuration”. Rails apps come out of the box with a host of pre-set configurations and defaults that reduce the number of decisions developers need to make when writing code. Making fewer decisions not only saves in developer time, but also means developers will make better choices on the decisions that matter — i.e. The inner workings of your application. Reducing decision fatigue is just one of the ways Rails makes developers more productive.
Rails makes all of the routine decisions for you, while giving you complete control to make change those decisions if you want to.
Fast iteration is important for any business, but it’s especially important to startups and small organisations where resources are often tight, and time is really of the essence. Being able to test features early in development reduces wasted time and money. And the less time and money spent getting your Minimum Viable Product to market and getting feedback, the better.
I once worked with a startup that was paying 4 or 5 very high salaries and also kept a lawyer on retainer — you can be sure they were keen to have their MVP developed in as little time as possible.
* To be fair to the Python community, Django is also known for fast development — but comes with other drawbacks.
The Ruby community has a strong culture of developers writing tests for their code. Simply put, tests are lines of code in a project that make sure the other lines of code are working correctly. To non-programmers, the concept of code testing might seem a little vague. But, consider the following scenario:
Your website requires customers to sign up and create an account before making a purchase. Your business decides to start offering SMS confirmation when an order is shipped. Your developer adds the option for customers to enter their phone number in the “My Profile” section of your website. You try out the new feature and it all looks good — you give the go-ahead to deploy the new changes. A few of days later, one thoughtful customer notifies you that they can’t create an account on your website. An investigation of the issue reveals a bug in the code. Now customers cannot create a new account because the system expects them to have a phone number, but there’s no field for them to do so, so nobody can create an account.
Software developers are not perfect. And as a software project grows it becomes harder and harder to keep track of all of the individual rules and requirements. Bugs like this can and do happen regularly, and they could potentially cause harm to your business in lost revenue and goodwill before they’re corrected.
With a test suite in place, your developer would have been alerted to the new bug as soon as it appeared, and he or she would have fixed it then and there.
Writing tests is an integral part of the Ruby on Rails framework. So much so that Rails will automatically generate a corresponding test file for every code file you create. Tools like CircleCI provide even greater assurance that your app is working well, by emailing your team if there’s a test that fails. Every good Rails developer knows the importance of writing tests for their code, and this is a cultural trend that just is not really present in other developer communities.
If your business decides to build a product without testing in place, you can expect spend a huge amount of time dealing with the unforeseen bugs and errors that will result from untested code. This is definitely worth chatting to your developer about.
REST (REpresentational State Transfer) is one of these nerdy protocols that software developers like to argue about.
So here’s what it means in English: Most web services these days are not just stand-alone websites, they also interact with the external world too. An example could be your business’s own mobile app that pulls its data from your website, or maybe it’s another website pushing content to your website the same way Twitter and Facebook do.
Rails, as a framework, is inherently RESTful and makes building a REST API surprisingly painless.
What this means for your business is that, in the very likely possibility that one day your service will grow and have to interact with the outside world, doing so in Rails will make that process far cheaper and faster.
“Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.”
— Former US president, George W. Bush
There are literally dozens of ways to hack a website — and the Rails team never stop implementing new security patches and features to help keep Rails apps secure. Older versions are kept up to date too — which is great for businesses who can’t afford to pay to upgrade their app to the latest major version, but still want to keep their apps secure.
Apart from the obvious benefit of saving your developer the time it would take to implement these security features themselves, implementing security at the framework level helps ensure that security measures are not overlooked — which is particularly likely if your developer is less experienced with web security.
The take-home message for your business is that Rails is a very secure framework used by some of the most at-risk companies online including GitHub and Twitter. Rails is not the only secure web framework, but it is one that draws on the wisdom of a huge global community who are constantly releasing updates to keep it that way.
The Rails community is large and growing, and this is one of the points that really sets it apart from its cousin Django. Django is also a great framework, but has a smaller community of developers. (A quick search on StackOverflow yields 200,586 questions tagged with “Rails”, and only 93,317 questions tagged “Django”).
Software developers don’t like to duplicate their efforts. And since most problems we’ll encounter are not likely to be completely unique, we’ll often turn to online communities like GitHub and StackOverflow to find a solution quickly. There’s almost always a library or gemout there that gets us half-way to achieving our goal — eliminating the need for us to start from scratch.
What this means for your business is that when deciding how to approach a particular problem, or if a nasty bug appears in your application, your developers have a massive community of peers they can call on to help find the best solution, if necessary.
What generally happens when people discuss the benefits of one web framework vs. another, is that people amicably conclude that a developer will always do their best work in whatever language or framework they’re most comfortable working in. Honestly, this is just a beige, lukewarm attempt at diplomacy.
Mark Friedgan, ranked as one of Infoworld’s top 25 CTOs, decided to try out Rails although he was already very competent in other frameworks.
“When we were starting out, we didn’t know Ruby or Rails and could do Java or .NET in our sleep. We budgeted 2 weeks to play around with Rails and if we were still as frustrated after 2 weeks as we were day one, we’d switch to Java. In those two weeks we had built so much functionality there was no reason to go back. The high amount of developer productivity is huge.”
— Mark Friedgan
And when Katana transitioned from writing iOS apps in Objective-C to using RubyMotion it was the same. Of course, the switch was sometimes challenging — we had to learn a lot of new concepts. But the number of work-hours we’ve saved from doing so has easily justified the move.
The reality is, a good developer should be flexible enough to pick up a new framework or language in a couple of weeks. The decision on which tools you use to build your product should be based on how effectively they enable you to achieve your business goals, and not based on which one your developer happened to learned first.
Languages like PHP will stick around for a while yet, because of their sheer ubiquity, but building your tech startup in PHP is the modern-day equivalent of bringing a banana to a gunfight. There’s no real justification in opting to use a slower, inferior framework.
Technology in the world of the World Wide Web moves quickly. I’m certain that one day a new framework will emerge that’s better than Rails, and if I decide to stick with Rails just because “I like it more”, I’ll be left behind.
Ruby on Rails is the most powerful web framework available today and has been a crucial factor in the current tech startup boom — it should be the de-facto choice, at least for now, for any bespoke web application.
While working on a client app, we put together this simple library to make persistence really, really easy.Written by Gavin Morrice—