Author here: I encourage anyone that is curious about the reason for this framework as opposed to X to read the project's architecture document https://github.com/timothycrosley/hug/blob/develop/ARCHITECT.... Some highlights: it allows some of the most concise Python code, produces automatic documentation, supports annotation based validation and argument transformation, automatically enables version management, and is way faster then Flask / Django at handling requests. Also, I'm free to answer any questions you may have :)
> produces automatic documentation, supports annotation based validation and argument transformation
These aren't new, though the approach to them seems quite clean.
> automatically enables version management
There's syntax sugar in the decorators for supporting versioned api's, sure.. but you still need separate functions for each version. I think the wording oversells the feature a bit.
> and is way faster then Flask / Django at handling requests
In what configuration? Pretty much anything is faster than Flask's included development server. Is it faster than Flask configured with nginx over wsgi? If so, how much faster? The best way to convince people of this is to not only post benchmark results, but also commit the benchmarks themselves so people can run them.
Project looks neat but Flask is well though out, well supported, has amazing documentation, and supports both Python 2.x and 3.x.. which leaves little reason to switch (with the exception of the CLI interface.. which I can't deny is pretty darn cool).
You can see the performance difference bench-marked by a competing framework non the less, here: http://pycnic.nullism.com/ These are done running a standard uwsgi setup for all frameworks (even playing ground).
> These aren't new, though the approach to them seems quite clean.
This is really the crux of it, nothing is new. That is before Flask etc you could do everything you can do with Flask now, but the approach was bad and not clean. Required a lot of duplication of work. Flask helped fix that. You can do the hug enables through flask now, but the approach isn't clean, they require a lot of duplication of work. Hug fixes that.
The same reasons people started using Flask are the same reasons they should start using hug. It provides a cleaner, faster, and better base for the APIs of the future - just like Flask did when it came along.
I would be interested to see the benchmarks against Pyramid, because it tries to be really minimal while at same time it is very friendly and flexible if you want to write REST API's with it.
How well it understands types? Could I generate TypeScript interfaces for each API call?
I'm not that interested in RESTfullness, but rather easily navigable API through auto-completion. E.g. /users/save/ would become "Users.Save()" in JavaScript/TypeScript, with interfaces.
There's a bunch of reasons, but they really come down to a focus on memory efficiency and knowledge of how certain things perform on Python (using hasattr instead of isinstance where applicable, using __slots__, only processing things when it's clear they need to be processed). And then for extra measure: Cython compilation. You can see a competing frameworks benchmarks showing the result of all this work here: http://pycnic.nullism.com/
