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.
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.
> 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.
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.
i've been a highlight-reader for as long as I can remember. It irks me when there's a widget that does this, or if the text is in an image. It gives me nothing to 'hold on' to!!
NoScript is overkill but I wish there was a way to disable certain API entirely without disabling javascript as a whole. In this case I'd really like to disable window.getSelection() and document.selection, as usually sites using those are either up to no good or .. as awful as the original link.
You can, just have a plugin that redefines the function to do nothing. I've only seen it on scripts that try to punish hotlinking by doing things like making console.log do nothing or redefining false to true, as it's obviously an example of worst practices.
I can see both sides of the conversation here. If you have built web applications in other languages, and using other frameworks, the existing Django tutorial is perfectly fine. You know there are many pieces that need to work together to make a meaningful web application, you have a sense of what those pieces should be, and you can make sense of each piece as you read about it.
For someone new to programming, and new to developing web apps, the tutorial can be intimidating because you read about a bunch of parts that don't show anything through the browser for a while. This approach is different; it puts everything in one file so the student can see something in the browser right away, and then builds complexity on top of that. If done well, this is a really good approach. I expect that, in the more complete development of this approach, the student ends up with a project similar to what we see in the official tutorial. Taking a simplified, single-file approach and then pulling out the pieces as you add complexity is a perfectly reasonable pedagogical approach. I think this approach can even work for people coming at Django with experience in other languages and frameworks. The authors are not pretending that Django is simpler than it is; they are just presenting it in a simplified way initially, with the full intention of getting into all the necessary parts to build a complete application.
I think we also need to remember that when we write tutorials and books about Django, we are really preparing our readers and students to dig into the overall Django documentation for themselves. That documentation is thorough, and if readers leave this book with an ability to make sense of the official documentation, the authors have done their job.
> For someone new to programming, and new to developing web apps
Such a person is going to have a hard time regardless. I think it's much better to become proficient in a single (Turing-complete) language first.
The Web is a total mess -- a typical web application requires you to know, at a minimum, HTML, CSS, JS, your server-side language of choice, regular expressions, and SQL.
I agree. Let them use PHP if they just want to get something up and running - that's what it was designed for.
Django on the other hand is for more experienced web developers that want to do things correctly. And it adds another layer of complexity on to the list of technologies you mentioned.
While I agree that the sample application is something that needs to be considered from time to time, I don't agree that we need to make it look as simple as the ones offered by micro-frameworks.
For one, Django isn't a micro-framework and using it as such, although possible, is probably overkill.
Anybody who has ever seen an MVC pattern or read about it will understand why it needs 6 parts and won't necessarily be intimidated by it. I know I wasn't when I first looked at it.
On-boarding new users needs to be simple and welcoming, nobody disputes that. But this trend in dumbing down everything should not extend to web frameworks in my humble opinion.
Demonstrating what a minimal example of a django project looks like isn't dumbing down. I would argue the opposite; running startproject and accepting whatever it spews out is the mindset of a dumbed-down programmer.
Any programmer should be able to write down a minimal example of whatever they're working on, but personally I had never thought through how to make a minimal django app -- had you?
I particularly disliked the "it isn’t until part three that you finally write your first public facing view" part. Giving views such a high priority is just wrong. The first part of the tutorial covers the dev server, db setup, models and queries. Data models and queries are really at the core of (almost) any Django project, in a normal app most views will just execute queries and send the data to the browser.
I think the Django tutorial is an excellent piece of documentation. If somebody doesn't have enough patience to work through it, they probably won't have the time to read the rest of the docs either and will most likely end up writing messy code.
"Giving views such a high priority is just wrong." No, it's not! If I'm trynig to teach someone with wery little programming experience, he'll want to see results. Starting out with something he'll see is what helps to keep him engaged.
There is a reason most tutorials start with: this is how you show something, and if you want to sawe data here's how to make ane use a database. Sure doing it the other way around seems natural to you and other web developers, but it's a bad way to introduce a framework to a complete newbie.
The problem I see with your approach is that you have a rather narrow definition of "seeing results". If you want them to see something in the browser immediately, start by teaching basic HTML. You don't need Django for that. QuerySets that are easy to generate are a great result for somebody who has HTML experience and wants to build a data driven website.
Making the first step simple will just make it even more frustrating later when they don't understand concepts like objects, modules, packages, inheritance, DRY, separation of concerns, best practices, yadda.
I think when it comes to django, too many people go in a start using it without understanding anything that's going on inside. Django's magic often encourages ignorance till debugging forces you to figure out what is going on. This approach could really help mitigate that effect.
I'm guilty of doing what you describe. It wasn't until I moved away from Django for a bit, built a Flask app, and came back to Django that I finally understood what was going on. The approach that the article describes really reminded me of creating a Flask app. I would have learned Django MUCH faster with such an approach.
I'd say in Django documentation there might be a place for such simplified project scaffolding that fits into one file and few lines. Not as dumbing down, but as explaining a complicated thing in a simple manner and from another angle.
Replacing current project template, though, doesn't make sense IMO (and OP isn't suggesting that anyway). Default project should be suitable for the majority of use cases, and the current one seems to deal with that role well. Giving such a simplified template to a person without much discipline with regards to code organization would probably result in poorly maintainable pile down the line.
Fully agree. I wanted to recommend Django for a friend to get started in web development but it's such a hassle to get started, I'd rather have him start with flask or even PHP..
I would much sooner introduce someone to Flask than I would to PHP and Laravel (which is, IMO, the best current PHP framework.) Flask has an easier learning curve than Django, and is able to handle small to large applications. Plus, Python is simply a better language than PHP.
This is coming from someone who writes a lot of PHP.
It's common to use SQLAlchemy with Flask, so the answer depends on how comfortable you are with that ORM.
That being said, you should absolutely at least learn the basics of working directly with databases. ORMs are a leaky abstraction, and you will run into situations where it's easier to drop into raw SQL to get the job done. Think of it like this: using GPS while driving is fine 95% of the time, but when it malfunctions or breaks, you're screwed unless you know how to read a map or ask for directions ;)
SQL are a leaky abstraction too, and ORMs get rid of an extremely high amount of common beginner errors.
Using raw SQL instead of an ORM is one of the best examples of premature optimization I can think of (unless you are very very good at SQL and have a very complicated structure).
Django's ORM is great for simple SQL. Anything moderately complex is going to require you to understand SQL, plus other features of the ORM (extra / raw queries).
This is great. Both for beginners to learn, and it looks useful also for bootstrapping toy projects, and creating integration test suites for non-standalone django libraries.
I've used Django before version 1.0 That's 3-4 years ago. The tutorial is pretty good, though I took my time to understand every bit of piece. At the time the best book anyone could get was The Django Book (http://www.djangobook.com/en/2.0/index.html), which unfortunately has ceased development.
I don't use Django these days but the hard part I remember was using signal. Getting deep into the core to fit needs is hard of any framework.
There are many tutorials just covering the basics of the framework. Then the author stops because eventually the complex stuff like handling long computation, message queue, openid/oauth/ldap integration, load balancer are very project dependent. While that's true, and every tool's author must have some "tutorial" on how to use his or her tool, but this independence (or shall I say decentralized) can be a burden on beginner.
I am very much like to think we should have a book that can cover more tool integration.
The problem with the default django tutorial is that it gives you the impression that you need all those pieces in place for it to work. This seems like and gives the impression of an inflexible architecture. Django doesn't need a specific set of components to be useful and tutorials which shows off that side would be useful.
For example, someone might want to use django with cassandra. The current default tutorial would discourage a user from doing that as it gives the impression that a SQL backend is required.
Simpler, more decoupled tutorials might also attract a user base who have more modern ideas on how to use django in different environments. We certainly need those innovators to push things forward .. look at what they have done for javascript over time.
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.