5 ms·
Could someone please concisely describe if there is a use-case where Django offers utility above what Flask can provide?
by philipov 9y ago
Could someone please concisely describe if there is a use-case where Django offers utility above what Flask can provide?
- KekDemaga 9y agoI too am curious. I had trouble getting started with Django but once I tired Flask everything seemed to make sense.
- davidscolgan 9y agoA definite downside of Django is learning curve. I'd argue Django is harder at first but easier in the long term.
- charred_toast 9y agoExactly; it takes time to learn the thing—it's huge compared to Flask. The documentation is killer though. I've been learning django for at least a few years now. I try not to rush, I know I'll figure it out eventually is basically my philosophy.
- davidscolgan 9y agoDjango definitely has top tier documentation. I'd recommend first reading the official tutorial, then trying to make something with it and referring to the different sections as needed. For people wanting to go to the next level Two Scoops of Django is a fantastic book on best practices, and even more opinionated than Django, which I consider to be a great thing.
- speg 9y agoBuilt in everything. Users, auth, admin, ORM. Flask is the opposite: Bring Your Own Everything. It's not hard to replicate the functionality of Django but there is surely utility in having everything boxed up and ready to go.
- philipov 9y agoOh, I get it now. Thanks!
- andybak 9y agoYes. The joy of reasonable defaults and an opinionated way of working. Some people loathe that but it frees me to think about the customer's actual problem rather than merely tidying my pencil case.
- jon_richards 9y agoNever use the built in user. Always start a project with a custom user extending abstract user. At some point you'll want to customize the user in some way (like making the username case insensitive), and you don't want to be dealing with migration dependency conflicts when you do. For some reason the Django team is really against any attempt to fix that. They're almost hostile in their discussion of it.
- thraxil 9y agoOK. Well, I've been building Django apps since around 2007/2008. More than 50 deployed to production, many still running/maintained. Never once had a problem using the built-in user model. Do you work in some vertical that makes this a particularly common problem for you?
- jastr 9y agoI don't think the parent comment is saying don't use the built-in user model. The comment is suggesting to sub-class/extend the built-in user model. So you can use much of the built-in functionality and add/change what you'd like, eg. to add a birthday field There are obviously other ways to do this, perhaps by creating a Profile model that relates to a User.
- jon_richards 9y agoYes. Technically you should extend the abstract user model or things get real broken real fast, but that still gives you all the functionality of the built-in user model right out the gate. The main reason is that if you ever want to change how the username works, it will be a major pain to do if you've been using the built-in user model and already run migrations.
- davidscolgan 9y agoSome reasons you might pick Django over Flask: You want to be productive out of the gate - Django has the batteries included philosophy, so there's less time spent wiring together different libraries. Fewer architectural decisions - Django is fairly opinionated about where to put things (less than Rails, but more than Flask). For some people who have problems with bikeshedding, this is a big win. Having all of the pieces tightly integrated means less time fiddling. As a sidenote this can really help when onboarding new developers. A complaint I've heard with Node/ReactJS apps is that they can be organized in any number of ways, and so knowledge doesn't carry over from one project to the next as well. Class based views - Django has a really cool concept called class based views, where you can compose the "controller" functionality of your app with mixins. See ccbv.co.uk for a nice explanataion. Django is really really good at CRUD apps, and you are probably building something that does mostly CRUD or can be convinced that it is CRUD. "More popular," and therefore more people use it and therefore more open source 3rd party packages to use and more people to get help from and more people to choose from when hiring. One metric - Stack Overflow has 154k questions on Django, and 18k questions on Flask. "More mature" - this could be questionable, but Django is 12 years old vs Flask's 7 years, and Django has 25k Git commits vs Flask's 3k. This means more person-hours have gone into Django than Flask. None of this is to say that Flask is not a capable framework. It looks pretty solid for what it offers. But the choice of framework is a decision that should be informed by the business requirements, unless it is a personal project and then use whatever you want. Hope this is helpful.
- sametmax 9y agoThe killer feature is the ecosystem. You have plug and play libs for every thing.
- thraxil 9y agoIf you're building a complicated, full, user-facing application, and start with Flask, you'll find yourself reinventing most of Django. Eg, a user model with pluggable authentication and flexible permissions model, ORM with migrations and associated automatic form generation and validation, static asset compression pipeline, CSRF and CORS protection, etc. Yes, you can find Flask libraries to handle pretty much all of that stuff, but it's on you to pull it all in, glue it together, figure out which ones work well together, and document it for any one else who might work on your project. Especially for some of the security related things, it's definitely nice to know that those parts have been integrated and tested and audited already. It's a tradeoff. With flask, you can get exactly the components you like; with Django, they're mostly chosen for you. If you don't like Django's ORM, you can replace it, but then you lose a lot of the advantages that come from its integration with everything else.
- vforgione 9y agoExactly this. Every production Flask project I've seen has a massive requirements file to bolt on functionality that comes built into Django. The second I realize that I need an auth system or may potentially have a DB migration, I select Django. Frankly, I don't see the attraction to _bring your own_ frameworks in most cases (though I've done it for very specialized cases). I get paid to get projects done, not to reinvent the wheel.
- thraxil 9y agoTo extend this a bit, I would consider Flask if I didn't have a relational database. Without a relational DB, you lose the ORM and most of the ecosystem that's tied to it. At that point, something lightweight and simple is appealing. In practice though, when I've been in that situation, I've found it more compelling to just drop Python and use Go instead. I guess with a use case that relied on NumPy, Pandas, Tensorflow or something Python-specific but that didn't have a UI, I might still go with Flask.
- flavio81 9y ago>To extend this a bit, I would consider Flask if I didn't have a relational database. Use the Flask-SQLAlchemy plugin. It works beautifully. SQLAlchemy is a very good ORM.
- charred_toast 9y agoI love Flask for mini-apps and micro-services. I pretty much use it when I want to run a single python file with a web-facing component. It's also great when I need to build simple celery or task/cron-based apps. Like the other commenters have already pointed out, if you need a full-fledged website, Django.
- bigmanwalter 9y agoIf you're interested in trying a hybrid approach, I find that Web2py offers the best of both worlds. It's batteries included in that it offers most of Django's features, but the author understands API aesthetics, much like Flask's author, and so it's a delight to use. I started with Flask, tried Django, was disgusted by the gross API, and then I found web2py where I now sit happily :)