Ramaze: a Ruby framework that will amaze

Lately the Ruby community has experienced a surge of new web frameworks. Most of them are respectable and promising open source projects created by people who tried to create lightweight but valid alternatives to Rails. Do I think that they will rise to fame just like Rails did? Of course not, but they are not hopeless copycats either, because they express a different “software opinion” while maintaing similar but not identical goals. I think it’s important to give proper exposure to the most up and coming ones. Besides Rails and Nitro, by now most of you will have heard about Ezra’s excellent Merb and _why’s Camping, but would you be interested in the framework with the following characteristics?

• A very welcoming community with the right attitude, down to earth folks, and no prima donnas;
• Lightweight, meaning that it’s not bloated and doesn’t fill the skeleton of an application with a bunch of unnecessary files;
• Very Ruby like, based on the KISS and POLS principles;
• Follows the MVC architectural pattern, but allows you to run everything off a single script if need be;
• Already works perfectly with Ruby 1.9 (and runs much faster with it);
• Faster than Rails, thread safe and well optimized;
• Doesn’t get in the way and has an almost flat learning curve;
• Unlike other frameworks, it’s very well documented with information and sample applications, whose code is browsable through a cool web interface;
• Developed for more than 1 year;
• Very stable with no known bugs;
• Developed following BDD, with extensive test coverage;
• Very actively developed;
• Gaining momentum, day-by-day;
• Modular design that allows for minimal dependencies;
• Supports pretty much any Ruby Templating Engines (Ezamar, Erubis, Sass, Haml, Liquid, Markaby, etc…);
• Supports most deployment solutions (Mongrel, Evented Mongrel, Swifiplied Mongrel, Thin, fastcgi, Apache, Nginx, etc…) since it uses Rack;
• Supports any Ruby ORM (ActiveRecord, Og, Datamapper, Sequel, etc…);
• Ships with JQuery, but can take advantage of any Ajax framework;
• Already used in production for small and large applications;
• Follows a pragmatic approach with several useful helpers.

A framework like this exists, and it’s called Ramaze (pronounced ra-ma-ze, Japanese style, even if the name comes from Ruby-Amaze). This is an example of a complete Hello World application:

require 'rubygems'
require 'ramaze'

class MainController < Ramaze::Controller
  def index
    'Hello, Ramaze!'
  end
end

# Runs mongrel on https://localhost:7000/
Ramaze.start :adapter => :mongrel, :port => 7000	

Pretty straightforward, isn’t it? But don’t let that fool you, if you want an MVC folder structure which is lighter but similar to the one you’d get with Rails, that’s available too through the ramaze command. Even though generally speaking, Ramaze is closer to Nitro than Rails.

An informal interview with Ramaze’s community

Ever since I learned about Ramaze, I found it extremely easy to hack with it, and while of course I mostly use (and love) Rails, I’m very impressed by this little framework, which is hard to criticize in any way. To get a better feeling for Ramaze and its small but friendly community, I decided to informally ask a few questions to three people who are deeply involved with the project. They are Aman “tmm1” Gupta, Jonathan “Kashia” Buch and Pistos. Michael “manveru” Fellinger, creator of the project, read the questions and substantially agreed with the answers which the others gave.

1) I’ve been playing with Ramaze for a few days now and I’m very impressed by the fact that it doesn’t get in the way, an important aspect to which Ruby programmers have grown accustomed to. I’ll start with the first question then. How did you get involved with Ruby programming?

Aman: I first tried Ruby back in 2002 and worked through a few chapters of the first edition of the Programming Ruby book, which was available for free online. I really liked the language, but couldn’t find a place to use it. When Rails became popular a few years ago, I rediscovered Ruby and made the switch from PHP. I’ve never been happier =)

Jonathan: Like many, I came from PHP, but unlike the most I didn’t come because of Rails. My brother discovered it first and tried to convince me to try it for quite some time. I didn’t think it was worth it, “just another language”, not seeing the benefits really by reading the Pickaxe. The first thing I actually did, was writing an IRC bot, which was easy with ‘rice’ (which was quite ‘abandoned’ even back when I started), but seemed impossible to me with PHP. This lib taught me a most valuable skill: being able to read good code and using something without documentation. And, it cleared my head, Ruby is just *SO* much more accessible to my mind…

Pistos: I started with Ruby after reading an article in the April 2002 issue of Linux Magazine. “Write Ruby, Be Happy”, it said – and that piqued my attention. 🙂 I was dawdling around with Perl, and had been doing Java for a couple of years. Ruby just clicked with me, and I haven’t found anything as satisfying and joyful since.

2) Great, so what motivated you to get involved with this project, and what do you think is the philosophy/vision for this framework?

Aman: The more I used Rails, the more frustrated I became with it. I love Ruby’s simplicity and elegance, and Ramaze stays true to those principles. Unlike Rails, there’s no magic required. With Rails, there’s just so much useless junk that comes pre-packaged, a new Rails app contains dozens of files and directories (500kb worth!) and does absolutely nothing!

