Why we build websites and apps using Ruby on Rails

There are tens if not hundreds of languages and frameworks the developers at initforthe could use when we build our websites and web apps. So why do we choose Ruby? 

Ruby on Rails, or Rails as it's more commonly known, is a server-side web application framework, written in the Ruby programming language. 

Rails runs on a model-view-controller framework (MVC). This framework provides a stable structure for databases, web services and web pages.

The synopsis is that Ruby and Rails apps are: - very stable - lovely to work with - open source - no supplementary costs - as secure as you need it to be - tested to hell and back - easy to get started with

Ruby has been around for yonks - 19 years to be exact - and it's actively maintained and developed. The latest release (at the time of writing this post) was 17 days ago. And it's used in some fairly high profile sites and applications including GOV.UK, Twitter and Basecamp.

Ruby on Rails, more commonly referred to 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.

The fact that this isn't a new platform helps clients to put their trust in the technology. It has history. It's well developed and maintained. 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. 

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. Each and every one will say the same: 'Wow, this is beautiful'. Never thought you'd hear beautiful and programming code in the same sentence, huh?! 

New software developers who are introduced to Rails, often comment that it has a faster development process and nicer structure than other frameworks. These most likely come as a direct result of the 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 and easier to develop on. It's also generally easier to bring in new developers with a shorter induction period.

I'm sure any client will agree that having an app that's easier to maintain and develop will be useful when it comes to adding new features. It often helps performance too!

Both Ruby and Rails are Open Source Software. They're both free, 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 which 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!

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' development 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 breach 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!

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?). And 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.

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 warrant you've wanted some new feature added after it's gone live. I'm also confident that something else broke at the same time. 

That's much less likely to happen with a Rails app. Simply because developers are 'belted round the ear-hole' if they don't test their work; it's embedded in their very being!

Rails in particular has a low entry level. This means it's reasonably straight forward for anyone to get involved in some fashion. From hardened system admins to graphic designers 

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 some 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.