It’s interesting that you brought this up - I’ve been wondering for a long time why Elixir doesn’t have a sinatra clone - almost every language (especially “ruby descendants/inspired” languages) has some some form of sinatra clone.
I’m also perfectly happy with phoenix and think it’s light weight enough, I can restructure folders etc. however I like but I often think about building a sinatra clone for fun and for getting more used to macros 
I think it’s precisely because of what José suggested: Phoenix doesn’t really get in your way when you build your application.
It doesn’t force you to write your code a certain way or use specific libraries for things that are unrelated to its core functionality (serving HTTP and Websocket requests).
True that - one of the many reasons I really like phoenix.
Sometimes I still think that a sinatra like library might be nice (although as many people here mentioned you can just use plug instead) - i.e. for teaching or really small projects (let’s say a little chat bot).
I probably underestimate the effort to make a good sinatra clone though 
I think, in a way, Plug.Router already exposes a sinatra-like DSL, so there’s no separate package - most people looking for something like that find it enough.
This might be of interest to you if you want to build something using Plug. German Velasco is a great guy, I used to work with him at thoughtbot, and he breaks it down very nicely:
Some people might have inferred from the OP’s post that Phoenix wasn’t a lightweight framework, whereas I think the general consensus is that it is
Had they asked for a ‘simpler’ framework I might have asked in what way since Phoenix itself can be used in various ways; from a simple (albeit more majestic) monolith (so pretty easy for anyone coming from Rails to jump into), to the default (more ideal) path using Contexts and pushing the Phoenix is not your app mantra, and then of course this can be taken to the extreme, where Phoenix is used as a layer (or a number of layers) inside an Elixir app which itself is built as a series of components (as per Dave’s course). I actually really love that Phoenix is flexible like this and I can definitely see me using it in all three of those ways for different kinds of apps 
I probably would have also included links to RaxxKit as something worth looking at, but in all honesty I really do not know enough about it other than it seeming to be more like Ruby’s Hanami which is comprised of several micro-libraries (I can see the benefit of something like that in Ruby, but am, as of yet, unsure where it fits in the Elixir world). Perhaps you can help with that - I don’t think you ever got around to answering my questions about it which would definitely help people see why it was created, where it fits into the Elixir landscape, its pros, cons, and when someone might want to use it over other frameworks 
This might be of interest to you if you want to build something using Plug.
It would be quite less efficient than the default phoenix setup since he used the default EEx engine for templates which just concatenates binaries instead of using iolists. It’s the mistake I’m seeing most often when people try using plug.
Still, a great introduction.
The comparison to Hanami is probably quite good as I have been following that projects development . HoweverI’m not trying to make a phoenix vs Raxx case here.
Raxx.Kit obviously has it’s own set of assumptions/conventions and as I mention whenever possible I have been using both in production for over a year now and each has their place.
What I find more curious is the goal of phoenix to be both lightweight and batteries included. Trying to optimise for both has always seamed ambitious to me and prone to compromise even if that compromise is just mixed messaging. Anyway the consensus is not with me here and I am happy to let that continue.
I will answer your question in that thread
At work we toyed a bit with just Plug+Cowboy for “HTTP API” style apps, but everything turned out a bit differently. The last couple of projects, we just generated a Phoenix app with all the --without options, then take an axe and kill the foo_web/foo stuff, remove everything else we don’t need, and then have something that - if needed - can grow back into something full-fledged but it simple, minimal, and understandable; developers that just did a Phoenix read-through will know where to find everything but it’s still very light-weight. Just checked one project, cloc says there’s 125 LOC in the Phoenix bits.
One of these days, I’m gonna whip up something that just generates this minimal thing
What is your ultimate goal though? Smaller .beam files? Performance gains? Easier to recover from exceptions (I don’t quite get that.) Another coding style? (I think we can all agree this is subjective but worth the effort regardless if you find yourself more productive in the end.) I understand the argument for a Plug replacement that deals better with sockets and channels – carrying easily accessible metadata at all times if I got it correctly – but outside of that I seriously can’t understand what is it that Raxx does better (and I think I spotted Jose or Michal saying the next Plug / Phoenix will address these issues Soon™).
I have been reading your posts and comments last month or so and I still cannot understand what is your objection to Phoenix. I am not raining on your parade. Maybe I am just dumb and can’t grasp the idea. Will you help me understand? (I did read your threads here btw, but not your blog.)
Maybe you don’t but you have been repeating that Raxx is better suited for certain use cases and I am yet to see something that will convince me of this claim. Do you have a quick and self-explanatory example that shows when Raxx is a better fit than Plug / Phoenix?
As @cdegroot mentions, you can very easily reduce Phoenix’s generated files and still use most of it (and most of its “boilerplate” are optional convenience helpers anyway, they are not mandatory the way Rails makes most of itself mandatory if you wanna use it).
This is not about democracy or consensus. Give us pieces of info that help people make an informed decision. Alternatives are good, they challenge the thinking of people and make them see new horizons.