Hacker News Reader

Comment by angvp | Hacker News Reader

I think is a myth than Flask is lighter than Django, in my experience I had a Django app and a Flask app we started with Flask because we believed that myth, in the end we had an application like 10 times bigger in code, we refactored in less than a week and the performance was even better for Django than Flask app. I know this is not a Flask vs Django post, but I woudln't use something than is almost 3 years ago from the last release and they're promising a new release from almost a year.

View on HN

Calling something "lightweight" typically has nothing to do with what you end up having to do with the library to satisfy your specific use case. Flask is lightweight in the sense that it does comparably little and imposes fewer architectural dogmas. It's not lightweight in the sense that it always entails doing less work to get where you want, and I don't think that's how the word is typically used when describing technology. It's the difference between simple and easy -- Flask is perhaps simple rather than the other (when compared to Django).

In terms of utility and productivity, it all depends on what you want to achieve, of course, and I imagine that Django is a better choice in many cases, but when you already have the wheels you feel like you'd need to re-invent, and those wheels aren't the bells and whistles Django already offers I think I'd prefer using Flask.

Gonna have to agree with you. If I remember correctly the overhead is similar between Django and Flask. I love how quickly I can write a hello world app but I find that if I am building any kind of application that requires auth, db interaction, crud like actions, it ends up being easier in the long run to just run with Django.

It may be because I do not use flask enough either. I spent a little over a year working on a production flask app with a small team and I still feel no where closer in solidifying best practices and design patterns with flask.

Correct. I'm working with a flask app now and the tendency was to have a few files with thousands of lines of code - this encapsulates about 25-30 api endpoints along with all the necessary imports, etc at the top. Including sql and the usual suspects.

I think flask is great, like sinatra, for small apps. But I would never consider it for 'big' apps that represented more than half a dozen api endpoints and some sort of in-depth feature set.

Above that size, unless it's super simple, you'll pay the price in tech debt. While our api has worked up until this point, we're gonna scrap it for a Rails api-only app because we need convention + orm + other things to scale not just the app, but the team. There probably is a way to do this in flask, but 95% of our team are Rails guys, so it just makes more sense to go with q company wide maintainable system vs. what's there now.

For small/single devs working on small projects, flask (and sinatra) are great.

I have to wonder - did you try the Flask Blueprint facility? Furthermore you don't have to use the decorator approach to define the endpoints, there is a class based initialization (add_url_rule) to which you can just pass a View class. These are AFAIK the main two ways to modularize Flask code.

Reply on news.ycombinator.com