Given a directory full of Rails applications, it’s almost impossible to distinguish apps that have real code (that’s worth saving) from the empty skeleton directories (that could be discarded). I love that Ramaze is super lightweight. A lot of times I just need to write a simple web-app, and with Ramaze I can do that in just one or a few files. Even with larger apps, I can start out with one file and split it up and re-factor when I feel it to be necessary.

Jonathan: Like our boss (manveru), I was originally a Nitro guy. Rails never really ‘got’ to me, after knowing Nitro first. I watched Nitro grow, and I’ve seen Ramaze grow from its infancy. What was true of Nitro (and is now with Ramaze): If I had only one sentence to describe why I use it: It smells good. Let me say that again, it smells good, that’s basically it. My vision, for where it is going, is closely coupled with where I see the community heading. The current lot of long-term users always strive to _do_ something. They all (at least that’s my feeling) like that the framework stays in the background, allowing them to code whatever they want to. Ramaze goes, wherever the current ‘mindshare’ of the community is. As that, I don’t think it is that important where it is headed right now, it is more important that the community itself is interested in new ideas, unusual topics and that the community does not go stale. Let me give you an example. Ramaze has been stable; it has been feature complete since more than a year. Yet it always evolves, in small steps, like something organic.

Pistos: I met the lead dev (“manveru”) in IRC via a shared interest in Ruby. He talked about the web framework he was working on (Ramaze), and I decided to give it a shot after playing around with Rails and Nitro. Ramaze’s simplicity and ease of use were a breath of fresh air after things like Rails, and I’ve remained loyal to the project since then. I hope to continue making contributions by way of: testing it via actual use; writing up user-level documentation; submitting the occasional minor patch; helping answer questions and maintain the friendly atmosphere in our IRC channel; and spreading the word about it.

3) Merb, Camping and Sinatra, to name but a few, have been receiving a lot of attention lately. How does Ramaze compare to them and why should a Ruby developer adopt it instead of other alternatives?

Aman: This is one of the things I love about the Ruby community, the variety of approaches and options available for any given problem.

First of all, I would definitely encourage everyone to explore all the web-development options available in the Ruby community, and to use the one that is the best solution for their problem. I believe we have the most comprehensive list of these frameworks at https://ramaze.net#other-frameworks.

As I used Rails for various projects, I discovered that I was using less and less of its bundled functionality. I prefer using jQuery for javascript and Haml for my templates, which means I have no use for Rails features like rjs and helpers such as link_to_remote and form_for. With Ramaze, you can choose your own templating engine, ORM, javascript library and only include the helpers you want to use. This leads to a simpler, less bloated framework that stays out of the way as much as possible, and lets you, the developer, decide what solution is best for your project.

If you like the Rails way of doing things, Merb is a great alternative. Compared to Rails, it’s both faster (2-4x requests per second) and uses less RAM (1/3 to 1/2 memory usage). If I needed to write a RESTful app, Merb would be my first choice.

Jonathan: If you ask me, Ramaze has more in common with Nitro (and thus with Rails) than Camping or Sinatra. Truth to be told: I haven’t actually _tried_ one of the other microframeworks. I have looked at examples, seen source, seen documentation, but I have not actually tried one of them. But I constantly hear good things about them from within the Ramaze community, especially about Merb. Yet, they all did not catch my attention enough to even build a single small app with them. It might not be their fault, but Ramaze (at the moment) is exactly what I want from my framework: staying in the background, providing help wherever it can, making me feel all cozy and rules applying to Ruby, apply to Ramaze too.

4) Would you say that despite being a very lightweight framework, Ramaze would still be suitable for writing large web applications as is happening now with Rails?

Aman: Yep, definitely. Ramaze is extremely robust. Currently we have no known bugs, and are feature-complete. New features are usually added to Ramaze when people make requests. Part of the reason our codebase is so solid is because of an excellent test-suite. In fact, our darcs repository won’t let you commit patches if they break any of our specs.

Jonathan: As far as I know, I have the largest codebase using Ramaze. I built a 12k-15k LoC Ramaze application on my internship for a Finnish company. That application an internal app, managing a middle-class company with its special requirements. Ramaze was a perfect fit for that, and parts of my development with and in Ramaze went back, enhancing it further. Ramaze internally is very clean and can easily be adapted to do anything you want.

Making a framework bigger can (and this is solely my own opinion) end in 2 ways: a) it gets over specialized, it makes it dead easy to create a certain kind of application, but is a horrible match to everything else; b) it gets over generalized, making it a nightmare to configure, making it painful to write small applications or making small enhancements to it. Having a small framework brings something different into play: You might have to code your specialized features yourself. Those needs might make the application (not the framework) slow, unadaptable and very specific. But that is not the fault of the framework, it were your requirements. So, having that small framework makes small applications dead easy (in Ramaze’s case a single file with at least `Ramaze.start` is sufficient) and big applications easy too. Easy (for me) because I like to have the full source code of anything I highly depend on in my head, which means small codebase or written by me.

