I first got into Ruby in late 2004, about 6 months after Rails was first released. I think 0.8.5 was the first Rails version I used. I found that Rails made web development much easier than the frameworkless PHP I was generally using for web development at the time.|I used Rails for pretty much all of my web development for a few years, but I gradually got disillusioned by the complexity of Rails.

In July of this year, I was looking at a comparison of a bunch of lesser known ruby web frameworks, and read about Cuba. Cuba has been around since 2010, but this was my first exposure to it. Anyway, as I read about Cuba, I saw how it addressed the duplication issues that I was seeing in my more complex Sinatra applications. From reviewing some benchmarks, I also saw that Cuba was much faster than Sinatra.|After trying to convert one of my simpler Sinatra applications to Cuba, I found there were quite a few things I didn’t like about Cuba, that were easier in Sinatra. I came to the conclusion I should create a new web framework based on Cuba that borrowed many features from Sinatra, along with some ideas I had about extensibility and nonpollution, trying to get the best web framework for the types of web applications that I develop.

As I said, the main feature that separates Roda from most other ruby web frameworks is that it is designed around the idea of a routing tree. Since most programmers are not familiar with the routing tree concept, I’m first going to talk about what a routing tree is and how it works.

Before I can talk about a routing tree, I need to talk about routing in general.

In general, routing a request is the process of taking the request and finding the code that should handle that request. While routing can consider any aspect of the request, in most cases only two parts of the request will be used during routing.

These two parts are both contained in the HTTP request line, which is the first data transmitted from the client to the server during an HTTP request.

An HTTP request line looks like this. Here, GET is the request method, and /albums/1/tracks is the request path. It is possible to use other parts of the request during routing, such as routing using information from the request headers or the request body, but in most cases only the request method and request path are used.

Sinatra and other similar ruby web frameworks look at the full path of the request when deciding how to route a request. The iterate over their array of possible routes, checking each route to see if it matches the current request. A routing tree handles things differently, routing by segments of the path.

When routing a request for /albums/1/tracks, a routing tree is going to look at the first segment, albums. If the /albums segment doesn’t match, it skips the albums branch, so that other routes under /albums are not considered.

If the /albums segment matches, it looks inside the /albums branch of the tree for a route for /1/tracks, ignoring other branches.|Incidentally, this is more or less how a file system works. When you ask a file system to open a file, it doesn’t compare every path in the file system and see if it matches the requested path. It looks at the first segment in the path, sees if it is a directory, and if so, it looks for the rest of the path inside that directory.

If the use of a routing tree was purely a performance issue, it wouldn’t be all that interesting. What makes routing trees interesting is that at any point during the routing, you can operate on the current request.

If any of you have used the Ragel state machine compiler, this is similar to Ragel’s ability to execute arbitrary code during parsing.

Let’s start with Hello World, since that’s the simplest case. This Roda app will return Hello World! as the response body for every request. While this doesn’t show off the routing tree aspects of Roda, it does show that Roda gets the response body from the value the block returns, similar to Sinatra.

In almost all Roda apps, you are going to want to actually use Roda’s routing tree methods. The first routing tree method I’m going to discuss is called r.on, which creates branches in the routing tree. Here, you call r.on with the string albums, which will match the current request if the request path starts with albums. Let me break down what is going on here.

In the first line, we are calling the Roda.route method, which is the start of the routing tree. All requests that come to the web application are yielded to the block you pass to Roda.route. The block is yielded a Rack::Request instance with some additional methods. By convention, the block argument is named r.

The additional methods added to the Rack::Request instance are related to routing the request. As mentioned earlier, the request’s on method is used to create branches in the routing tree. Any arguments you pass to this method are called matchers, and are used to match the current request.|In this case, a single matcher is given, which is the string albums. In Roda, string matchers match the first segment in the request path. So if the request path starts with /albums, this will match, and the request will be routed to the block passed to on. That block returns a Hello Albums string, which Roda will use as the response body.

If the request path is /artists, this will not match, so r.on will return nil without yielding to the block, and execution will continue after the call. In this case, there is nothing after the call to r.on, so the return value of the Roda.route block will be nil. Since the block didn’t return a string, Roda will use a 404 response status code with an empty response body.|This provides the principal of least surprise, where if you don’t specifically handle a request, an empty 404 response is used.

While it works, this code has issues, because it returns the same response for all paths under /albums, including /albums/should/not/exist. In general, that isn’t what you want. What you probably want to do is return a 404 response for any path that you don’t specifically handle.

