I gave a pretty detailed response here: https://news.ycombinator.com/item?id=14026051 https://news.ycombinator.com/item?id=14026051 - Django may be "batteries

I gave a pretty detailed response here: https://news.ycombinator.com/item?id=14026051 https://news.ycombinator.com/item?id=14026051 - Django may be "batteries included", but definitely not monolithic. It's your choice how you want to implement views. Nothing's tying you down to using a DetailView, but by conforming to them, you make your code more readable and consistent. You can also pick your own template system, like Jinja2, but django templates are still fast, intuitive, and powerful. You don't have to pull in every contrib module and CBV. You don't have to use django.forms, but they save a lot of time with form validation. You don't have to use ModelForm (ORM-backed forms), but it gives you the ability to get database-backed form behavior with little work. They're also designed to be customizable for specialized scenarios. Django is designed from the ground up to let you override and expand. django.forms build upon the "field" API (https://docs.djangoproject.com/en/1.11/ref/forms/fields/ https://docs.djangoproject.com/en/1.11/ref/forms/fields/), which represents the data sent back and forth. And widgets, the HTML representation (https://docs.djangoproject.com/en/1.11/ref/forms/widgets/ https://docs.djangoproject.com/en/1.11/ref/forms/widgets/). You can use django, and build your own fields and widgets to use with forms. You don't have to load every template tag and filter library. It's configurable on a per-template (per-file) basis. You don't have to use the auth system, but if you do, you can still use a custom User model and backend (https://docs.djangoproject.com/en/1.11/topics/auth/customizing/ https://docs.djangoproject.com/en/1.11/topics/auth/customizi...). But you're going to have to conform to some sensible conventions (such as a settings modules, urls.py, request contexts). In most situations, you'll pull in stuff from django.contrib, like django.contrib.auth, and occasionally you'll write your own custom replacements. And you'll end up using the ORM. - While it's not SQLAlchemy, Django's ORM is capable. It may not have as many bells and whistles, but Django ORM is not "weaker" in any sense. It's been used in production for 10+ years and works across SQL dialects. In a pinch, one-off custom queries have.raw(), and I could still run those safely thanks to params (https://docs.djangoproject.com/en/1.11/topics/db/sql/#passing-parameters-into-raw https://docs.djangoproject.com/en/1.11/topics/db/sql/#passin...). Also, the migration system is nice. - While development settings can be slow when you're using asset managers (like django-compressor), Django can scale. Of course if you're rebuilding SASS every refresh and not using cache, you're going to have 500ms to 1 second page loads that can be cringey if you're hauling in bootstrap. But in practice, you're going to be compressing those files in production and using caching settings. - Testing can be fast. My favorite tool is RequestFactory (https://docs.djangoproject.com/en/1.11/topics/testing/advanced/#the-request-factory https://docs.djangoproject.com/en/1.11/topics/testing/advanc...). I could run about 100+ tests in about 300ms. So every time I saved, I checked the permissions/integrity of all my views, including ones which used the ORM.