When building websites and web apps, there are tens if not hundreds of languages and frameworks we could use, so why Ruby? I'm going to try and explain what is quite a technical choice in as concise a way as possible.
What this article isn't is reasoning for why we haven't chosen any specific one of the myriad of other frameworks as the base with which we work.
The synopsis is that Ruby and Rails apps are:
- very stable
- lovely to work with
- open source - free!
- as secure as you need it to be
- tested to hell and back
- easy to get started with
A stable platform
Ruby has been around yonks. 19 years to be more accurate. It's stable, actively maintained and developed. Ruby is also a beautiful language to work with. Talk to any developer who has broached more than a "Hello World" application in a few languages, and ask them to take a look at Ruby, and each and every one says the same: 'Wow, this is beautiful'. Never thought you'd hear beautiful and code in the same sentence, huh!
Ruby on Rails, more commonly known as Rails, is a web application stack (platform to you and I) built using the Ruby language. You might have heard of Zend, CodeIgniter (built with PHP), WebObjects (built with Java) or Django (built with Python). There are countless others, but the rule is that a framework is built using a language. Its role is to stop developers from having to reinvent the wheel each time they build an app and so provides a lot of help with common tasks.
Rails is stable too. Its first release was in July 2004. It's also actively maintained (the last release at time of writing was 17 days ago!), and used in some fairly high profile sites and applications (GOV.UK, Twitter and Basecamp all are either built in or owe some measure of their success to Ruby and Rails), which themselves contribute huge amounts of code and value to the community.
What this means is that the website or app we build for you will work well, and won't crash for unknown reasons. When it does, we'll fix it, and write tests to make sure it doesn't happen again; keep reading for more on testing.
Beautiful to look at (yep!)
New developers to Rails often hail it for having a faster development process and nicer structure than other frameworks. These most likely come as a direct result of decisions made when designing Rails which have permeated the community. We talk a lot about "convention over configuration" and "don't repeat yourself", patterns intrinsic in the way Rails developers learn and are taught to write code. What results is usually cleaner, easier to maintain, easier to develop on, and generally easier to bring in new developers with a shorter induction period.
I'm sure you'll agree that your app being easier to maintain and develop on will be useful when it comes to adding new features (it often helps performance too!)
Utopian ideals as real world premises
Both Ruby and Rails are Open Source Software. They're both free as in beer, and free as in speech - you don't pay to use them, and you can do with them as you wish. That's extremely powerful in the world of software development. The result of this is that there are thousands of contributors to both projects, which means it's endlessly improving. Think of Open Source as a kind of political and economic utopia. No, really!
Lots of the tools we've come to rely on when building and hosting websites and apps are open source. They've often been built to scratch one person's itch, but are now used and developed on by so many people. We'll often contribute work we do back to the community, and we use a lot of open source kit.
It's a bit like paying in kind, and for that, we get the benefit of tens, hundreds or thousands of peoples' expertise instead of a small handful. That's how you can do all that fancy stuff on your site for relatively little time and money; we're not constantly reinventing the wheel.
It also has a security benefit too. Imagine a framework you couldn't see. How would you know it was secure, other than the vendor telling you it was? What if a security hole was found, and how would you know it had been fixed? Ruby and Rails don't have that problem. You can always see inside them, fix them, report problems, and in doing so, you're contributing back to the community too. It results in a far more secure platform for everyone (as long as you keep up to date with security patches!)
After all, you don't want your website to be hacked!
A humble, dedicated and helpful community
The Ruby community (like a gaggle of geese, but of programmers) is generally a nice place to be. It self polices issues that arise, and brings to task those that show malice or other bad practice. That's a good thing - it sounds a bit draconian, but it really is needed to keep the community strong and pulling in the same direction.
The guy who created Ruby, Yukihiro Matsumoto (Matz for short) is a thoroughly nice chap, and that's also rubbed off on the community. The mantra, if you will, is Matz is nice, so we are nice. Let that sink in for a moment. The result is a more helpful, friendly, upbeat community than some others - we hear this all the time talking to people coming to the Ruby community from elsewhere.
Because not everyone knows everything (who knew?), it's handy to have a helpful community when it comes to solving some of the more complex challenges we face. That works both ways, and we're regularly helping others too. All in all, your site/app can be up and running faster by harnessing the community spirit.
Tested, inside and out
One of the big areas that Ruby excels in is testing. Again, it's not the language itself, but the community that pushes this ideal. The annals of web development history contain the phrase "I asked my developer for a feature, and everything else broke" time and time again. The mentality of testing everything with automated tests was presented as a requirement when Rails was first released, and so every good Rails developer now writes tests. That phrase has been banished. It no longer applies with Rails.
If you've ever had a website or app built for you in the past, I'll bet you've wanted some new feature or other added after it's gone live. I'll also bet that something else broke at the same time. That's much less likely to happen with a Rails app, because developers -are belted round the ear-hole if they don't test their work- in the Rails community habitually write tests for their work; it's embedded in their very being!
Anyone can get involved (ish)
Rails in particular has a low entry level, meaning it's reasonably straight forward for anyone from hardened sysadmins to graphic designers to get involved in some fashion.
So that's why we chose (and still choose) Ruby on Rails
Ruby and Rails are still the main tools in our arsenal. We do work with a number of others, but these are our mainstay, and they're not going anywhere fast.
We feel it's the best way to turn our client's dreams and aspirations into platforms and applications which in turn allow those dreams to become reality. A utopian full circle, if you will.