rack-server-pages

ack, as suggested in the OP, is a little too extreme. One of the commenters over there mentioned Rack Server Pages[3], which is interesting. Sinatra appealed to me because most of its features come disabled out of the box (in modular mode), and you can selectively reenable them and incorporate other bits of Rack middleware to build up your stack. Some commenters here appear to be conflating Rails and Sinatra in terms of behemoth-ness, which is strange to me because Sinatra::Base is less than 2,000 LOC. Sinatra is not much more than a thin DSL for creating Rack applications as described in the OP! Anyway, it also seemed silly to eschew Rails only to pull in ActiveRecord and ActiveSupport, so after another round of research I selected the excellent Sequel ORM[4] to handle database abstraction. There have been times when I felt like we were going against the grain. The Ruby community is oriented around Rails, and most of my early Ruby questions received Rails-specific answers, which was frustrating. Some pieces of Rack middleware and other things like json:api serializers tend to be implemented (and documented) in a Rails-specific way; getting them to work with Sinatra (or finding viable alternatives) has been time-consuming. More than once I've thought to myself, "If we're going to use some unsupported and/or fringe-y thing, we might as well have built this in Elixir or Luminus or Sails or ChicagoBoss or..." That being said, writing Ruby is fun, the community is great (MINASWAN), and we've discovered some amazing libraries. There is a ton of work going on to improve Ruby (specifically, JRuby 9K, Ruby OMR, ConcurrentRuby, etc.) so the language has a bright future. In the meantime, our solution is fast, stable, simple, and easy to test and deploy, so it meets all of our requirements. 1. https://github.com/mwpastore/FrameworkBenchmarks/blob/sinatr... 2. https://www.techempower.com/benchmarks/ 3. https://github.com/migrs/rack-server-pages 4. http://sequel.jeremyevans.net

those aspects of HTTP that frameworks keep well hidden under their carpet and that can help you become a good web developer instead of "simply" a framework user. Yes for sure, best practices that frameworks implement are there for a reason, and it's great to have them, but IMHO, this approach has advantages when learning and could also be seen as an essential step to understand what those frameworks you will use next are abstracting and why. IMHO, what still contributes to new generations of devs approaching PHP, is also its immediateness and simplicity with nothing to do except '<?php' code '?>' and with this comment I just wanted to give a bit more exposure to the fact that a similar solution exists for Ruby too, and that it's a bit of a pity that because of the importance of Rails it got a bit overshadowed.