Hacker News new | past | comments | ask | show | jobs | submit login

It's obviously to a large degree personal preference, opinionated frameworks vs microframeworks. The reason why I would still use Django even if I wasn't using the ORM is because

1) I'm still probably using the ORM. I was just noting that for any data that the ORM doesn't fit well, you don't have to use it.

2) Why is Flask "lighter weight" than Django? From my perspective, as soon as you start writing a real app, you end up reinventing all these basic things like file layout using your own conventions, instead of a standard one that people are familiar with. The mental burden of figuring out your special snowflake conventions makes it 'heavier' weight to me. But again, personal preference :) Flask is obviously much better for really simple stuff, and does provide a great framework for extensions, even if I still lean towards Django.




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.


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.


That's exactly right, it's personal preference. There are people who like some things already thought out for them, and there are people who always build up a mental model of what they want first and for whom it's a burden to then have to map that model to whatever an opinionated framework wants. I think you're more the person who builds the Lego pirate ship with the instructions and then mods stuff to make it more awesome, while I'm rather the person who builds the pirate ship, then gets bored, takes it apart completely and builds something else from the ground up ;-). There's advantages and disadvantages to both modes of doing things.


Agree with m_mueller. I can never wrap my head around how Ruby or Django expects me to think, but I know exactly how I would go about building a 200-route application in flask.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: