| Strongly agree. For me the mark of a useful framework is that is reduces the complexity of the task you are trying to do. If it increases the complexity of the task, it isn't the right tool for the job! Choosing the right level of abstraction is the most important part of software engineering. If all you need is HTTP routing, then Flask is great, but every time I tried to use it for the kinds of things Django is great at (databasing, templating, forms), I had to effectively roll my own crappy version of Django. (Something something every sufficiently large C++ program has a poorly implemented version of LISP embedded into it.) I saw this dramatically demonstrated by an enormous Flask installation that would have greatly benefited from a little imposed structure. I bounced hard from that gig after being shown the code because it was going to be a massive pain to understand the poorly designed abstractions. But it wasn't even the maintainer's fault - it was pretty good code but it had only been designed by one person, both the abstractions and the business logic. And the abstractions were leaky simply because abstractions are difficult to design. The framework allows you to completely offload the architectural decisions underneath the framework to many person-years worth of design, bug squashing, and security fixes. How do I add headers to a request? Django has one opinionated way. Where do I put my database models? models.py and if you put them there you don't have to do any connection fiddling. The ideal of a framework is that if you release attachment to how things you don't actually care about anyway are done, you get thousands of free high quality lines of code. I learned a lot from Sandi Metz about the costs of "The Wrong Abstraction" https://www.youtube.com/watch?v=8bZh5LMaSmE |