What I want:

Single-purpose "action" objects.

I want to look at a project's file structure and see what it does. Something like actions/create_article.rb that has a CreateArticle class who's only job is to create articles.

No controllers/viewsets that handle an entire set of CRUD operations on a resource.

Don't push request/response stuff into the business logic layer.

For example, CreateArticle doesn't need an entire request object. It just needs some data. The routing layer should pull what's needed out of the request and pass it in to the business layer.

Resources that live at a single URL, like REST for reals

A resource maps to a single URL. HTTP methods called on that URL map to actions. Something like:

resource 'article', at: '/article/:id' do
  map GET, to: 'get_article'
  map PUT, to: 'update_article'
  # etc...
end

Yeah, that means the singular and plural are separate resources:

resource 'article_collection', at: '/articles' do
  map GET, to: 'list_articles'
  map POST, to: 'add_article'
end

Yeah, that means for non-api stuff you'll need weird stuff like this:

resource 'new_article_form', at: '/articles/new' do
  map GET, to: 'build_article_form'
end

You got a problem with that? I don't. I love it. Most everything server-side is an API now anyway. And it will map really nicely to hypermedia apis. Imagine doing a OPTIONS /path/to/resource. You see what I'm saying? Whatever. I don't care what you think.

Resources != Database tables

It's super easy in Django or Rails to hit the ground running. Since they expect the entire flow from a web request down to the database and back you are dealing with a Model that maps to a Database Table. You can wire up a complete CRUD scaffold in minutes. Well great. A paper thin foundation that becomes convoluted and torn as soon as you have to break from the DB Table CRUD mold, and you always need to do that.

Getting started is the easy part! Maintenance is the real work. The framework can go ahead and make the "getting started" step more complicated if it means a firmer foundation that will support change and growth.

It can still have "magic" (form helpers, etc) but it should be supported through thin interfaces, not by shoving all the magic into a giant class that you expect everything to inherit from (ActiveRecord::Base, models.Model). Any object that supports the interface for a piece of magic should get to use the magic.

I like magic! I like fat tools!

I don't want a "lightweight" framework. I don't want "less magic". I just want something that's well designed. Something that's designed to support change and growth. Apps always change and grow and that's always the hardest part.