So having used both, this is what I tend to say about them: some of Flask's commonly-used components are better than django's (SQLAlchemy notably), but altogether, django is a better framework.
I strongly disagree with the notion expressed by some that beginners should start with flask "to learn how things work". Making a sane and maintainable project layout is not a particularly easy thing to do, >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app initialization routine as a result. Django's project/app layout and initialization is really quite well considered and I would say appropriate for 99% of projects. That 1% would probably be better off with flask.
More broadly, this is the whole opinionated vs. non-opinionated debate, and I've come to the belief that the vast majority of programmers need the guidance that an opinionated framework gives. It is said that flask doesn't try to suggest any particular structure for your project, but I would say that the effect of that the majority of the time is to produce a project with no structure. Don't get me started on the pattern of `helpers.py` files everywhere: I mean - what isn't a helper? What doesn't fall into that category? So yeah, just heap everything and god knows what in that file.
It shouldn't be a shock to you by this point if I say that I don't think flask is particularly well designed either, but I won't go into my interface-by-interface rant now...
I agree about Flash/Django. But SQLAlchemy is definitely not "better". It is more powerful, more correct, more proper, more flexible. But boy is it a fucking obtuse, verbose, difficult piece of bahoo to use. Django ORM follows Django's philosophy of pragmatism. Assume sane defaults/be opinionated. Make the easy, everyday shit easy! The hard stuff can be figured out later (or just drop to raw SQL). SQLAlchemy's philosophy is to be correct, like RDBMA academic correct and proper. Make the insanely rare and/or difficult stuff possible even if it means making the common stuff a PITA.
It's like the difference between an esoteric and powerful language like Haskell which is objectively more correct. And Python, which is "who cares purity, it lets me get shit done fast and easy."
There's also, I think, a huge divide in the way developers think/reason about problems. Cause I've never seen anyone like both ORMs. Everyone likes/tolerates one and hates the other. I'm guessing some devs "think" the way SQLAlchemy works and others "think" the way DjangoORM works.
So, I do think both ORMs have their place. Just wish SQLAlchemy's place was not in code I have to write/maintain.
>More broadly, this is the whole opinionated vs. non-opinionated debate, and I've come to the belief that the vast majority of programmers need the guidance that an opinionated framework gives.
The vast majority of programmers need opinionated because they want to string together 15 or 20 different plugins to do ordinary things like CMS, rate limiting, caching, facebook/github authentication, csv export from the admin, drag and drop within admin, and hundreds of other things where you don't want to reinvent the wheel.
With Django there is a larger ecosystem and those modules tend to play better together, and they are pretty much equally loosely coupled. With Flask you get a few modules that use SQLAlchemy, some that use peewee and others like Quokka (flask CMS) that just decided to use mongo for the hell of it. That's the dark side of not being opinionated.
The "batteries included" argument is a red herring, IMO. It doesn't really matter that Django includes admin in the 'django' package and flask separates it out into 'flask-admin'. You don't have to use either if you don't want and being in a different package is orthogonal to coupling.
The magic argument is also sometimes a bit of a red herring too. SQLAlchemy, django ORM, django admin and flask admin all use tons of magic but everybody loves them. Magic is horrible in the wrong place but incredibly powerful in the right place. Rails gave it a bad rep because it used magic too much in the wrong places.
What about Django makes you feel it is the better framework? It's a great singular package, but basically everything in it is done better somewhere else. I'd take Flask's templates over Django's any day and Peewee or SQLA over Django's ORM as well. I never liked regexs for routing and as I've gotten older and liked regexs more, still don't like that approach - Flask's approach is better.
Django is nice for beginners cause you can say "learn this" and they've got a bunch of books and docs to go through, but having watched Django evolve over the last decade, it hasn't really changed from it's stable but boring and does nothing best manner.
They're both kind of dead tech anyway given enough time. Python isn't the best choice for today's websites. That being said, don't know what language/framework is the right thing to push on a beginner.
> So having used both, this is what I tend to say about them: some of Flask's commonly-used components are better than django's (SQLAlchemy notably), but altogether, django is a better framework.
Most Flask dev however, are unable to leverage the full power of SQLalchemy. They do miss the nice integration of the Django ORM, espacially the form generation, admin and fantastic app ecosystem that assumes you have a User object.
> Making a sane and maintainable project layout is not a particularly easy thing to do
+1000 on this. I noticed this as a dev AND a trainer. In the end, flask is great if you are either very beginer and want to do simple things, or very experienced. For all the rest, you want Django.
But the price to pay to enter the Django world is higher.
> It shouldn't be a shock to you by this point if I say that I don't think flask is particularly well designed either, but I won't go into my interface-by-interface rant now...
Well, the global objects such as request is one of my pet peeve... And the decision of a central "app" object make modularity kinda difficult, and blueprint feel like afterthoughts.
But flask also almost invented the whole @route API, which is really awesome.
> I strongly disagree with the notion expressed by some that beginners should start with flask "to learn how things work". Making a sane and maintainable project layout is not a particularly easy thing to do, >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app initialization routine as a result. Django's project/app layout and initialization is really quite well considered and I would say appropriate for 99% of projects. That 1% would probably be better off with flask.
I actually feel like this is why I recommend beginners start with Flask though. I think learning the mistakes and seeing the problems and pain firsthand let's you appreciate and hopefully understand the decisions that were made.
Of course, I should say I recommend it for something like a toy project that you don't intend to maintain. If it's something that's long term then I would agree that Django is likely to be the better choice.
In the end I suppose everyone is different in the same way some people recommend learning Python vs C as their first language.
I was never able to do what I wanted to do in Django. The moment you have something that even slightly breaks apart from the MVC model, it all breaks down. It's great for a blog or simple web app, but not much more than that.
In Django I always felt like I had to do things the Django way. In Flask I always felt like I was doing things the Python way.
That makes sense about project organization done correctly.
The thing that really stands out about Flask to me (using it for small projects, I don't really get to use Python at my day job) is that the codebase is incredibly easy to understand in it's entirety. Anytime I have needed to look something up I can go to the code and usually understand it within a minute or so.
I'd classify myself as a mediocre programmer by big tech company standards and Flask is very easy for me to understand and use.
I would have to agree with you, there's no point in learning Flask if you're going to do Django projects. Things don't translate well between the two. I like both frameworks, for different things, but you shouldn't try to do a Flask application in Django.
To benefit from Django, you need to do exactly what the documentation want you to do. You'll be happier, everything will be easier and you write a LOT less code. I tried fighting Django, because I didn't agree with some of the design decision, especially in the Django Rest Framework. The result was a worse product, too much and too complex code. The rewritten version did everything "The Django Way". It took less time, and the result was infinitely more understandable and testable.
> >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app
tbh I've seen this plenty of times regardless of whichever framework people choose. At least with Flask the original developer sometimes gets a twinge of 'hmm this seems like a lot of work & might be a mistake'; Django smooths it over so you end up with cached property counts for things which are trivially computable from the DB (+the associated invalidation bugs).
> It is said that flask doesn't try to suggest any particular structure for your project, but I would say that the effect of that the majority of the time is to produce a project with no structure.
Don't blame Flask, blame whoever hired mediocre developers in your company. No framework that "enforces" things will compensate for bad human capital.
> I strongly disagree with the notion expressed by some that beginners should start with flask "to learn how things work". Making a sane and maintainable project layout is not a particularly easy thing to do
I always saw it as Django is the lady with the 30 pound purse that has everything you could possibly need on a trip to disneyland and Flask was the guy who showed up to the camping trip wondering why everybody else brought a tent when it's so nice out.
I'm working with a large, 5 year old Django codebase. My humble opinion: Django itself is actively hindering our ability to deliver new features.
Some pain points:
- Django's fat models approach is bad. By coupling model behaviour to database schema, it all but guarantees that you're gonna have a tough time modifying either.
- Django's class-based views and its admin framework strongly encourages a sort of "one-view, one-model" approach. Just about nobody has requirements that neatly fit that worldview. If you need to interact with two models in a single view, working around it is painful.
- Not Django specific, but Python is a bad choice to use at scale. The lack of a good default immutable data structure means we're stuck using mutable data structures everywhere. In a large codebase, the lack of guarantees around something as basic as the shape of a data structure is a huge problem. A notorious example is Django's HttpRequest, whose attributes may or may not be set by the middlewares.
There are more, but one thing's for sure, I probably won't be using Django for my next project.
I'm a heavy Django user, but I work on a lot of data-intensive projects. I do my data modeling in the database and expose it to Django, and it feels pretty clean to me. I use the ORM for what I would consider its true purpose: converting relations and attributes to objects and properties. I use it very lightly, otherwise, like for filtering and sorting.
* Create primary "fact" models for the things you are CRUDing.
* Process the data in the database. Write your complex operations in SQL, and expose them as views.
* Create corresponding Django models on top of the views. These are not as "fat" because they are unmanaged models that just facilitate getting processed data to the user.
If you're using a good database, you accommodate writes through the views as well. I rarely find a good reason to do this, but when it comes up, it works great. It is especially useful when dealing with legacy schemas.
It won't help you with handling code size so big you really want types, but one advice I would give is ditch class based views. I find that function views much easier to reason about, even if it leads to code duplication. The ability to read the code linearly without jumping through inheritance hierarchies makes everything better.
while django encourages Fat Models and that approach ends up working well sometimes, django itself has no such approach to models. how much logic to put in a model is left to the application developer.
i think what tends to happen, though, is that coming up with a convention different than Fat Models is difficult, especially early on, so most organizations don't bother and end up with models that are badly abstracted AND fat.
this could be seen as a failure of the django community, but it is not a shortcoming of the framework itself.
You can still opt for function-based views almost 100% of the time. Though I'm a big fan of FBVs for "You see what you get", I've started to find that writing your own, project-specific CBVs might pay off for speed + enforcing style in handling requests though.
Fat models are most definitely a pain. Our solution has been to not rely on models for almost anything except for DB interaction, and instead have wrappers that act as business functions. So instead of Post.objects.create, you just write create_post. You still get ORM goodness for the most part, but your validation/creation layer is under control so you can apply your style.
Overall, Django's defaults and even the fat model approach can work really well if you're writing a CMS, for example. And fortunately it's getting easier and easier to use only what you want.
I hear you for the mutability of request objects. Mypy has helped us out a lot, but Django is pretty resistant to those.
The problem with this sort of advice though is that everyone likes to think their project will go hyperscale, or will be prepared to if necessary. The reality is that very very few of them ever need to yet so many design with this is mind not understanding the tradeoffs and what they're losing by following this approach. (Incidentally I also attribute much of the current popularity of microservices to this idea)
The fact is that once you hit hyperscale you should almost certainly not be using the same codebase as when you were still establishing exactly what your project should do.
For most projects, the fat models approach works really very well and I don't feel is something that people should be dissuaded from. For most projects, the alternatives are far harder to get clean results from.
Used both and off the bat found Flask breezy and Django bureaucratic. But then the next day with Flask you look up how to do something elementary like login (for fsck sakes) and find there's alternatives of various qualities and scopes, and the flask-security guy has disappeared. Found myself spending a full week up front wrangling tokens and other crap instead of the project at hand, sigh. Django starts to shine at that point.
Lately I've been yearning for a "Flango" distribution with flask and the top twenty extensions supported by a single dev team.
It could use some documentation and some community TLC, but Level 12 is a solid Python shop with a pragmatic approach to app development. There are libraries for auth, login, webgrids, SQLAlchemy, forms, etc etc.
Disclaimer: I used to work for Level 12 and wrote a large production app atop keg.
I feel like Django has too much magic. I agree that it is easier to get quick wins with Django, and if you're building a small hobby site or something, then it's great.
But if you're building something that you hope you'll have to rapidly scale, Django is going to hurt you. It's way harder to scale due to both its heavy reliance on hidden magic its tight integration with its data store.
When you want to rapidly scale, the easiest way to do that is if your data store and application aren't so tightly intertwined that you have to scale both to solve a bottleneck in either.
Flask is still one of my favorites in web frameworks, mainly because it was from the Sinatra/microframework moment and still is a pleasure to work with. Just plugin other micro frameworks for the data, middleware, routing, templating as desired.
Express is similar in Node still because of the simplicity and micro size of it.
Micro frameworks don't dictate and grow with a product as needed rather than growing into a monolith and it dictating too much.
As far as Django, it is still one of the most desirable monoliths out there but you don't have to use it that way. However, it is meant to take over like Angular, Rails, MVC etc.
Hmmm. OK. Read through most of this thread. Not sure I agree with some of what is being said about Django. In particular about this "magic" thing.
It took me a while to get comfortable with Django. I tried to learn it on and off for about four years. I finally decided the only way to do it was to focus, commit to it and not jump off into something else until I got it.
That probably took about six months. Much of it felt confusing and, yes, magical. Until I made one more decision: Read The Source Luke.
Seriously. I started to look things up in Django source code. Every single time I came across something I did not understand or that seemed magical I went to source. It was painful at first but it became easier as it turned into a habit.
And then it happened, one day it just clicked. What seemed like a confusing mess months earlier made complete sense. It almost felt like this happened overnight, which wasn't the case.
I now believe the best way to learn Django is to do it exactly this way. Have the source open on another monitor and look-up everything as you go through a tutorial or book. In the process you'll discover much more than what you were looking for originally.
I find myself doing this more and more often with python libraries, even with the well-documented ones like Django REST Framework - always keep a source browser open on the virtualenv dir so I can read library source. There's something about the style of python documentation that makes it difficult to really understand how the classes in a library fit together, so this is necessary for larger python frameworks.
(My personal gold standard for programmer reference documentation has been the Qt API docs for very, very long. They've varied in quality over the years but they're always an example of how to do it.)
Flask is great since you can mix and match different parts from the toolbox and build/use exactly what you want. But it is easy to end up at a point where you are just rewriting your own mini-Django on top of Flask.
Django on the other hand brings a full meal to the table. Using other toys from the toolbox is certainly possible, but it feels "wrong". And yes, Django certainly has some rough/not-so-shiny edges here and there, partly due to legacy code that cant be easily refactored due to compatibility. But overall it gets the job done and it gets polished more with every release.
At the end of the day, it comes down to personal preference.
To paraphrase: "Whoever does not know Django, is doomed to reinvent it".
You can use Django with its "batteries included" philosophy. Or you can use Flask and start adding in lots of extra libraries (which may or may not play together nicely) to get an ORM, user models, admin site, etc. etc. So you end up reinventing a full web framework based on Flask.
I've done trivial and non-trivial projects in both, and the general summary presented here feels correct. If you've got something with content, that matches most common situations (users, content related to users, content related to other content), Django will get you there quickly and efficiently.
But I still use Flask a lot more, because most of what I create are limited use web services that do interesting things behind the scenes. Caching proxies to improve performance of legacy services, script runners, report generation tools.
Most of the time, Flask feels like the de facto web server, like Requests is the de facto web client.
For nearly a decade now, Python has been my web project language of choice. I started out working exclusively with Django, and I still applaud the rock-solidness and the convenience of Django. However, over the past few years I've shifted entirely to Flask, and I now code most new projects (no matter what size) in Flask, whenever I have a choice.
Flask's main strength over Django, in my opinion, is that it does things in a more modern and a more Pythonic way. The nice "app" object and nice import of settings in Flask, that lets you instantiate multiple app objects in a single process, vs the global app / settings in Django. The use of contexts for exposing requests, sessions, and the like in Flask, vs using arguments and globals in Django. The breakdown into separate, lightweight, independently-usable projects for WSGI toolkit, template engine, CLI toolkit, etc in Flask, vs the monolithic project that is Django.
I have always thought of Flask as the natural and the worthy successor to Django, in terms of being the gold standard among Python web frameworks.
Yes, Flask's ecosystem is sometimes hit-and-miss in terms of code being well-maintained and integrating together reliably. But, considering the number of disparate projects and authors involved, it is actually (in general) quite stable and it does all work nicely.
In terms of helping to enforce a good code structure, and in terms of bundling together popular third-party libraries for Flask, there are a number of utilities that can help. My personal favourite is https://github.com/sloria/cookiecutter-flask , but there are others.
On my next side project will use pyramid next aiohttp or tornado. Python has a good ecosystem of libs. Pick one when you need it. Django is perhaps the less pythonic option. After some time doing go and js.. I prefer the lib approach.. on the end you don't need so many things to quickly respond to http requests ;)
Pyramid really is the underappreciated hidden gem in Python web development. It can be as much of an micro- or full stack framework as you need it to be, while being much better thought out and extensible than something like Flask or Bottle.
No crazy thread local state imports to complicate testing and encourage people to couple their code to the web framework, features like renderers to make _unit_ testing view functions easy, almost 100% test coverage in all the core libraries...
It's a shame that the mainstream basically boils down to Django or Flask. But it's no wonder that organizations like Mozilla and new PyPi are building on Pyramid instead.
I've been building stuff in sanic, which is built on uvloop and is super fast. I can recommend it if you're willing to sacrifice a bit of project maturity for a solid async webserver.
I started out with Zope 15 yrs ago, then switched to Django. Now I use Tornado for it's support for web sockets and an async programming style. Tornado coroutines work beautifully with RethinkDB.
Django re-usable apps and admin is the killer feature, making it a breeze to do 99% of the work on most agencies websites and then the 1% is just tying it together.
But I'm missing a good abstraction over Django, with most websites features included (user registration, job runner, webpack integration). Also I've come to hate django templates DSL so much I'm now only using a non-DSL method[0] (but it's kinda painful when you want to use apps, making you appreciate standardization)
Do you already know Django really well? Then use Django for small and big web projects.
Do you not know either? Then learn Flask for small, trivial applications and learn Django when you find yourself creating your own web framework on top of Flask.
You adapt yourself, and your requirements, to Django. Django is "convention over configuration" which means thar first you need to learn all conventions. This takes time.
You adapt Flask to your requirements and your preferences. You build Flask to your liking and needs. Flask is extremely easy to learn.
I think both Django and Flask are good frameworks that solve different problems. Django has a batteries included philosophy that gets you up and running quickly without ever leaving Python (as the developer). Flask is drastically less opinionated and focuses on providing you web hooks to bring your project/logic to the web letting you do whatever you need behind the scenes.
Personally, I feel like Django is great for a "traditional" and straightforward web applications and Flask is better for projects that may require a bit more flexibility both in modeling and backing services.
I think this line from the article follows this perspective:
> Before long, projects will be dealing with forms, REST endpoints and other things that are all best represented via a declarative model with types. The exact stance Django’s applications take from the beginning.
The first application I worked in from the ground-up is a flask app; quite a learning experience, to put it lightly. Despite the amount of technical debt accumulated, however, I don't regret it. I grew a lot as a developer and became more knowledgeable about web development in general.
I picked flask then because I, rather dogmatically, distrusted Django and its batteries included approach. Nowadays, I think it's great and almost the perfect choice to prototype something quickly. That said, if I felt the application would grow in functionality too much, I'd use Flask. Django gets in one's way rather quickly.
One of these things is not like the other. You don't have to choose and there will be cases for both where one is the vastly superior choice. For example: I'd go with Flask for microservices but django for a CMS. I'm sure some people will argue the more apposite. The nodejs thing is so fragmented and difficult by comparison. Flask's routes are better. django's admin absolutely rocks (still). I guess these face-offs are fun but I don't find them very informative, relevant or meaningful. A weird hybrid though - now that would be cool. Or a SAP killer in django.
My apprehension about using flask for microservices is that calls to another microservices are going to block. With NodeJS, the webserver and http libraries are async and mature. Python's really missing a solid async requests library (but async webservers like sanic are getting better).
I worked with flask once. It was code made by an obviously gifted russian coder i worked with. Cleanest webcode i have seen. I never played with django, all i can say is flask can produce really clean code.
Python in general does this. Its designed to be readable first in most regards, something really valuable for other languages to learn - for every line written, it will probably be read dozens of times. Optimizing for the writing part with arcane or convoluted syntax at the expense of legibility only makes projects age poorly.
[+] [-] ris|8 years ago|reply
I strongly disagree with the notion expressed by some that beginners should start with flask "to learn how things work". Making a sane and maintainable project layout is not a particularly easy thing to do, >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app initialization routine as a result. Django's project/app layout and initialization is really quite well considered and I would say appropriate for 99% of projects. That 1% would probably be better off with flask.
More broadly, this is the whole opinionated vs. non-opinionated debate, and I've come to the belief that the vast majority of programmers need the guidance that an opinionated framework gives. It is said that flask doesn't try to suggest any particular structure for your project, but I would say that the effect of that the majority of the time is to produce a project with no structure. Don't get me started on the pattern of `helpers.py` files everywhere: I mean - what isn't a helper? What doesn't fall into that category? So yeah, just heap everything and god knows what in that file.
It shouldn't be a shock to you by this point if I say that I don't think flask is particularly well designed either, but I won't go into my interface-by-interface rant now...
[+] [-] njharman|8 years ago|reply
It's like the difference between an esoteric and powerful language like Haskell which is objectively more correct. And Python, which is "who cares purity, it lets me get shit done fast and easy."
There's also, I think, a huge divide in the way developers think/reason about problems. Cause I've never seen anyone like both ORMs. Everyone likes/tolerates one and hates the other. I'm guessing some devs "think" the way SQLAlchemy works and others "think" the way DjangoORM works.
So, I do think both ORMs have their place. Just wish SQLAlchemy's place was not in code I have to write/maintain.
[+] [-] crdoconnor|8 years ago|reply
The vast majority of programmers need opinionated because they want to string together 15 or 20 different plugins to do ordinary things like CMS, rate limiting, caching, facebook/github authentication, csv export from the admin, drag and drop within admin, and hundreds of other things where you don't want to reinvent the wheel.
With Django there is a larger ecosystem and those modules tend to play better together, and they are pretty much equally loosely coupled. With Flask you get a few modules that use SQLAlchemy, some that use peewee and others like Quokka (flask CMS) that just decided to use mongo for the hell of it. That's the dark side of not being opinionated.
The "batteries included" argument is a red herring, IMO. It doesn't really matter that Django includes admin in the 'django' package and flask separates it out into 'flask-admin'. You don't have to use either if you don't want and being in a different package is orthogonal to coupling.
The magic argument is also sometimes a bit of a red herring too. SQLAlchemy, django ORM, django admin and flask admin all use tons of magic but everybody loves them. Magic is horrible in the wrong place but incredibly powerful in the right place. Rails gave it a bad rep because it used magic too much in the wrong places.
[+] [-] aaron-lebo|8 years ago|reply
Django is nice for beginners cause you can say "learn this" and they've got a bunch of books and docs to go through, but having watched Django evolve over the last decade, it hasn't really changed from it's stable but boring and does nothing best manner.
They're both kind of dead tech anyway given enough time. Python isn't the best choice for today's websites. That being said, don't know what language/framework is the right thing to push on a beginner.
[+] [-] sametmax|8 years ago|reply
Most Flask dev however, are unable to leverage the full power of SQLalchemy. They do miss the nice integration of the Django ORM, espacially the form generation, admin and fantastic app ecosystem that assumes you have a User object.
> Making a sane and maintainable project layout is not a particularly easy thing to do
+1000 on this. I noticed this as a dev AND a trainer. In the end, flask is great if you are either very beginer and want to do simple things, or very experienced. For all the rest, you want Django.
But the price to pay to enter the Django world is higher.
> It shouldn't be a shock to you by this point if I say that I don't think flask is particularly well designed either, but I won't go into my interface-by-interface rant now...
Well, the global objects such as request is one of my pet peeve... And the decision of a central "app" object make modularity kinda difficult, and blueprint feel like afterthoughts.
But flask also almost invented the whole @route API, which is really awesome.
[+] [-] rifung|8 years ago|reply
I actually feel like this is why I recommend beginners start with Flask though. I think learning the mistakes and seeing the problems and pain firsthand let's you appreciate and hopefully understand the decisions that were made.
Of course, I should say I recommend it for something like a toy project that you don't intend to maintain. If it's something that's long term then I would agree that Django is likely to be the better choice.
In the end I suppose everyone is different in the same way some people recommend learning Python vs C as their first language.
[+] [-] dheera|8 years ago|reply
In Django I always felt like I had to do things the Django way. In Flask I always felt like I was doing things the Python way.
[+] [-] plandis|8 years ago|reply
The thing that really stands out about Flask to me (using it for small projects, I don't really get to use Python at my day job) is that the codebase is incredibly easy to understand in it's entirety. Anytime I have needed to look something up I can go to the code and usually understand it within a minute or so.
I'd classify myself as a mediocre programmer by big tech company standards and Flask is very easy for me to understand and use.
[+] [-] mrweasel|8 years ago|reply
To benefit from Django, you need to do exactly what the documentation want you to do. You'll be happier, everything will be easier and you write a LOT less code. I tried fighting Django, because I didn't agree with some of the design decision, especially in the Django Rest Framework. The result was a worse product, too much and too complex code. The rewritten version did everything "The Django Way". It took less time, and the result was infinitely more understandable and testable.
[+] [-] falsedan|8 years ago|reply
tbh I've seen this plenty of times regardless of whichever framework people choose. At least with Flask the original developer sometimes gets a twinge of 'hmm this seems like a lot of work & might be a mistake'; Django smooths it over so you end up with cached property counts for things which are trivially computable from the DB (+the associated invalidation bugs).
[+] [-] flavio81|8 years ago|reply
Don't blame Flask, blame whoever hired mediocre developers in your company. No framework that "enforces" things will compensate for bad human capital.
[+] [-] tvaughan|8 years ago|reply
For help with this: https://www.starterkit.win/
[+] [-] field0fsilicons|8 years ago|reply
[+] [-] Steeeve|8 years ago|reply
[+] [-] MichaelRenor|8 years ago|reply
[+] [-] hetspookjee|8 years ago|reply
[+] [-] yen223|8 years ago|reply
Some pain points:
- Django's fat models approach is bad. By coupling model behaviour to database schema, it all but guarantees that you're gonna have a tough time modifying either.
- Django's class-based views and its admin framework strongly encourages a sort of "one-view, one-model" approach. Just about nobody has requirements that neatly fit that worldview. If you need to interact with two models in a single view, working around it is painful.
- Not Django specific, but Python is a bad choice to use at scale. The lack of a good default immutable data structure means we're stuck using mutable data structures everywhere. In a large codebase, the lack of guarantees around something as basic as the shape of a data structure is a huge problem. A notorious example is Django's HttpRequest, whose attributes may or may not be set by the middlewares.
There are more, but one thing's for sure, I probably won't be using Django for my next project.
[+] [-] ibejoeb|8 years ago|reply
* Create primary "fact" models for the things you are CRUDing.
* Process the data in the database. Write your complex operations in SQL, and expose them as views.
* Create corresponding Django models on top of the views. These are not as "fat" because they are unmanaged models that just facilitate getting processed data to the user.
If you're using a good database, you accommodate writes through the views as well. I rarely find a good reason to do this, but when it comes up, it works great. It is especially useful when dealing with legacy schemas.
[+] [-] wolf550e|8 years ago|reply
[+] [-] rguzman|8 years ago|reply
while django encourages Fat Models and that approach ends up working well sometimes, django itself has no such approach to models. how much logic to put in a model is left to the application developer.
i think what tends to happen, though, is that coming up with a convention different than Fat Models is difficult, especially early on, so most organizations don't bother and end up with models that are badly abstracted AND fat.
this could be seen as a failure of the django community, but it is not a shortcoming of the framework itself.
[+] [-] rtpg|8 years ago|reply
Fat models are most definitely a pain. Our solution has been to not rely on models for almost anything except for DB interaction, and instead have wrappers that act as business functions. So instead of Post.objects.create, you just write create_post. You still get ORM goodness for the most part, but your validation/creation layer is under control so you can apply your style.
Overall, Django's defaults and even the fat model approach can work really well if you're writing a CMS, for example. And fortunately it's getting easier and easier to use only what you want.
I hear you for the mutability of request objects. Mypy has helped us out a lot, but Django is pretty resistant to those.
[+] [-] ris|8 years ago|reply
The fact is that once you hit hyperscale you should almost certainly not be using the same codebase as when you were still establishing exactly what your project should do.
For most projects, the fat models approach works really very well and I don't feel is something that people should be dissuaded from. For most projects, the alternatives are far harder to get clean results from.
[+] [-] neospice|8 years ago|reply
[+] [-] mixmastamyk|8 years ago|reply
Don't completely understand this one. Also, couldn't you create an immutable-in-practice class?
[+] [-] mixmastamyk|8 years ago|reply
Lately I've been yearning for a "Flango" distribution with flask and the top twenty extensions supported by a single dev team.
[+] [-] nZac|8 years ago|reply
It could use some documentation and some community TLC, but Level 12 is a solid Python shop with a pragmatic approach to app development. There are libraries for auth, login, webgrids, SQLAlchemy, forms, etc etc.
Disclaimer: I used to work for Level 12 and wrote a large production app atop keg.
[+] [-] bradmwalker|8 years ago|reply
[+] [-] jedberg|8 years ago|reply
But if you're building something that you hope you'll have to rapidly scale, Django is going to hurt you. It's way harder to scale due to both its heavy reliance on hidden magic its tight integration with its data store.
When you want to rapidly scale, the easiest way to do that is if your data store and application aren't so tightly intertwined that you have to scale both to solve a bottleneck in either.
[+] [-] drawkbox|8 years ago|reply
Express is similar in Node still because of the simplicity and micro size of it.
Micro frameworks don't dictate and grow with a product as needed rather than growing into a monolith and it dictating too much.
As far as Django, it is still one of the most desirable monoliths out there but you don't have to use it that way. However, it is meant to take over like Angular, Rails, MVC etc.
[+] [-] martin_hnuid|8 years ago|reply
It took me a while to get comfortable with Django. I tried to learn it on and off for about four years. I finally decided the only way to do it was to focus, commit to it and not jump off into something else until I got it.
That probably took about six months. Much of it felt confusing and, yes, magical. Until I made one more decision: Read The Source Luke.
Seriously. I started to look things up in Django source code. Every single time I came across something I did not understand or that seemed magical I went to source. It was painful at first but it became easier as it turned into a habit.
And then it happened, one day it just clicked. What seemed like a confusing mess months earlier made complete sense. It almost felt like this happened overnight, which wasn't the case.
I now believe the best way to learn Django is to do it exactly this way. Have the source open on another monitor and look-up everything as you go through a tutorial or book. In the process you'll discover much more than what you were looking for originally.
[+] [-] sirtaj|8 years ago|reply
(My personal gold standard for programmer reference documentation has been the Qt API docs for very, very long. They've varied in quality over the years but they're always an example of how to do it.)
[+] [-] n0clu|8 years ago|reply
[+] [-] sparkling|8 years ago|reply
For tiny applications: go with Flask.
For medium and big applications: it depends.
Flask is great since you can mix and match different parts from the toolbox and build/use exactly what you want. But it is easy to end up at a point where you are just rewriting your own mini-Django on top of Flask.
Django on the other hand brings a full meal to the table. Using other toys from the toolbox is certainly possible, but it feels "wrong". And yes, Django certainly has some rough/not-so-shiny edges here and there, partly due to legacy code that cant be easily refactored due to compatibility. But overall it gets the job done and it gets polished more with every release.
At the end of the day, it comes down to personal preference.
[+] [-] ishi|8 years ago|reply
You can use Django with its "batteries included" philosophy. Or you can use Flask and start adding in lots of extra libraries (which may or may not play together nicely) to get an ORM, user models, admin site, etc. etc. So you end up reinventing a full web framework based on Flask.
[+] [-] passive|8 years ago|reply
But I still use Flask a lot more, because most of what I create are limited use web services that do interesting things behind the scenes. Caching proxies to improve performance of legacy services, script runners, report generation tools.
Most of the time, Flask feels like the de facto web server, like Requests is the de facto web client.
[+] [-] jaza|8 years ago|reply
Flask's main strength over Django, in my opinion, is that it does things in a more modern and a more Pythonic way. The nice "app" object and nice import of settings in Flask, that lets you instantiate multiple app objects in a single process, vs the global app / settings in Django. The use of contexts for exposing requests, sessions, and the like in Flask, vs using arguments and globals in Django. The breakdown into separate, lightweight, independently-usable projects for WSGI toolkit, template engine, CLI toolkit, etc in Flask, vs the monolithic project that is Django.
I have always thought of Flask as the natural and the worthy successor to Django, in terms of being the gold standard among Python web frameworks.
Yes, Flask's ecosystem is sometimes hit-and-miss in terms of code being well-maintained and integrating together reliably. But, considering the number of disparate projects and authors involved, it is actually (in general) quite stable and it does all work nicely.
In terms of helping to enforce a good code structure, and in terms of bundling together popular third-party libraries for Flask, there are a number of utilities that can help. My personal favourite is https://github.com/sloria/cookiecutter-flask , but there are others.
[+] [-] jordic|8 years ago|reply
[+] [-] veeti|8 years ago|reply
No crazy thread local state imports to complicate testing and encourage people to couple their code to the web framework, features like renderers to make _unit_ testing view functions easy, almost 100% test coverage in all the core libraries...
It's a shame that the mainstream basically boils down to Django or Flask. But it's no wonder that organizations like Mozilla and new PyPi are building on Pyramid instead.
[+] [-] cshenton|8 years ago|reply
See https://magic.io/blog/uvloop-blazing-fast-python-networking/ for a full write up.
I've been building stuff in sanic, which is built on uvloop and is super fast. I can recommend it if you're willing to sacrifice a bit of project maturity for a solid async webserver.
[+] [-] osullivj|8 years ago|reply
[+] [-] Buetol|8 years ago|reply
But I'm missing a good abstraction over Django, with most websites features included (user registration, job runner, webpack integration). Also I've come to hate django templates DSL so much I'm now only using a non-DSL method[0] (but it's kinda painful when you want to use apps, making you appreciate standardization)
[0]: https://github.com/mdamien/lys
[+] [-] mychael|8 years ago|reply
Do you already know Django really well? Then use Django for small and big web projects.
Do you not know either? Then learn Flask for small, trivial applications and learn Django when you find yourself creating your own web framework on top of Flask.
[+] [-] flavio81|8 years ago|reply
You adapt yourself, and your requirements, to Django. Django is "convention over configuration" which means thar first you need to learn all conventions. This takes time.
You adapt Flask to your requirements and your preferences. You build Flask to your liking and needs. Flask is extremely easy to learn.
[+] [-] gshulegaard|8 years ago|reply
Personally, I feel like Django is great for a "traditional" and straightforward web applications and Flask is better for projects that may require a bit more flexibility both in modeling and backing services.
I think this line from the article follows this perspective:
> Before long, projects will be dealing with forms, REST endpoints and other things that are all best represented via a declarative model with types. The exact stance Django’s applications take from the beginning.
[+] [-] luord|8 years ago|reply
I picked flask then because I, rather dogmatically, distrusted Django and its batteries included approach. Nowadays, I think it's great and almost the perfect choice to prototype something quickly. That said, if I felt the application would grow in functionality too much, I'd use Flask. Django gets in one's way rather quickly.
[+] [-] nthcolumn|8 years ago|reply
[+] [-] cshenton|8 years ago|reply
[+] [-] timwaagh|8 years ago|reply
[+] [-] zanny|8 years ago|reply
[+] [-] welder|8 years ago|reply
https://wakatime.com/django-vs-flask-worksheet
With a comparison between the two:
https://wakatime.com/blog/14-pirates-use-flask-the-navy-uses...
Your guide is way more comprehensive, so mind if I link to it?