<story><title>Django vs. Flask</title><url>https://www.git-pull.com/code_explorer/django-vs-flask.html</url></story><parent_chain><item><author>yen223</author><text>I&amp;#x27;m working with a large, 5 year old Django codebase. My humble opinion: Django itself is actively hindering our ability to deliver new features.&lt;p&gt;Some pain points:&lt;p&gt;- Django&amp;#x27;s fat models approach is bad. By coupling model behaviour to database schema, it all but guarantees that you&amp;#x27;re gonna have a tough time modifying either.&lt;p&gt;- Django&amp;#x27;s class-based views and its admin framework strongly encourages a sort of &amp;quot;one-view, one-model&amp;quot; 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.&lt;p&gt;- Not Django specific, but Python is a bad choice to use at scale. The lack of a good default immutable data structure means we&amp;#x27;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&amp;#x27;s HttpRequest, whose attributes may or may not be set by the middlewares.&lt;p&gt;There are more, but one thing&amp;#x27;s for sure, I probably won&amp;#x27;t be using Django for my next project.</text></item></parent_chain><comment><author>ibejoeb</author><text>I&amp;#x27;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.&lt;p&gt;* Create primary &amp;quot;fact&amp;quot; models for the things you are CRUDing.&lt;p&gt;* Process the data in the database. Write your complex operations in SQL, and expose them as views.&lt;p&gt;* Create corresponding Django models on top of the views. These are not as &amp;quot;fat&amp;quot; because they are unmanaged models that just facilitate getting processed data to the user.&lt;p&gt;If you&amp;#x27;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.</text></comment>
<story><title>Django vs. Flask</title><url>https://www.git-pull.com/code_explorer/django-vs-flask.html</url></story><parent_chain><item><author>yen223</author><text>I&amp;#x27;m working with a large, 5 year old Django codebase. My humble opinion: Django itself is actively hindering our ability to deliver new features.&lt;p&gt;Some pain points:&lt;p&gt;- Django&amp;#x27;s fat models approach is bad. By coupling model behaviour to database schema, it all but guarantees that you&amp;#x27;re gonna have a tough time modifying either.&lt;p&gt;- Django&amp;#x27;s class-based views and its admin framework strongly encourages a sort of &amp;quot;one-view, one-model&amp;quot; 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.&lt;p&gt;- Not Django specific, but Python is a bad choice to use at scale. The lack of a good default immutable data structure means we&amp;#x27;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&amp;#x27;s HttpRequest, whose attributes may or may not be set by the middlewares.&lt;p&gt;There are more, but one thing&amp;#x27;s for sure, I probably won&amp;#x27;t be using Django for my next project.</text></item></parent_chain><comment><author>wolf550e</author><text>It won&amp;#x27;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.</text></comment>