[tsurantino]

I feel like this is an over-simplification. Like others have mentioned, despite the initial hurdles, going through the process of configuring that Django project initially forces you to wrap your head around a standard architecture that is essential in creating your web app. You have a greater understanding of a typical web app's components, making it easier to debug and understand the source of potential problems.

The problem is not one of dealing with bloat, but balancing a potentially intimidating setup process with the need for showing results to new programmers or programmers moving between frameworks.

If you want to emphasize results, then you should first develop a TemplateView and then work your way from there to discuss Forms and finally Models/ModelForms. Things like configuring your settings, URLs and views should stay as they are, as bringing them all together into one file encourages a disorganized mess in the future.

[lelandbatey]

I'm a long time believer that first you must do terrible things, then you can understand how much better it is to use a framework.

In my case, I made a bunch of Flask apps, and while quick easy and fun, in my inexperience things quickly descended into a disorganized mess. Now that I've struggled with that, I understand the purpose of the structure of frameworks like Django or RoR. I have more perspective because I didn't jump in to the high level straight away.

Now, that's not to say this is the only way to learn, or the right way to learn. I just think it was a nice thing to learn, and tangentially related to the topic at hand.

[rbanffy]

> I'm a long time believer that first you must do terrible things, then you can understand how much better it is to use a framework.

There was a moment many friends of mine started building their apps on Flask. They loved the freedom it afforded them.

Every app of this series has grown into something that user more or less the full Django feature set. All of those friends of mine ended um having to build their own Django, piece by piece.

There is a valuable lesson here: chances are your app will grow to need a full framework. Unless you can build a better framework, you should stick to one that covers the most common use cases.

[rdn]

It goes both ways. While Django's structure and submodules are very good, at times this can get in the way. Flask is more of a ground-up approach; you lose some of the benefits of tight integration but gain flexibility. But, without seeing ways to organize things well in the first place, I could see a newcomer to Flask having trouble assembling the pieces they need appropriately.