New clients often ask why we use Ruby on Rails to build web apps. Unless they know a Rails developer, they probably haven't heard of it. And Rails developers usually have very strong opinions about Rails.
Oftentimes clients' questions about Ruby on Rails are thinly veiled concerns: does Rails perform well? Can it scale with my business? Is it easy to use?
The truth is that Ruby on Rails is incredibly similar to many other MVC frameworks in many programming languages. There's plenty of online documentation, community support, and available libraries to simplify common tasks, much like what exists for most web development frameworks.
Could we use something else? Sure! In fact, we do use other languages and frameworks from time to time, typically when helping clients salvage existing projects they started elsewhere. We've even built expertise around other frameworks because it was the best decision for our clients.
When we have the option, though, we reach for Ruby on Rails to build new web apps. Our development team is quickly productive on new projects thanks to its capabilities and our deep experience with Ruby on Rails.
Our Rails experience
I first tried Ruby on Rails in 2012. At the time I was mostly using Java's Spring framework to build web apps, and had previously used a few PHP frameworks. Ruby's syntax felt intuitive. Ruby on Rails, as the framework's website claims, is optimized for programmer happiness. As any Enterprise Java developer will tell you, this is a marked departure from some web development frameworks.
Rails takes a "convention over configuration" approach.
Once a developer learns the conventions, they quickly become productive in Rails. This was certainly the case for me.
Initially, I felt like many things in Rails happened by way of magic. Other frameworks I used had their own conventions, but did not shy from requiring plenty of configuration to get things running.
Within a few weeks, I felt more than comfortable in Ruby on Rails: I wanted to use Rails exclusively. A decade later, I still prefer Ruby on Rails over any other web development framework I've tried (and I've tried a lot).
But all of that is only interesting to developers: who cares about how the sausage is made?
Delivering results for our clients
When we build an app, we prioritize attaining our clients' goals. Our clients want great products, not necessarily technological marvels that programmers fawn over. The Rails development experience lends itself to achieving results.
Rarely do we find ourselves muddling around in Rails, trying to figure out how to make a feature work. With Ruby on Rails, we know how the feature should work. The framework's conventions give us a straightforward roadmap with sane defaults for most features. That means we can focus on features themselves: building a frictionless user experience that helps our clients attain their goals.
Ruby on Rails has immense community support. There are open source libraries (gems) for most popular third-party services, making integration with those services as simple as possible. Community-driven knowledge bases enable developers to accomplish practically any task with Ruby on Rails. This means that we can use Rails to build almost any feature you might envision for your product.
Our experience with Rails translates into product reliability as well. We have used Rails to build dozens of production applications, so we know more about how those applications work than we know about any other app development framework.
In other words, when we use Rails to build your web app, you get the very best of our web development expertise applied to your project.
Web app performance
When Rails was first released in 2003, it was criticized for its performance. Rails apps were noticeably slower than other web apps. Ruby is an interpreted language, which is naturally slower than compiled languages. However, the performance of the Rails framework and Ruby itself have both significantly improved over the past two decades.
In practice, we have seen no meaningful difference in performance when comparing resource utilization between Rails and other non-Ruby frameworks for our real-world applications.
There are also numerous ways to optimize performance when you do hit a performance bottleneck, regardless of language or framework. There has yet to be an application we've built where any modern framework—Rails, Laravel, or otherwise—has hamstrung app performance.
Typically, what developers dismiss as framework-specific performance woes are due to other issues in the app.
For example, excessive database queries, memory consumption, slow disk access, or expensive network requests are much more likely to cause performance issues than your choice of framework. None of those issues are Rails-specific, and all of them have solutions (caching, query optimization, etc.).
Popularity and transferability
A few clients have wondered how building their product in Ruby on Rails might impact hiring efforts for their own in-house team. We know that outsourcing to our team is rarely a permanent solution for smaller organizations, and clients deserve the freedom to take their product in-house or to another agency.
Experienced Rails developer availability is dependent on your local job market. In Nashville, for example, experienced C# developers are more common than Ruby developers due to the prevalence of healthcare companies in the area that rely on C# applications, but it's still possible to hire people with Ruby on Rails experience. Ruby on Rails is also easy for an experienced web developer to pick up within a few weeks. Most modern MVC frameworks (.NET, Spring, Symfony, etc.) share design patterns and concepts that are very similar to those of Ruby on Rails.
Our first-hand experience tells us that newer developers can learn Ruby on Rails, too: it's the first framework we introduce to our developers when they join the team. Twin Sun was the first professional programming job for some of our developers, and those team members learned Rails fundamentals in a matter of weeks.
Our compliance with standard Rails conventions—coupled with other practices of ours such as automated testing, continuous integration, and documentation—make the process of transferring a project to your in-house team very straightforward. If a developer knows Rails, they already know how our projects work.
Our Rails apps give you a head start
When we start a new web app project, we don't use the bare-bones app template provided by the Ruby on Rails maintainers. Instead, we have built our own base application to speed up development of the most common features we see in new apps.
Things like user login, authorization, and email notifications are generally the same across most apps. Those capabilities are baked in to our base app. Things like login screens still need to be designed for your app, but the core functionality is there as soon as we start the project. Our clients benefit from us using these core features that have been tested and proven in dozens of other apps.
Rails works well for us
Do we have to use Ruby on Rails to build a new web app? No, there are plenty of other tools that can get the job done, and we've used many of them.
However, we have invested our time and effort into building our expertise in Rails. You can take advantage of our expertise and build your web app with confidence.
Top comments (0)