anchor.diff:  
     get '/artist/:id' do
       @artist = Artist[params[:id]]
  +    check_access(@artist)
       erb :artist
     end
   
     post '/artist/:id' do
       @artist = Artist[params[:id]]
  +    check_access(@artist)
       @artist.update(params[:artist])
       redirect(request.path_info)
     end
   
  -  get '/artist/:id/album/:number' do
  +  delete '/artist/:id' do
       @artist = Artist[params[:id]]
  -    @album = @artist.album_with_number(params[:number])
  -    erb :album
  -  end
  -
  -  post '/artist/:id/album/:number' do
  -    @artist = Artist[params[:id]]
  -    @album = @artist.album_with_number(params[:number])
  -    @album.update(params[:album])
  -    redirect(request.path_info)
  -  end
  -
  -  get '/artist/:id/album/:number/track/:track_num' do
  -    @artist = Artist[params[:id]]
  -    @album = @artist.album_with_number(params[:number])
  -    @track = @album.track_with_number(params[:track_num])
  -    erb :track
  -  end
  -
  -  post '/artist/:id/album/:number/track/:track_num' do
  -    @artist = Artist[params[:id]]
  -    @album = @artist.album_with_number(params[:number])
  -    @track = @album.track_with_number(params[:track_num])
  -    @track.update(params[:track])
  -    redirect(request.path_info)
  +    check_access(@artist)
  +    @artist.destory
  +    redirect '/' 
     end
   end
   </code></pre>
   </div>
   
  -<p style="clear: both;">While the Roda code is slightly more lines, it should be apparent that it is actually much simpler.  Instead of setting the <span class="code">@artist</span>, <span class="code">@album</span>, and/or <span class="code">@track</span> variables in every route that uses them, the variables are set as soon as that branch of the tree is taken, and can be used in all routes under that branch.  This is why Roda is called a routing tree web framework. In all but the smallest applications, this usually results in much DRYer and easier to maintain code.</p>
  +<p style="clear: both;">While the Roda code is slightly more lines, it should be apparent that it is actually simpler.  Instead of setting the <span class="code">@artist</span> variable and checking that access is allowed in all three of the sinatra routes, the variables are set as soon as that branch of the tree is taken, and can be used in all routes under that branch.  This is why Roda is called a routing tree web framework.  This is a very simplified example, but if you see this type of duplication in a lot of the Sinatra code you write, your app could probably be made simpler by converting to Roda.</p>
   
   <h3>Faster</h3>
   
  -<p>In addition to being more maintainable, Roda's approach is also faster in general.  This is because Sinatra is doing more work to determine which route to take compared to Roda.  Let's say you are going to <span class="path">/artist/1/album/2/track/3</span>.  What Sinatra is going to do is check each route in order, comparing the request method and route against the full path of the request, and if it doesn't match, starting again with the next route.  With Roda, as soon as part of the route matches, that part does not need to be rechecked every time.  Also, the request method is only checked once at the end to determine whether to take get or post as the final branch.</p>
  +<p>In addition to being more maintainable, Roda's approach is also faster in general.   Sinatra routes requests by testing each of the stored routes against the current request, in order.  With Roda, once one branch of the tree matches, only routes inside that branch are considered, not any routes after that branch.  Roda also has support for a single route that dispatches to multiple branches via the multi_route plugin.  For large applications, routing in Sinatra is roughly O(n), where n is the number of routes, while routing in Roda can be close to O(log n), depending on how you structure your routing tree.  For small applications, because Roda is simpler internally, <a href="https://github.com/luislavena/bench-micro#requestssec">Roda is about 2.5 times faster than Sinatra</a>.</p>
   
   <h3>Plugin System</h3>
   
  
positive.code:       view :index
      end
  
      r.on 'artist/:id' do |artist_id|
        @artist = Artist[artist_id]
  
        r.is do
          r.get do
            view :artist
          end
  
          r.post do
            @artist.update(params[:artist])
            r.redirect
          end
        end
  
        r.on 'album/:number' do |album_number|
          @album = @artist.album_with_number(album_number)
  
          r.is do
            r.get do
              view :album
            end
  
            r.post do
              @album.update(params[:album])
              r.redirect
            end
          end
  
          r.on 'track/:track_num' do |track_num|
            @track = @album.track_with_number(track_num)
  
            r.is do
              r.get do 
                view :track
              end
  
              r.post do
                @track.update(params[:track])
                r.redirect
              end
            end
          end
        end
      end
    end
  
negative.code: 
  <h3>Routing Tree</h3>
  
  <p>The primary difference between Roda and Sinatra is that Roda uses a routing tree, while Sinatra uses a list of routes.  At any point in the routing tree, Roda allows you to operate on the current request.  If your URLs reflect your application architecture, this allows you to have DRYer code.  Let's examine code examples for a very simple app, implemented in both Sinatra and Roda:</p>
  
  <div class="col-md-6">
  Roda:
  