The problem with this approach is readability. If you look at the code vs Sinatra every time you want to figure out which route to edit, you have to traverse the tree as opposed to just scanning for the route you want. As an example, editing the route /artist/:id/album/:number requires you to first find the /artist/:id then scan down and look for /album/:number making sure you watch for the closing end because what if the route isn't defined? In Sinatra, you look for /artist/:id/album/:number. The solution to this is to put a comment on every route to denote where it is. I agree the tree methodology can be faster O(log N) (for GET and POST) vs O(N) but readability suffers with no comments.
I'm glad Roda is finally getting some publicity. I submitted it here when it was released.<p>I've converted about 15 apps from Sinatra to Roda, and a couple of Rails apps to Roda (working on converting my final Rails app). Personally, I've found that the biggest advantages come when the URL structure mirrors your application structure, and you have redundant code in many routes, as that type of code becomes simpler, faster, and DRYer with Roda.<p>Yes, you can use a before block with wildcard routes with Sinatra, but Sinatra will still traverse the routing list sequentially and recheck the full route for every entry in the list. Unfortunately, while I love Sinatra, have contributed patches to it, and have used it since 0.1.0, the approach doesn't scale well for sites with a lot of routes.<p>The code non-locality issue shouldn't be ignored, and is probably the largest issue with Roda, but the issue is probably going to happen with any approach that DRYs up the code to the same degree. It's true if you use a before block in Sinatra, or a before_filter in Rails.<p>The use of a routing tree really isn't an innovative approach (at least not innovated by me). It's been around in Ruby since Rum was released in 2008 (and maybe earlier elsewhere). However, it's not well known, and I hope that Roda brings it into the mainstream.<p>One of the best things about Roda that I don't think has been mentioned in the comments yet is the plugin system, which I borrowed from Sequel. This makes it easy to extend Roda beyond its very small core. For example, the multi_route plugin makes it easy to scale Roda to larger sites by splitting up routing subtrees into specific files. There are currently about 15 plugins, and I have ideas for quite a few more that I will implement after finishing up my current Rails->Roda conversion.<p>I apologize that the code on the website isn't syntax highlighted. If anyone can offer their design skills, I would greatly appreciate it.<p>If you have any questions about Roda, please ask.
I don't really buy the "big win" over Sinatra ("much DRYer", no need to set ivars for each action) because you can just use a `before` block with wildcard routes.<p><pre><code> before '/artist/:id*' do
@artist = Artist[params[:id]]
end
before '/artist/:id/album/:number*' do
@album = @artist.album_with_number(params[:number])
end</code></pre>
Welcome Roda and congrats for this new innovative routing idea. As much as I see some value in a tree-like routing definition in this nice comparison with Sinatra, <a href="http://roda.jeremyevans.net/why.html" rel="nofollow">http://roda.jeremyevans.net/why.html</a>, Sinatra's routing approach still appears to be more readable and manageable. Maybe Sinatra could optimize the storage of the routing entries internally in a tree to make it as fast as Roda (if it doesn't already do).
I love it. I think the concerns about the code being unmaintainable from the example are a bit unfair. There is nothing preventing a developer from moving the blocks out into separate files/classes for a more coder-friendly organization. How deep do you guys nest your javascript callbacks?<p>This also lead me to check out sequel, which I can't believe that I'm just now finding out about.
I've been using a web "framework" I wrote for a few years now. It now powers various projects, from the Chartboost Store backend, to the entire the entire backend codebase for my new startup, FreshPay.<p><a href="https://github.com/kballenegger/kenji" rel="nofollow">https://github.com/kballenegger/kenji</a><p>One of the big things that makes Kenji awesome is that, like Roda, it uses a routing tree.
I think this looks great. However, even in his simple example comparing Roda and Sinatra the code ends with 7 'end's. I can imagine how deeply nested a non-simple app can be. In my experience, the deeper you get in your nesting - the more complicated the code is to read.
Oh boy another web framework to benchmark... :-)<p><a href="http://www.madebymarket.com/blog/dev/ruby-web-benchmark-report.html" rel="nofollow">http://www.madebymarket.com/blog/dev/ruby-web-benchmark-repo...</a>
It might be just me, but that is insanely hard to read. I MUCH prefer the Sinatra approach for that reason alone. Looking at the examples side-by-side I couldn't tell what was going on in Roda...at all.
My apologies if this is off-topic, but since I see mention of various frameworks ... it seems relevant.<p>I'm a .NET dev finally looking at Ruby again. I have a Rails book from a long while ago that I'm working through (well, planning on - Rails 4 in Action, still in MEAP) but looking at this data I'm wondering if that's the best idea.<p>Any recommendations on a framework for someone getting started?<p>If it helps, I've been using ASP.NET MVC since 1.0 if not slightly earlier.
I wish that routes weren't stuck within strings like `/artist/:id`, but instead used some kind of pattern matching like `['artist' :id]`. It's better to use Ruby syntax instead of a quoted string of characters that can't be manipulated or verified as easily.
Definitely feels like an improvement on Cuba! I'm not a huge fan of the `is` method here, though. I feel like you could get the same thing from a terser DSL if you treated HTTP methods as terminators and only allowed `on` to filter the path.