History of Ruby on Rails

Many web-based software systems contain a number of common types of components and functionality.
Calling application code based on HTTP posts, performing database transactions, rendering HTML
responses, and putting all of the system’s functionality into a scalable, extensible architecture are all common concerns in these applications. Because of the prevalence of web applications in today’s world, these problems are faced by many developers worldwide on a daily basis. Clearly, when facing such a task, a prudent software engineer would seek a common framework for web application development that could reduce the need to reinvent existing solutions, create a common base architecture for a number of different applications, and provide a ready-to-go solution for as many of the requirements as possible.

This solution to the problem is not a new one. Frameworks like Microsoft’s .NET or Sun’s Java 2
Enterprise Edition (J2EE) are widely used to satisfy the needs of developers creating large scale service
oriented architectures for web deployment. These systems have been tried and tested many times and are well known for the robust solutions they can provide. Unfortunately, with such a robust architecture seems to come an inherently large amount of overhead in terms of configuration and setup. In addition, there tends to be a large learning curve to understand the architecture and all of its variants. In particular, J2EE has many different technologies that can be glued together within it, including Struts, Hibernate, and Spring.

Enter Ruby on Rails. Ruby on Rails is an open-source web application framework designed to make the
job of the developer easier by providing everything one needs to create web-based, database-driven
applications easily while focusing on the idea, not the technology behind implementing the idea. It is
designed to be a marriage of the “quick-n-dirty” camp of PHP web developers and the “slow-n-clean”
methodologies of the old enterprise architecture crowd. Many proponents of the framework will be quick to tout quotes saying that it can make developing web systems ten times faster than performing similar tasks with competing, more complex frameworks like J2EE.

Rails was developed while its creators were building a real life system with it. This allowed them to test
out their ideas as they were putting them in to production, along with allowing them to drive the
development of the framework based on the actual needs of a real project.

The creator of Ruby on Rails, David Heinemeier Hansson of 37signals, will tell you that some of the
framework’s power comes from the fact that it follows the mantra of “convention over configuration.”
This means that instead of allowing an ultimate amount of flexibility in what a developer can do with a system, there are limits imposed. While this may sound like a bad thing, it actually allows for a much
easier time in creating the types of solutions that it is specifically designed for. In David’s words, “If you
are happy to work along the golden path that I’ve embedded in Rails, you gain an immense reward in
terms of productivity that allows you to do more, sooner, and better at the application level.” Basically,
because assumptions are made on the part of the framework about how the developer will be doing things, the developer doesn’t have to tell the framework how those things will be done. This means less time spent writing configuration files and more time working on the idea of the product.

A high-level view of the Rails architecture makes it look very much like other web application
frameworks. Its architecture is based on MVC, designed to separate concerns and reduce the coupling
between disparate functionality. Part of Rails’ power comes from the fact that this architecture is
connected through an auto-generated code base structure. The developer can set up a project and then
make changes to the model directly and observe the results without a lot of work to set up every part of
getting that data propagated throughout the rest of the system.

The entire benefit of using Ruby on Rails is in many of the small things it does to benefit the developer in
ways that other similar frameworks do not. These little things collectively work together to create a
development experience which overall seems much more agile and less cumbersome than the process
involved in working with other large and robust web development architectures.

In mid-2003, a small web development firm called 37signals was starting development on Basecamp, a
web-based project management tool. For several years, they had been using PHP for their applications
and trying to build up a reusable framework.
Unfortunately, their PHP framework failed to provide maximum productivity, and the programmers were
growing increasingly frustrated with their development experiences. PHP offered a quick and dirty approach to web applications, but 37signals was rapidly pushing the limits of what PHP reasonably
accomplish. On the other end of the spectrum, J2EE offered a slow and clean approach. The approach
was too slow, however, and unreasonably complex. In order to combine the best of both worlds into a
quick and clean approach, a new framework was needed. This framework would facilitate rapid
development with a focus on producing results, while also incorporating design patterns and best
practices.

Basecamp would be 37signals’ first product offering, and the project marked their transition from
consulting to product development. It was clear that if the company wanted to deliver an effective
product line without significantly expanding their resources, they would need a software platform to build on.

As a result, two primary goals emerged. First, 37signals needed an extensible, modifiable web
application framework that could be used to create Basecamp and future products. The framework would
promote code reuse and provide libraries of common functionality. Second, the framework itself needed
to make development enjoyable for the programmers, making the programmers extremely productive.
With increased productivity, 37signals could accomplish more work without hiring more developers.

To achieve the second goal and provide a starting point, Ruby was chosen as the programming language
for the web framework. The dynamic, powerfully expressive nature of Ruby along with its extensive
metaprogramming features ensured an enjoyable, fruitful development experience with plenty of
flexibility. By designing the framework to take advantage of Ruby’s unique traits, a clean productive
development was guaranteed.

Since Ruby was selected and established as a foundation, David could then address his first goal of
creating an extensible web framework. However, he did not build the framework upfront. Instead, he
proceeded to build Basecamp, and the framework that grew out of Basecamp became Ruby on Rails.
Unlike web frameworks like J2EE and .NET, which were developed to specifications designed to suit the
needs of all possible users, Ruby on Rails was extracted from a complete product. As a result, the
framework reflects the real needs of a real project, and contains no extraneous or unnecessary features for the average developer. Thus, when developing a future 37signals product, David could reuse Rails,
without being hindered by unnecessary components, and spend most of his time focusing on application
specific functionality.

Despite the fact that Rails began as a proprietary framework, a decision was made to avoid including
business logic and application-specific features. Originally, the scope was constrained simply to make the framework manageable and to guard against feature creep. When Rails was publicly released as open source, the lack of business logic left the framework as a powerful, general solution that the majority of programmers could reuse.

From its inception, the Rails framework has been driven by pragmatic, minimalist decisions. It uses
proven techniques from real-world applications, meaning that the framework is a reflection of the way
programmers actually work.