Haven't used flask in some time now, but most of your objections are missing the mark.
> GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this.
Flask's request is not global. I have had this discussion with someone else before:
FWIW, flask's "from flask import request" never had been a blocker for me, whereas django's injected request variable had made me write middleware to preseve requests as thread locals so that I can access it elsewhere. Werkzeug does the same thing, except it does it more robustly.
> MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware.
I don't see an issue. If you can solve it using simple python(decorators), solve it using Python.
> BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware.
Rather than calling app.before_request, you can call blueprint.before_request and it will work only for that blueprint.
> SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods
Then don't use the decorator. Have a routes.py and call app.add_url_rule
I have had a template with all of this from some time back
> GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this.
Flask's request is not global. I have had this discussion with someone else before:
https://news.ycombinator.com/item?id=6662623
FWIW, flask's "from flask import request" never had been a blocker for me, whereas django's injected request variable had made me write middleware to preseve requests as thread locals so that I can access it elsewhere. Werkzeug does the same thing, except it does it more robustly.
> MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware.
I don't see an issue. If you can solve it using simple python(decorators), solve it using Python.
> BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware.
Rather than calling app.before_request, you can call blueprint.before_request and it will work only for that blueprint.
> SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods
Then don't use the decorator. Have a routes.py and call app.add_url_rule
I have had a template with all of this from some time back
https://github.com/rahulkmr/flask-bigapp-template