Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news.

Mack: A Fast, “Best of the Rest” Web App Framework

By Peter Cooper / April 11, 2008


Mack is an interesting new Ruby Web app framework (of which, as we know, there are many!) that takes some of the best elements of other Web app frameworks (including Rack support!) and presents itself in a very modular, "agile" way. Developer Mark Bates gives the inspiration for Mack's development as "portals" and says that a lot of Mack's development will be focused on this, including features like a distributed routing system and interoperability between multiple trusted, local apps.

I've personally used Mack (along with jQuery) in the last day or two to develop a chat client. It's worked out very well. Mack is very fast and very light, but offers a familiar Rails-style directory and file structure. I chose DataMapper (one of many options) for my ORM, and it worked seamlessly. Mack also has thorough documentation.

Mack is certainly worth a try if you're either a Web application framework junkie or looking for something that's modular and fast and won't be too alien if you're already familiar with Rails.


  1. Aman Gupta says:

    Are there any example apps online? Is the source for your chat client available?

  2. Peter Cooper says:

    Not sure on the first question. No to the second question. It really was just a very scrappy playabout :) Not even sure if I'll ever make it live!

  3. Aman Gupta says:

    I can't seem to find a hello world, or any other simple blog/wiki/etc examples.

  4. Peter Cooper says:

    One problem is that it'd be different depending on what ORM you used.

    However, just from my limited use, the directory structure is nearly identical to Rails (app, config, lib, log, public, test, tmp and vendor), and the files in their default state are similar but a lot "lighter". For example.. config/boot.rb is just:

    require 'rubygems'
    require 'rack'
    require 'fileutils'

    gem 'mack'
    require 'mack'

    The routes file is simpler. The environments files are YAML files instead of Ruby (and empty by default). database.yml is the same.

    Views work in a similar way to Rails. app/views/whatever/index.html.erb, etc.

    No /script folder as everything is handled through Rake tasks.

    Just imagine a stripped down Rails really.

  5. Peter Cooper says:

    But, yes, there is probably a lot more the developer could do about documentation and example (true for every project, even Ruby itself!) and hopefully this post will get enough people interested that it gets produced :)

  6. Mark Bates says:

    Peter, thanks for the great review! I'm a huge fan of the site, and I'm enjoying RubyFlow even more these days.

    Aman, You can find a blog demo here:

    It's from an older version of the framework, but it's still good. The source can be found here:

    By the end of the weekend I'm going to have the next version of Mack up which will feature migration support for ActiveRecord and DataMapper. I'm also working on a distributed routes demo app, but it's not quite finished yet.


  7. Aman Gupta says:

    Thanks Mark. You mention that Mack is suitable for "distributed, portal-like applications".. could you elaborate?

  8. Mark Bates says:

    Aman, in the current release there is support for distributed routing. That means that multiple apps can share their routes with the other apps. This means that all your apps can be aware of each others routing, even if that routing changes. Something that I think is pretty dang cool. I've rewritten the distributed routes stuff in the next release, 0.4.5, due out in a few days. It's been rewritten to use Rinda. That's the first of many distributed features that are going to be built into Mack.

    Mack is going to include a bunch of helpers, and services to make dealing with distributed apps easier, including automatic searching/retrieval of unknown services.

    As far as portal stuff is concerned, I haven't put a lot of stuff in there just yet, but there is a render(:url => "") allows for in the inline rendering of a webpage. It allows for all the REST verbs, and a parameters, etc... In a future release this method will be smart enough to know 'local' requests, and handle them accordingly. There'll also be a 'portlet' registration system that will allows you to wrap this render type with standard parameters that always need to be passed, as well as other attributes.

    It's a young framework, and there's a lot to be done. If you've got some good ideas for features, I'd love to hear them. You can find the code at if you want to contributed.

    Hope that helps.

Other Posts to Enjoy

Twitter Mentions