A few weeks back, I took a brief look at alternate frameworks to Ruby, i.e. things that weren’t Rails. People seemed to like it. As a result of that post, several people got in touch to suggest a frameworks I may have overlooked. So I thought I’d do a follow up post and share those with you after having reviewed them.

Let’s take a look at even more frameworks you can use to get Ruby on to the web.

Padrino

Based in Sinatra at it’s core, Padrino is a lightweight full-stack ruby framework. Unlike Sinatra, it has some features that are very Rails like, such as a method for generating applications with padrino g project myapp.

Part of the beauty of Padrino is the tooling. With support for many database libraries along with testing and mocking tools, it goes a step further with a drop-in admin interface that is ORM agnostic and comes with scaffolding and authentication features.

Essentially, Padrino is a step between Sinatra and Rails that goes beyond the simplicity of Sinatra and allows more complex applications to grow.

Roda

Another framework winding down the road of simplicity is Roda, created by Jeremy Evans. The goal of Roda is to be fast, DRY, and to work correctly. Using a routing tree, this framework focuses on operating on requests as they are current instead of focusing on asynchronus I/O.

One of the focuses of Roda is to keep your application as clean as possible. Roda limits instance variables, instance methods, and class namespaces in order to avoid possible conflicts. This makes for a streamlined application where refactoring or the addition of new functionality can be done with minimal fuss.

Goliath

Bare metal performance. Rack API support. Simple configuration. These are the focuses of Goliath, a light-weight framework based on Ruby 1.9. While it is a bit dated, Goliath is still useful and can be manipulated to take advantage of more modern versions of Ruby.

With a nod to asynchronous I/O operations, Goliath might remind some people of Cramp which we touched on in the earlier article. The difference being Goliath’s focus on working with alternate Rubies, such as JRuby and Rubinius.

Reel

Reel is a framework built on Celluloid::IO, meaning it is another event based framework. Reel has the ability to use non-blocking connections or delegating to worker threads to perform the normal blocking IO. This is determined by building on Celluloid and its thread handling.

Reel also offers several framework adapters for use in different environments. These include Rack and Webmachine, both of which are helpful when customizing your application for use on platforms such as Engine Yard.

Camping

When it comes to microframeworks, few are as micro as the 4k Camping. With a single file architecture, this framework aims to be more simple and safe than Sinatra and to forgo all the complexity Rails apps have.

Camping isn’t meant for full scale production applications. It’s really something to play around with and get a feel for lightweight frameworks and single page applications. Almost an alternate to things like EmberJS than Rails, Camping is a toy that will help you on your way to learning the larger frameworks.

Rango

Have you heard of Django? Meet it’s Ruby counterpart, Rango. Built primarily for Python developers looking to get into Ruby, Rango looks to bring a familiar feel for those who didn’t start out with Ruby or Rails in mind. Rango does not define runtime dependencies so you can configure the template layer as you feel fit for your application. This means your environment is configured with just what you need, cutting down on dependency overhead.

Rango (like Django) wants to keep the focus on simple code that is easy to follow and relies on explicit code instead of having things happen “automagically”. This framework may require a bit more code work to get up and running, but once there, debugging should be a breeze thanks to the built-in tooling and familiar testing and reporting apparatus.

Conclusion

There are likely many more frameworks we can talk about. Rails is still the major market share but as developers discover alternatives many realize it’s about the tool that fits the job, not the biggest tool in the toolbox that matters.

P.S. What are your favorite alternative frameworks? Perhaps we’ll do a part three of this series! Let us know below.