Where Rails Makes Sense
Ruby on Rails needs little introduction these days. Originally released in December of 2005, the past several years have seen Rails mature into one of the most powerful web application frameworks around.
It almost single-handedly brought the Ruby programming language into the mainstream, and its presence is seen and felt in many places online.One might even argue today's startup culture wouldn't look the same without it. Twitter began as a Rails app, and many of the web apps and sites we know and use today are either built with it entirely or utilize it for significant slices of functionality. Indeed, Rails has been so successful that it has spawned a number of copycats in other languages. It has also driven changes in other established frameworks.
We at COPIOUS have been using Rails for nearly as long as it has existed, and while we're enamored with its capabilities, using it is not a foregone conclusion. Each project is unique, and choosing the right tool for the task is always of paramount concern.
On the surface, Rails is best suited for traditional web applications. We call Rails a "full stack" framework because it encompasses virtually all aspects of modern web application development. Rails' original claim to fame was that it brought conventions to many of the most common tasks, allowing developers to bypass the most repetitive tasks so they could instead spend more time focusing on the unique aspects of the project. Virtually all modern web apps have to deal with things like generating HTML, storing things in databases, maintaining visitor sessions, processing forms, and so forth. Rails includes modules for doing all of these and many more, with the caveat being that developers generally must play by its rules. While it is open source and can be modified by anyone for virtually any purpose, developers extract greater efficiencies when they follow conventions.
Rails is remarkably well-suited for a wide variety of applications. While each project is unique, the underlying technical requirements for many or even most can be surprisingly consistent. In most cases, a standard SQL database will meet all storage needs. Likewise, Rails' built-in templating language will suffice, and it's very easy to swap out if something else is desired. While Rails makes many assumptions and decisions for the developer, just as important are the places where Rails is built to allow the developer freedom. Today, the Rails ecosystem is huge, with thousands of modules available to refine and expand functionality and many options for finding qualified developers, web hosts, management, and so forth. In fact, it is probably easier to list cases where Rails may not be the best fit for a given project's needs than to enumerate the many places where Rails works well.
To that end, there are some specific cases where a developer may not want to use Rails:
Real-time applications
Many web apps are designed to behave more like desktop applications than traditional websites. Some sites today include functionality that allows the server to "push" updates to the browser without requiring a page refresh. Other applications make a large number of requests behind the scenes. In many cases it is better to build such functionality as a slice of an application that sits alongside the "core" application and is specific to the task at hand.
Rails is built to facilitate this; however, sometimes the right tool for the task is written in another language.
Small applications
Just as many websites share common technology requirements, another large swath of websites need considerably less. While Rails does the basics very well, in many cases it's simply heavier than a given task needs. This is an area where smaller, more nimble frameworks like Sinatra may be considered.
Applications that need to interact with closed-source software
While Rails has done a great job of adopting - and in turn, helping developers adopt modern coding styles and best practices, there are cases where using Rails can make things more difficult. If a project will require heavy integration with closed-source technologies, it will often be easier to use vendor-specific tools. It is certainly possible for Rails to work in these projects, but it can lead to situations where the efficiencies gained are nullified by efficiencies lost.
Application types with established domain-specific leaders
While Rails includes a lot of valuable functionality, there are areas that tend to be unique enough from project to project that they have been left outside of "Rails core" - the primary features offered by Rails. For example, ecommerce web applications share many commonalities like payment processing, the taking of orders, and so forth; however, business rules almost always dictate specific needs that require considerable effort to implement. This leads to applications and frameworks designed specifically to address these tasks.
Magento is an example of a web application targeted at this particular problem domain. While it comes with its own issues, so much effort has gone into making Magento a fit for so many common ecommerce applications that it is often better to use it than to effectively start from scratch with Rails. The flip side is that many ecommerce applications are so small that using something like Magento can be seen as overkill.
Static Websites
Rails is a web application framework - not a static content framework. While it is certainly possible to use Rails functionality to build static content websites, it is best suited for web applications with dynamic functionality. If a site is primarily static content, offers little user interactivity, and has no particular needs from a data storage perspective, it is generally advisable to use off-the-shelf content management systems like Expression Engine.
We at COPIOUS choose Rails for many of our projects. Our engineers have deep experience with the framework and can generally bend it to meet virtually any need. Rails is a great choice for many apps because functionality is constantly evolving, and both Rails and Ruby are designed to facilitate developer productivity. Emphasis on practices like Test Driven Development helps ensure quality and robustness.
The decision of which technologies to use on a project should be dictated by the specific needs of the project. For many, Rails is a glove-like fit.