So if you only want to handle /albums and not any paths below /albums, you can use the r.is method. r.is is similar to r.on, but it does a terminal match, so it only matches if the request path is empty after processing the matchers. So this code will not match the /albums/should/not/exist path.|The reason for the method naming here is that r.on matches ON the route’s prefix, while r.is matches only if the match IS complete.

So routing trees are built in Roda using a combination of the r.on and r.is methods. r.on does prefix matching on the request path, and r.is does full matching on the request path.|If you were routing purely based on the request path, then you could say that r.on creates branches in the routing tree, and r.is creates leaf nodes.|Here, r.on albums creates a branch, handling all paths under /albums.

Here you are calling r.is list, which will match only if the current request path is /list. It may seem odd that this works, but the reason it does is that the request path is being modified as the request is being routed.

When a request for /albums/list comes in, the routing tree uses the initial request path.

When the r.on albums method matches, it consumes /albums from the front of the request path.

So inside of the r.on block, the request path is /list.

r.is matches only if all of its matchers match and the request path is completely consumed by the matchers. Since the request path is /list and that matches the string given to r.is, this request matches and Hello Albums will be returned.

If you get a request for /albums/list/all, the r.on call still matches, but the path inside the r.on block is /list/all. Since r.is list does not completely consume the request path, this request will not be matched, and Roda will return an empty 404 response.

So far I’ve just been focusing on routing using the request path. As I mentioned earlier, routing usually takes into account the request method as well.|Consider this routing tree, which will handle requests for /albums/new.

In order to handle the GET and POST request methods, Roda has r.get and r.post routing methods. If you call these methods with no arguments, they match against the request method, so r.get matches the GET request method, and r.post matches the POST request method.

Here, a GET request for /albums/new will return Hello Albums.

And a POST request for /albums/new will return Album Added.

So the way a routing tree is usually built in Roda is by combining the r.on, r.is, r.get, and r.post methods. You use the r.on method to branch based on the request path prefix. You use the r.is method for doing a complete match on the path, and you use the r.get or r.post methods to handle different request methods for the same request path.

As I mentioned, if you don’t provide any matchers to the r.get or r.post methods, they just do a simple check against the request method. If you provide any matchers to the methods, they also do a terminal match on the request path, allowing for an API similar to Sinatra.|So a GET request for /albums will be matched by a r.get albums,

and a POST request for /artists will be matched by a r.post artists,

but a POST request for /artists/1 will not be matched by either. It won’t be matched by r.get because it isn’t a GET request, and it won’t be matched by r.post because the request path will not be completely consumed by the matchers.

So when you are building a routing tree, if you only want to handle GET requests for /albums/list, and not other request methods, instead of calling r.is list and calling r.get inside of that,

You just call r.get list, which is a more succinct way of expressing the same routing tree.

Now that we’ve covered the the four basic routing methods, let’s talk about the arguments that you give to these methods, which are called matchers.

We’ve already covered one type of matcher, the string matcher. This matches the verbatim string in the first segment of the request path, so it will match /albums, but not /artists.

Strings can contain slashes if you want to match multiple segments in the request path. So this matches /albums/list, but not /albums/1.

You can use embedded colons in your strings, which will match arbitrary segments in the request path. So this matches both /albums/1 and /albums/2.

Note that when you use an embedded colon in a string, the text that is matched by that colon is yielded to the block. In Roda, this is the primary way that data from the request path is extracted for use inside the route handling code.

Another way of specifying the previous matcher is to use a separate symbol matcher, like this. Just as with the embedded colon in the string, it yields the matched segment to the block.

Yet another way of doing it is using a regular expression. With a regular expression matcher, any regular expression captures are yielded to the block.

There are other types of matchers that allow for more advanced matching, but in the interest of time I won’t be going over them.

I mentioned earlier that one of the main advantages of routing trees is that they have the ability to execute arbitrary code during the routing process. This may not sound important, but it is the main reason that Roda allows for simpler and DRYer code compared to most other ruby web frameworks.

If you want to make sure someone is logged in before accessing these routes, you can just put the code that checks for a login as the first line in the Roda.route block.|This provides a similar feature to the capabilities of a global before filter in Rails or Sinatra, so it doesn’t sound like anything special.

Because you can execute code at any point in the routing tree, you can put this check after the routes for logging in. I think this is more elegant than a global before filter that does a login check, which must check that the current path isn’t the login action, or else nobody would be able to login.

