Hacker News Reader

Comment by robertlagrant | Hacker News Reader

Low dependency analysis is one of the reasons I like Flask[0].

[0] https://github.com/pallets/flask/blob/main/setup.py

Weird, I dislike Flask because it quickly becomes a dependency soup the moment you want to add something simple like forms or a DB.

Django has less dependencies[1] - one "real" one (asgiref), one to work around a sqlite issue ("sqlparse"), and up to two timezone related backports depending on your OS (tzcata, zoneinfo). Plus obviously a library for your db backend, if you're not using sqlite.

And with that you get a lot more for less, compared to a Flask + wtforms + sqlalchemy + alembic "starter setup":

  > $ pip install flask "sqlalchemy[postgres]" wtforms alembic
  > $ pip freeze | wc -l
  > 13
  > $ pip install django psycopg2-binary
  > $ pip freeze | wc -l
  > 4

1. https://github.com/django/django/blob/60a7bd89860e504c0c33b0...

I understand what you say and the appeal for it. However, I have to admit that one of the reasons I like Golang over Python (Although I develop in both frequently and enjoy them) is because of the language mentality of libraries over frameworks. I prefer many explicit different dependencies glued together from one's own logic than a batteries included Framework where big part of the magic happens under the hood and ways of doing things must follow an specific path that does not always applies for your specific business case. I think this approach gives a better flexibility (and can cause annoying paralysis by decision too).

I don't think it is as soupy as you say.

Flask is split up into a few Pallets projects - Flask, Werkzeug, Markupsafe, Click, itsdangerous, Jinja2 - but they're all from the same stable group. This split makes them more useful as independent libraries, rather than one big framework.

Ditto two more (Alembic and SQLAlchemy) are also from a very stable group. It would be nice if Alembic used Jinja2 instead of Mako, of course, but it's a dev-time dependency and so it's lower risk in my opinion.

I agree that at the thing Django does (forms + a SQL database) it does it with fewer dependencies than Flask. But that doesn't mean Flask has loads of dependencies; it has an appropriate number for the task you're doing. I was more comparing Flask to actual dependency soup ecosystems[0].

[0] https://github.com/rizkimcitra/next-starter-blog/blob/main/p...

Ditto. I liked Flask years ago but unless you’re doing very contained microservices it always ends up feeling like you’re building your own framework. This isn’t a slam on Flask but rather, I think, a reminder that we’re so prone to think about the fun of being able to customize everything without thinking about the maintenance trade-offs.

Django is also excellent for this. This isn't a two-horse race :)

I believe a minimalistic server framework (Flask) is an unfair comparison to what the author is complaining about, namely packages that need to integrate into an entire front end framework and ecosystem (React Native). Handling requests (Flask's primary use case) is but a small fraction, and addition to, all of the other things you need to implement and consider on devices that would run React Native.

Examples: camera roll and / or camera integration, contact listing, deep linking _into_ the app, linking _out of_ the app, foreground or background push notification display (and subsequent routing on press), the list goes on and on. IMO, native development, even if you choose to go Kotlin / Swift path instead of react native, is extremely complex.

To be brutally honest, I too can fire up a linux box or container, install flask, and have my simple REST server up in a matter of minutes. The same cannot be said for all the example native features listed above.

you are conflating the size of the codebase with the number of dependencies

Django has fewer dependencies than Flask.

(though in all fairness the dependencies Flask has were developed by the same author, thus in that sense, it is more like Django)

Reply on news.ycombinator.com