Hacker News Reader

I like Flask a lot, but I take issue with:

> It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django).

Django doesn't force a data model onto you anymore than Flask does - nobody is forcing you to use the Django ORM. Any database code you write for a Flask app could be re-used in a Django app.

What the Django ORM does do is allow you to write portable apps and extensions. For example, suppose someone writes an extension for Flask that uses SQLAlchemy. If I'm writing a Flask app and only have a Mongo database available, I can't use that extension. On the other hand, if someone uses the Django ORM to write that extension, as long as I have a Django backend for my database, I can use their extension. It abstracts away the underlying datastore. Besides just which database you are using, you can also write a variety of code that works with Django models. Now granted, this abstraction can be severely leaky and flawed at times, but it's still quite powerful overall. Django provides a conventional, standard way to address the issue of interacting with data in a general way. Again, nobody is forcing you to use it, because you can just bypass the ORM and write your database code directly. It's just a powerful paradigm if you do embrace it.

I agree that you can use Django without the ORM, but IMO it makes it kind of pointless - what advantage would you get over something more lightweight? The reason why I'd use Django over Flask is if I want to use at least a few out-of-the box solutions or extensions, say a standard Admin interface. However, I'm just the type who prefers building this stuff either myself or using standard components that are decoupled from everything else as much as possible. If an underlying framework allows me to build stuff in a tidy and quick way, that's what I'm going to use. So it's not just about what you can do, it's about how the ecosystem around that tool works.

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.

>It doesn't force a data model / DB onto me - I can just plug in whatever I have (unlike Django

When starting with Django the data model is quite inflexible and difficult to work with. Especially the primary key issues.

Check out pyramid. It is more even more 'pay as you go' than flask. And more amenable to extension (ej. Router strategies)

I can imagine there are tools that are even better than Flask for this task in some ways. Just like there are tools better than the Swiss Army knife. The thing is, there has basically never been a situation where Flask has left me wanting more, so for me it's 'good enough', thus if I try anything else it's hard to justify the cost. But for someone who's still searching I'm sure it's a good idea to check it out.