This principle of executing code during routing applies at all points of the routing tree. If only certain logged in users should have access to view or update albums, you can have that check near the top of the r.on albums block.

The most common place this is useful is when dealing with separate request methods for the same request path. Assuming that a GET request for /albums/1 will display a form for editing the album with id 1, and a POST request for /albums/1 will process the form’s input, the routes can share code for retrieving the album, as shown here.|Now, this isn’t revolutionary, and you can accomplish pretty much the same thing using before filters in Rails and Sinatra. In both Rails and Sinatra, the before filters are going to be separated from the code being executed, making it harder to reason about.|Also, if you use this pattern a lot, then you need to add a separate before filter for every set of get and post routes you have, which is cumbersome, and on Sinatra negatively affects performance.

Speaking of performance, Roda is one of the best performing Ruby web frameworks. With Ruby’s reputation for performance, or lack thereof, you may think that’s similar to saying Roda is one of the fastest turtles, but it is a much faster turtle than Rails or Sinatra.

For a simple hello world app with a single route, Roda is about 2 and a half times faster than Sinatra. The reason for this is that Roda has much lower overhead than Sinatra.

Now, a hello world benchmark doesn’t really tell you how well Roda will perform in real world applications.

My production applications were always faster using Roda than Rails or Sinatra. How much faster depends on the specific action, with simpler actions performing significantly faster, and more complex actions performing about the same, as most of the time for those was spent inside the action, not during routing.

One pleasent surprise was my integration test suites sped up significantly. The exact same rack/test-based integration tests run 50% faster with Roda than Sinatra, and twice as fast after converting from Rails to Roda.

In terms of memory usage, Roda uses about 10MB memory less than Sinatra in terms of just requiring the library, but in my real world apps I’ve only noticed about a 1MB or 2MB decrease in the amount of memory used.|When compared to Rails, it’s a different story. On the largest app I converted from Rails to Roda, I saw memory decrease from 150MB to 80MB per unicorn worker process, and on the second largest, I saw memory decrease from 100MB to 60MB per unicorn worker process.

My largest app is probably about the size of the average Rails app, with about 200 routes, so this doesn’t really tell you if Roda’s approach scales to large applications. Since I thought this would be useful information to know if I was going to advocate that other people use Roda, I decided to see how well Roda would scale to applications with a large number of routes.

You may be familiar with the c10k problem, which was stated by Dan Kegel in 2001, and said that it was time that web servers should be able to serve 10,000 clients simultaneously.

I’m going to state the r10k problem, which is that web frameworks should be able to handle 10,000 routes efficiently. So I wrote a code generator that generates web applications with 10, 100, 1000, and 10,000 routes for Roda, Sinatra, and Rails, and I benchmarked them.

For 10 routes, r10k generates routes from /a to /j, using a single segment per request path.

For 100 routes, r10k generates routes /a/a to /j/j, using 2 segments per request path.|This approach extends to 1000 routes, which uses 3 segments per request path, and 10,000 routes, which uses 4 segments per request path.|Let’s first look at the results of a comparison of Roda, Rails, and Sinatra at 10, 100, and 1000 routes.

Because benchmarks are worthless unless the source is available for reproduction and criticism, you can find the source code for these benchmarks in my r10k GitHub repository. I encourage anyone to double check my work and make sure I’m not doing anything stupid or unfair towards Sinatra or Rails.

So I’ve gone over what I think are some design and performance advantages to using Roda. However, the benefits Roda offers come at a cost.

And that cost is the loss of route introspection. Because all routing in Roda is done at the instance level, you can’t introspect your routes like you can in Sinatra or Rails. In most cases, this doesn’t matter, but there are some applications that rely on introspection of the routes, and those would need to be handled differently with Roda.

The first routing tree web framework for ruby was Rum, which was written in Christian Neukirchen, the author of Rack, in January 2009. Rum was never released as a gem, and was basically just a proof of concept, showing how you could use a routing tree to route requests.

Cuba was developed by Michel Martens starting in April 2010, and started off as a simple wrapper around Rum with support for haml templates. It’s now expanded to include support for any template library supported by tilt. Cuba was the first routing tree web framework for ruby that was released as a gem, and has enjoyed some modest success, with about 40,000 downloads.

When I first started using Cuba, in version 3.1.1, status code handling violated the principle of least surprise.

