As someone who's spent a not-insignificant amount of time optimizing the heck out of a Sinatra benchmark[1] for TechEmpower's Web Framework Benchmarks[2] (TFB),

As someone who's spent a not-insignificant amount of time optimizing the heck out of a Sinatra benchmark[1] for TechEmpower's Web Framework Benchmarks[2] (TFB), and as someone who's spent the last four months or so building a json:api compliant Sinatra back-end and Ember.js front-end (for an MVP), this subject is near and dear to my heart. I definitely thrashed on language selection for a few weeks before settling on Ruby. It was an opportunity to learn a great language, but I wanted to actually learn the language instead of relying on a huge library. Rails had a lot of overhead for what we had in mind, Rails API had only recently been merged and seemed unproven, and the more esoteric Ruby web frameworks based on Celluloid (e.g. Reel) and EventMachine (e.g. Goliath) were too daunting. I think going all (well, almost all) the way down to Rack, 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/sinatra-sequel-rbx/frameworks/Ruby/sinatra-sequel/hello_world.rb https://github.com/mwpastore/FrameworkBenchmarks/blob/sinatr... 2. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ 3. https://github.com/migrs/rack-server-pages https://github.com/migrs/rack-server-pages 4. http://sequel.jeremyevans.net http://sequel.jeremyevans.net