5 ms·

I think that is exactly the problem with Flask. Look how simple it is! Except, as you say, you almost always need at least some of that stuff, and wiring it tog

by saila 5y ago

I think that is exactly the problem with Flask. Look how simple it is! Except, as you say, you almost always need at least some of that stuff, and wiring it together yourself is/becomes an unholy mess (IME). And getting set up with Django is just as simple, so I don’t buy that argument anyway.

CuriouslyC 5y ago
The problem with Django is that it's so opinionated. If you don't really use the admin interface and you want to do things your own way you will spend way more time wrestling with Django than you saved using a few plugins. Also, the ORM is hot garbage that you have to carry with you to some degree if you do actually use the admin at all.
- sgt 5y ago
  First thing I do is disable the admin interface. I think most serious Django devs view it as a gimmick.
  - andybak 5y ago
    Not all of us.
    - sgt 5y ago
      I guess it's a nice way to visualize the models, at least in the beginning. I prefer shell_plus along with dbshell. Then I can also write code that I can later easily adapt into my views etc.
      - andybak 5y ago
        It's invaluable in many ways for me and my clients and it's saved me countless hours of developing things from scratch. I think the animosity towards "over use" by some of the core community is misguided. The continued work that goes towards improving extensibility and features is surely a sign that someone finds it worth contributing towards. And the number of projects on Github or Django Packages that hook into the admin have to be written by somebody.
- saila 5y ago
  I rarely use the Django Admin except maybe for poking around in the early stages. I’ve never tried to build a full blown app/site with it. I think the right comparison here is to Flask-Admin, though, not Flask itself, and I’ll just say that the app I have to deal with that’s built on Flask-Admin is a nightmare, certainly no better than an equivalent app using Django Admin would be. Re the Django ORM, SQLAlchemy is certainly better in many ways, but the Django ORM is pretty good these days (and has been for a while IMO). If I know I’ll have complex database requirements that Django can’t easily handle, I’d much rather use Pyramid + SQLAlchemy than Flask.
- andybak 5y ago
  > the ORM is hot garbage It really is not.
gen220 5y ago
What problems do you run into with Flask (presumably + SQLAlchemy)? IME, this stack has been pretty simple both at-scale and at-home. At scale, my experience is mostly using it in REST APIs serving a react frontend. At-home, I've used it to setup numerous graphql services (with the graphene plugin). Admittedly, there's probably 100 different ways to configure anything wrong, especially for any framework written in Python. But once you witness a "golden path", and stick to it, it's pretty straightforward. (The Flask docs have improved a lot in this regard, in the last few years)
- saila 5y ago
  I’m working on multiple Flask apps currently and I have a lot to say about it, but regarding docs, the main Flask docs might be fine, but the docs for some of the extensions we use are quite bad. Also, there’s nothing about these apps that requires the alleged flexibility of Flask, so there’s a lot of issues with dependencies and integrating extensions. That’s a lot of extra work and probably weakens security for no benefit at all. Upgrading a big Django app is much simpler IME.
  - gen220 5y ago
    I think part of the reason the Flask extension ecosystem is so weak, is that most problems solved by an extension have solutions that are relatively small / cheap to build in-house. These things are difficult both to depend upon externally and to maintain, due to the dependency/upgrade issue you mentioned. For an example in a similar ecosystem: at a previous company, at one time we used SQLalchemy-continuum for audit tables. We found some bugs and were not able to upstream them. When we wanted to upgrade SLQLAlchemy to X.Y, we were stuck with this dependency that required SQLAlchemy X.Y-1. After a few years, we realized it was cheaper to cook up a SQLAlchemy-Continuum subset that met our needs, so it'd be easier to keep in line with SQLAlchemy. It's a very different mindset from Django; I think there's an appropriate context for each.
- digisign 5y ago
  May have changed, but when I tried it, the first day with Flask was incredible. The second day, when you're ready to implement log-in and password pages, maybe email reset... you are on your own. There's six and a half third-party extension options with different overlapping scopes to research, the author of the best one has taken off for the Bahamas for two years…