If you had this routing tree in Cuba, a request for /albums with no id would return an empty 200 response, instead of an empty 404 response, because the status code was set to 200 as soon as the on albums method matched.|This was a well known issue with Cuba, with a whole section in the README about how to work around the problem, and there was a pull request to fix the issue that had been open in Cuba’s issue tracker for over 6 months. This was eventually fixed in Cuba about a week after Roda’s initial release, using basically the same approach that Roda uses.

The second signficant issue I had with Cuba was that it didn’t have built-in support for terminal routes.

Cuba has no built in equivalent to Roda’s r.is method, which makes sure there is a terminal match of the request path. When you use Cuba’s on method, it only makes sure that the route has a prefix that matches. So this code will match /albums, but also /albums/1 and /albums/should/not/exist.

Cuba’s recommendation if you want a terminal match is to use \z at the end of a regular expression. Let’s just say I didn’t think this was very friendly to the user.

Another thing I didn’t like about Cuba was that it required explicit writing of response bodies, instead of using the route block return value as the response body, which is how Sinatra operates.

Everytime you want to write a response body in Cuba, which is most requests, you have to call the res.write method explicitly. I just think the Sinatra approach is simpler, and don’t think there is a net benefit by making the response body writing explicit. This is one of the philosphical differences between Roda and Cuba.|I was originally thinking I could just work around this issue using a Cuba plugin that made response body writing implicit.

But I found that Cuba’s plugin system was unable to override methods defined by Cuba.

I wanted to write a plugin that just overrode on and called super, and if the on block returned a String, write it to the response body before returning from the block.|Unfortunately, in Cuba this does not work, at least not if you add the plugin directly to the Cuba class, and after speaking with the author, I found that this was by design.|I was used to Sequel’s plugin system, where you can override any method and call super to get the default behavior. It was at this point that I decided to fork, and make sure the fork used a more extensible plugin system, based on Sequel’s plugin system.

Can anyone see the problem with this Sinatra code?

The problem is that the @response instance variable is already used by Sinatra internally, so this clobbers the response variable, and completely breaks Sinatra.|It just so happens that one of the apps I work on deals with a domain object called a response, so using Response as the class name and @response as the instance variable name was the most natural way to express the code.

Because I wanted it to work easily in Sinatra, I had to rename the instance variable to @agency_response. I didn’t like this, because a name like @agency_response indicates to me that there are other types of responses that the system deals with, and that’s not true in this case.

In Roda, all instance variables used internally in the scope of the Roda.route block are prefixed with an underscore, so they won’t conflict with instance variables the user wants to use.

Namespace pollution is not just an issue with instance variables, but with constants as well.

Can anyone see the problem with this Cuba code?

The problem is that even though you are requiring a top level Response class in the first line, the reference to the Response class inside the Cuba app references Cuba::Response, which is a subclass of Rack::Response, instead of the top level Response class that you required.

To avoid pollution of the constant namespace, Roda prefixes all constants inside the Roda namespace with Roda, so the internal classes are named Roda::RodaRequest, Roda::RodaResponse, and so on. This makes it unlikely that Roda’s constants will conflict with your application’s constants.

Finally, Roda avoids polluting the method namespace. With Cuba, all of the routing methods such as on, get, and root, are instance methods in the scope of the route block, so you can’t define view methods that conflict with them.|I don’t want to imply that this is a problem specific to Cuba, since Cuba is actually much better than most other ruby web frameworks in this regard, with only 23 additional methods over what is defined in Object. With Sinatra, there are 68 additional methods. In Roda there are only 6 additional methods.

The reason that Roda is able to have only 6 additional methods is by moving the routing methods to the Request class, which is why the Roda.route method yields the request instance to the block, and routing methods are methods called on the request instance.|Incidentally, if you look at Cuba’s routing methods, they all have feature envy, since pretty much all they do is call methods on the request instance, so even if this wasn’t being done to avoid pollution, it’s still a good idea from an object oriented design perspective.

Loading plugins in Roda is similar to loading plugins in Sequel and Cuba, just calling the Roda.plugin method.|Like Sequel but unlike Cuba, Roda ships with a set of official plugins, but external plugins can be loaded via the same method, so whether the plugin ships with Roda or is external is transparent to the user. In this case, this loads the render plugin, which supports rendering templates using the tilt library.

Usage is similar to Sinatra, except instead of having separate methods per template engine, it just has a single view method. In my experience with Sinatra, I rarely use more than one template engine in the same application, so with Roda’s render plugin, you set the default template engine when loading the plugin. If you want to use a non-default template engine, you can specify an option to override the default when calling view.|Similar to Sinatra, the view method just returns a string, so if you call view as the last expression in your route block, the result of the view is used as the response body.

Of special note in the render plugin is the :escape option, which switches the default template engine to an Erubis subclass that automatically escapes output, preventing common cross site scripting vulnerabilties.

When using the :escape option, the usual percent equal tag will escape the output.

To get unescaped output, you use the percent double equal tag. The use of percent equal for escaping and percent double equal for not escaping provides most of the security benefits of the default escaping that Rails uses, without the complexity of ActiveSupport::SafeBuffer.

Sinatra users may think there is nothing special about this, since Sinatra supports the :escape_html erb option, which will do roughly the same thing. This is what Sinatra recommends in its FAQ when asked about how to automatically escape HTML.

What they don’t tell you is that this is at least partially broken, in that it doesn’t support postfix conditionals inside percent equal tags. This is odd, as postfix conditionals inside percent equal tags are supported when not using the :escape_html option.

The reason that percent equal doesn’t work with postfix conditionals is because it generates this ruby code, just using the percent equal tag content as the argument to escape_xml.|Unfortunately this is not valid ruby syntax, because you can’t use a postfix conditional expression directly as a method argument.

In order to make it valid ruby syntax, you need to wrap the expression in parentheses, which is what Roda does.

Roda ships with another security related plugin, csrf, which adds protection against cross site request forgery. This loads rack_csrf as one of the middleware for the application.

It also adds some view helper methods, allowing you to easily create the necessary CSRF token tags in your views.

If you are doing server-side rendering using the render plugin, and you want to improve performance, in addition to thinking about application performance, you also need to think about rendering performance on the client. One of the best ways to improve rendering performance on the client is to flush the head tag for the response while still preparing the reminder of the response.|The chunked plugin lets you do that, using Transfer-Encoding chunked.

With the chunked plugin, you can use chunked instead of view as the method name, and it will stream the response to the client in chunks. By default, it will flush the top part of the layout template before rendering the content template.

You can a pass block to the chunked method, which will be yielded to after the top part of the layout is flushed to the client, but before rendering the content template. This allows you to execute code necessary to render the content while the client is making requests to load the assets needed to display the page. This can significantly decrease the total time the client takes to fully render the page.

Additionally, at any point inside the content or layout templates, you can call flush to send the partially rendered response to the client. This is mostly useful when loading large pages, where you want the client to see visible content before the all of the content is finished rendering.

The chunked plugin also has a chunk_by_default option, which makes view default to using chunked encoding if the client supports it, allowing you to speed up client rendering performance for all of your views.

One of the issues with Roda’s approach of having a single routing block that all requests are yielded to, is that you can’t split a block across multiple files. For larger sites, it’s not practical to have all routes in a single file, so Roda comes with a multi_route plugin.

With the multi_route plugin, in your main Roda application file, let’s say you have a large routing subtree for paths under albums, which you want to move to a separate file.

You replace the subtree with a call to r.route with the name of the route you want to use. In most cases this will be the same as the matched part of the request path.

You take the routing subtree you removed from the main source file, and you place it in a separate file. By convention these files are stored in a routes subdirectory, and you just require all files from the routes subdirectory in your main application file.|Inside these routing files, you call Roda.route, but you pass it the name for the route, which is the same as the name that you used in the r.route call in the main Roda application file.

For larger apps, it’s common to move all of your routing code to routing files. Assuming you named all of your routes with the request path prefix, you can dispatch to all of your named routes with a single r.multi_route call. In addition to DRYing up your code, this is also faster as it matches against all route prefixes simultaneously using a single regular expression.

If you are writing an app that uses the multi_route plugin, it’s probably large enough that you may want to not use a single directory for all of your views. While you could just specify the subdirectory each time you want to render a template, that’s not very DRY.|Roda ships with a view_subdirs plugin that allows for setting a view subdirectory to use for a given branch.

With the view_subdirs plugin, you can call set_view_subdir anywhere in your routing code, and when you call view, it will automatically prefix the template with that subdirectory. That’s more DRY, but some people might not think it’s DRY enough.

For the DRYest code, you can use the symbol views plugin.

With the symbol views plugin, you can just have your route block return a symbol, which is interpreted as a view template name, and will render the view and use the result as the response body.|Now, some people may consider this too DRY. But the great thing about Roda is this behavior is loaded via a plugin, so if you don’t like it, you just don’t have to load the plugin.