Pistos: Although we don’t have any Twitter-sized Ramaze apps running anywhere, based on the benchmarks that are shown on ramaze.net, plus the talk of folks in the IRC channel, I have confidence that Ramaze can keep up with any other Ruby framework existing at this time. If we ever run into scaling issues, I think we have a strong enough dev team that they can get on the ball and find a solution.

5) What do you use to test Ramaze?

Aman: We were using rspec until about last week, when we switched over to a
rspec-clone called bacon, written by chris2 (who also wrote Rack, which Ramaze also uses to interface with different webservers). bacon, like ramaze, is very lightweight- only 299 lines of code. The main motivation behind the switch was the fact that rspec does not yet run on 1.9. With bacon, Ramaze’s test-suite now passes on Ruby 1.9. In fact, preliminary benchmarks show a 60-80% speed boost when running Ramaze on Ruby 1.9. I believe we are the first web framework to be up and running on 1.9.

Jonathan: At the moment (for my personal projects too) I’m using bacon. Aman explained that quite nicely, more speed, less overhead, 1.9 compatible. I didn’t exactly care so much for rspec or BDD. It wasn’t so much better than Test::Unit in my opinion, and it felt less like ‘ruby’. Now with bacon that has gone away a bit, as bacon encourages use of normal Ruby idioms (think about why chris2 did not implement a `before_all`).

6) If you were trying to convince someone to switch to Ramaze, what would you say are the most crucial technical features that seal the deal?

Aman: I think the best feature of Ramaze is the number of useful helpers that are bundled with Ramaze. For example, we have awesome caching helper that lets you cache the output of selected actions, or even specific variables within your actions, very easily, and supports a variety of caching backends, including memcached.

Another great example in Ramaze would be sessions. By default Ramaze apps will store sessions in memory, but can leverage the caching backend to store these sessions in memcached instead. We actually don’t have a database backend for sessions (although one would be trivial to write), since in the real world, memcached is a much more ideal way of sharing session data between multiple Ramaze servers.

Ramaze is also fast (check out our benchmarks), and runs on Ruby 1.9!

Jonathan: Like Aman said below this questions: not only look out for Rails or Ramaze, be informed which other frameworks are available. Take the one that fits best to your requirement. If you mean by ‘switch’ ‘switch from Rails’, my answer would be the following: Ramaze uses less memory, is faster, does not require you to create 500 files on an empty project, does not impose a certain layout on you and adheres closely to normal Ruby rules.
If you mean by ‘switch’ just a general ‘switch from my current framework/programming language/programming style’, I have no real answer. An example would be the very much unknown IOWA framework from Kirk Haines. It’s been in production use for years, is dead stable, very fast (way faster even than Ramaze), but its documentation and marketing are non-existent. I don’t believe in following a hype (even if it’s Ramaze) just for the sake of coolness, I need to have a use-case to switch to something new. So, why should you switch?

Ramaze is:

• stable
• currently without any known bugs
• adaptable many kinds of projects/programming styles
• feature rich (many helpers)
• useable with almost any known and unknown templating style
• very configurable (check out the Loggers)

and last but not technical:

• easy to use
• easily modified
• easily understood (at least any part which does not read `Dispatcher`)
• embedded in an interesting and open minded community
• and: Ramaze smells good! ;D

Pistos: I think in terms of all the base features that one would expect from a web framework, Ramaze is feature-complete. There are a few of things that seal the deal for me, compared to my experiences with Rails and Nitro. I eventually got turned off of Rails because I thought their “convention over configuration” motto felt more like “dictatorship over flexibility”. If Rails’ conventions feel restrictive to you, Ramaze will be refreshing.

Another reason to like Ramaze is how easy it is to just get going with something functional, without having to follow along on a tutorial webpage every single time on account of the framework being too complex to remember how to get a base application built up.

One thing I really like about Ramaze is the helpful and friendly dev team. The IRC channel is a great place to get your questions answered, and to learn things about Ramaze, web development, or Ruby in general. Community and dev-user relations are number one on my priority list when it comes to choosing software, and Ramaze’s dev team is great in this regard.

How to get started

I thank the interviewees again for their time and hope that you’ll find this informal type of interview interesting. They are really a friendly group to join. If you’d like to get started with Ramaze, you can read the useful Wiki, particularly the Getting Started page. Also, take a look at the first screencasts, the source code of the examples, and if you wish, join the mailing list too. If this spurred your curiosity towards this project, I highly encourage you to join the #ramaze channel on irc.freenode.net using your favorite IRC client or, alternatively, through this browser-based console. Michael Fellinger will be presenting at the Ruby Fools Copenhagen 2008 Conference, so if you plan to attend give his talk a go.

One last thing, before you go try this fun Ruby framework. As you can see from the official page, they desperately need a nice looking logo and if at all possible a touch of good design for the site too. Things like this shouldn’t matter, but they do. Try to compare the impression that you get from that site with the one that shiny Merbivore.com conveys. If any designer out there wants to step up and help out with the look and feel of this project, that would be really appreciated.