peller 5y ago
I had the same pain points with Flask, so I built Flask Unchained to integrate many of the best extensions (IMO) to all work together out of the box in a reusable way: https://github.com/briancappello/flask-unchained https://github.com/briancappello/flask-unchained

by saila 5y ago

CuriouslyC 5y ago

The problem with Django is that it's so opinionated. If you don't really use the admin interface and you want to do things your own way you will spend way more time wrestling with Django than you saved using a few plugins. Also, the ORM is hot garbage that you have to carry with you to some degree if you do actually use the admin at all.

sgt 5y ago
First thing I do is disable the admin interface. I think most serious Django devs view it as a gimmick.
- andybak 5y ago
  Not all of us.
  - sgt 5y ago
    I guess it's a nice way to visualize the models, at least in the beginning. I prefer shell_plus along with dbshell. Then I can also write code that I can later easily adapt into my views etc.
    - andybak 5y ago
      It's invaluable in many ways for me and my clients and it's saved me countless hours of developing things from scratch. I think the animosity towards "over use" by some of the core community is misguided. The continued work that goes towards improving extensibility and features is surely a sign that someone finds it worth contributing towards. And the number of projects on Github or Django Packages that hook into the admin have to be written by somebody.
saila 5y ago
I rarely use the Django Admin except maybe for poking around in the early stages. I’ve never tried to build a full blown app/site with it. I think the right comparison here is to Flask-Admin, though, not Flask itself, and I’ll just say that the app I have to deal with that’s built on Flask-Admin is a nightmare, certainly no better than an equivalent app using Django Admin would be. Re the Django ORM, SQLAlchemy is certainly better in many ways, but the Django ORM is pretty good these days (and has been for a while IMO). If I know I’ll have complex database requirements that Django can’t easily handle, I’d much rather use Pyramid + SQLAlchemy than Flask.
andybak 5y ago
> the ORM is hot garbage It really is not.

gen220 5y ago

What problems do you run into with Flask (presumably + SQLAlchemy)? IME, this stack has been pretty simple both at-scale and at-home. At scale, my experience is mostly using it in REST APIs serving a react frontend. At-home, I've used it to setup numerous graphql services (with the graphene plugin). Admittedly, there's probably 100 different ways to configure anything wrong, especially for any framework written in Python. But once you witness a "golden path", and stick to it, it's pretty straightforward. (The Flask docs have improved a lot in this regard, in the last few years)

saila 5y ago
I’m working on multiple Flask apps currently and I have a lot to say about it, but regarding docs, the main Flask docs might be fine, but the docs for some of the extensions we use are quite bad. Also, there’s nothing about these apps that requires the alleged flexibility of Flask, so there’s a lot of issues with dependencies and integrating extensions. That’s a lot of extra work and probably weakens security for no benefit at all. Upgrading a big Django app is much simpler IME.
- gen220 5y ago
  I think part of the reason the Flask extension ecosystem is so weak, is that most problems solved by an extension have solutions that are relatively small / cheap to build in-house. These things are difficult both to depend upon externally and to maintain, due to the dependency/upgrade issue you mentioned. For an example in a similar ecosystem: at a previous company, at one time we used SQLalchemy-continuum for audit tables. We found some bugs and were not able to upstream them. When we wanted to upgrade SLQLAlchemy to X.Y, we were stuck with this dependency that required SQLAlchemy X.Y-1. After a few years, we realized it was cheaper to cook up a SQLAlchemy-Continuum subset that met our needs, so it'd be easier to keep in line with SQLAlchemy. It's a very different mindset from Django; I think there's an appropriate context for each.
digisign 5y ago
May have changed, but when I tried it, the first day with Flask was incredible. The second day, when you're ready to implement log-in and password pages, maybe email reset... you are on your own. There's six and a half third-party extension options with different overlapping scopes to research, the author of the best one has taken off for the Bahamas for two years…

peller 5y ago

I had the same pain points with Flask, so I built Flask Unchained to integrate many of the best extensions (IMO) to all work together out of the box in a reusable way: https://github.com/briancappello/flask-unchained https://github.com/briancappello/flask-unchained