Similar to the symbol_views plugin, Roda ships with a json plugin.

The json plugin makes it easy to create JSON API sites. You just have your route block return either an array or a hash, and Roda will automatically convert it to JSON and use the JSON as the response body.

A common issue with most ruby web frameworks is that by default, they tend to be too liberal in terms of what they match. The symbol_matchers plugin exists to make it easier to use more exact matching.

Take this simple route, which matches albums followed by a segment for the album’s id. While this works, in general it is too liberal.

It’s kind of obvious it is too liberal, since you are converting the matched album_id to an integer. So what you really want to do is only match segments consisting solely of decimal digits.

You could switch to using a regular expression as your matcher. But then you have to specify the grouping manually, and it takes more cognitive overhead to use a regular expression.

With the symbol_matchers plugin, Roda automatically treats some symbols specially, using specific regular expressions for them. One of these symbols is :d, which matches only decimal digits. So this makes sure that only albums followed by a segment with only decimal digits will be matched.

The symbol_matchers plugin also makes it easy to define your own symbol matchers. Let’s say you have lots of routes in your application that include a user’s username. But you don’t allow arbitrary characters in your usernames, you have a strict requirement of only lowercase ASCII letters, and usernames must be between 6 and 20 characters.

With the symbol_matchers plugin, you can use the symbol_matcher method, passing it the symbol you want to match, and the regular expression to use for that symbol. Then, everywhere in your app where you use that symbol, it will use that regular expression instead of the default of matching any sequence of characters. As shown in the previous examples, this works both for symbols and for embedded colons in strings.

Roda ships with a flash plugin that adds support for flash handling, similar to Rails flash handling or the flash handling you get from sinatra-flash.

If you want to handle request methods other than GET and POST, Roda ships with an all_verbs plugin that adds routing methods for all of the HTTP request methods.

Roda ships with a not_found plugin, for Sinatra-like support of specifying a block to call when no route matches.

Roda ships with a error_handler plugin, for Sinatra-like support of specifying a block to call when an error is raised while handling a request.

Roda ships with a pass plugin, for a Sinatra-like pass method. The pass method jumps out of the current routing block as if it did not match, allowing it to continue the routing process.

Roda ships with an indifferent_params plugin, for support for a Sinatra-like params hash that works with both symbols and strings. You could call this stealing from Sinatra, if you didn’t know that I’m the one who introduced indifferent params to Sinatra in the first place.|To be fair to me, Sinatra originally symbolized all params, which opened it up to denial of service attacks, so introducing indifferent access was done to keep backwards compatibility, not because indifferent params are a good idea in general.

If you want some actual stealing from Sinatra, Roda ships with a streaming plugin with an implementation mostly borrowed from Sinatra, though it does have some significant improvements that make it easier to use safely.

Likewise, Roda ships with a caching plugin with an implementation mostly borrowed from Sinatra, adding support for cache control, last modified, and etags.

Roda also ships with an assets plugin that allows for easily compiling and rendering your CSS and javascript assets on the fly in development, and compiling them into a single, compressed file in production for maximum performance.

Roda ships with a middleware plugin that turns your Roda app into a Rack middleware. If you have a Rails or Sinatra application that you want to speed up, but don’t have the time to fully replace with Roda, you can use the middleware plugin to turn the Roda app into middleware, then use that middleware in your Rails or Sinatra application.|Any route that the Roda app doesn’t handle will be forwarded to your Rails or Sinatra application, allowing you to gradually upgrade.

Roda also ships with over 10 additional plugins, but as I’m running out of time, I can’t cover all of them.

So let me review what I think are the main advantages of using Roda over other ruby web frameworks.

First, I think for simple web applications Roda is about as simple to use as Sinatra, and much simpler than Rails, and the Roda codebase itself is significantly smaller and simpler than either Sinatra or Rails.

As your application gets more complex, I think Roda does a better job than Sinatra of managing the complexity, while always remaining a lot less complex than Rails.

Roda performs significantly better than Sinatra and Rails for simple sites, and scales much better than either Rails or Sinatra for truly large sites.

Roda doesn’t pollute your namespaces, so you don’t need to worry about Roda conflicting with your application code.

Finally, because of the Sequel-based plugin system it uses, Roda is very extensible, so if you need functionality that isn’t included in one of the plugins that ship with Roda, it’s easy to add yourself.