6 ms·
This is epic. In theory now from V1 onwards it should be easier to convince people at big serious corps to use Flask as it cuts down a lot of Django bloat espec
by jxub 9y ago
This is epic. In theory now from V1 onwards it should be easier to convince people at big serious corps to use Flask as it cuts down a lot of Django bloat especially for smaller applications, microservices and other nimble backends.
- ryannevius 9y agoYou don't have to use the Django "bloat": https://github.com/syntarsus/minimal-django https://github.com/syntarsus/minimal-django
- Walkman 9y agoLOL
- deft 9y agoHopefully! There's a bad attitude I've noticed about Flask, people don't take it seriously and treat it like a learning tool or a library for quick and dirty hack projects. All because it's simple to learn and free of bullshit and Just Works™. Should lead to the opposite attitude, but nope. People apparently enjoy extra complexity.
- weberc2 9y agoI think a lot of criticism is valid. Flask has a lot of bizarre conventions which don't scale well, like stuffing all shared resources into the global context or app-level dicts and using `@route()` decorators all over, for example. And I'm not sure what the benefit is, except that clever feeling one gets when they use decorators or other seemingly magical features unnecessarily and later need to workaround the tight coupling.
- mixmastamyk 9y agoDecorators improve dev speed. No need to be constantly switching back and forth between views and urls.py. Still, sometimes nice to see all in one place.
- scaryclam 9y agoThey only improve speed from an initial "get it working" point of view. That's part of the reason flask is rarely taken seriously as a production solution. Not having natural separation between views and urls is a real PITA for anyone trying to create a long term solution or larger project. For what it's worth, I also hate the argument that bad design increases Dev speed. That's only true until you need find something later, then you have to hunt around instead of having one place to look, wiping out any initial gains. It's false economy.
- aregsarkissian 9y agoFYI with flask you don't have to use decorators for routing. You have the option to define all your routs in a single file.
- mixmastamyk 9y agoTrue in a very large project, false on the rest. Congrats on your one-true-way argument. ;)
- weberc2 9y agoI'm a professional Python dev, I have no reason to believe that decorators save any time for any size of project. They're harder to reason about for developers of all experience levels and their is no obvious advantage--some argue that the syntax is more pleasant, but I don't perceive an increase in readability; certainly not one that makes up for the increased cognitive burden. The following is super straightforward, testable, and it doesn't depend on globals for shared resources or request state: def hello_handler(r: Request) -> Response: return Response.ok("Hello!") def goodbye_handler(r: Request) -> Response: return Response.ok("Goodbye!") if __name__ == "__main__": router = Router("/") router.register_route("/hello/", "GET", hello_handler) router.register_route("/goodbye/", "GET", goodbye_handler)
- mixmastamyk 9y ago
- cuchoi 9y agoThere is a similar feeling towards SQLite
- aphextron 9y agoWhat's your application server setup like? Is there a standard for this? I tried using UWSGI and Gunicorn with varied results. It was just a pain to setup. I hope things have improved.
- acostanza 9y agoI found it pretty easy to set up with Gunicorn and nginx, all running in Docker
- abhishekjha 9y agoIs there any definite tutorial to set it up with Gunicorn and ngnix? I have used gunicorn before but not with ngnix.
- PokemonNoGo 9y agoSame setup as the other reply. Gunicorn and flask in docker. Works perfectly and is speedy.