
Simplifying Django - japhyr
http://programming.oreilly.com/2014/04/simplifying-django.html
======
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.

------
Walkman
I never realized Django tutorial teach you more than how to use the framework;
You learn _best practices_ from the very moment you start reading it.

Also, every other framework seems like a mess now :D You get a sensible
structure with Django when you start a new project.

------
scrollaway
URGH.

[https://mediacru.sh/jgc9B7eS1dDl](https://mediacru.sh/jgc9B7eS1dDl)

DON'T do this. Some of us speed readers read with selection. Completely
shatters usability.

Instant hatred of the website. This is like reading a book where the pages are
slimey and smell bad.

~~~
crusso
Great reason to use NoScript or ScriptSafe, since it kills things like this. I
hadn't even noticed the problem.

~~~
scrollaway
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.

~~~
patmcguire
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.

------
japhyr
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.

~~~
csense
> 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.

~~~
collyw
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.

------
scorpioxy
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.

~~~
nkuttler
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.

~~~
zidar
"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.

~~~
nkuttler
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.

------
lordsheepy
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.

~~~
ryannevius
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.

------
Joeboy
Nine years after the initial Django release, somebody's finally written a good
Hello World tutorial for it. Good work.

------
goblin89
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.

------
d0m
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..

~~~
arms
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.

~~~
japhyr
Is Flask easier than Django for someone with no experience working directly
with databases?

I have worked with Django a bit, but I've never built anything in Flask. Does
Flask use an ORM, or do people need to write their own SQL?

~~~
arms
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 ;)

~~~
rtpg
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).

------
Myrmornis
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.

------
yeukhon
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](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.

------
jbeja
This is the tutorial that wouldn't got me scared the first time trying Django.

------
blazespin
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.

------
tbatterii
getting rid of regex based routing would make it even simpler.

------
mladenkovacevic
The author creates their own BASE_PATH but I think in Django 1.6 this is taken
care of by a built in BASE_DIR

------
tbarbugli
Django is not a lightweight framework

