Saturday, November 2, 2013

The perfect web development framework

I've been trying out Django as a platform for resurrecting my website.  The crazy thing about websites is that they are almost all extremely similar, and yet each one seems like a huge endeavor to build.  Of course, some of this is self-inflicted because, in my own case, I'd rather rebuild a website from scratch in order to learn (and, to a tiny extent, enjoy) the latest development methods.  But mostly I think that we haven't solved the problem of how to reuse medium-level stuff.

If you want to "reuse" blog software, you can use Blogger or dozens of other systems, but then you can only do exactly what they have built.  Which can be pretty configurable, but there are still limits.  That's big reuse.  

If you want to reuse bits and pieces, like spellcheckers or mathematical functions, that's small reuse, and that works pretty well.

But in the middle, it's a mess.

I made it through the first Django tutorial and I'm not totally happy.  I wanted to get a simple web-driven application working, just a "Hello World" kind of thing.  A list of dogs: name, breed, gender, neutered true/false?.  Breed coming from a list in a separate table.  So the whole thing is two database tables and a relationship.  In the ideal web development platform, you define your data and then, pow, you get automatically and with no code or anything, all of the typical stuff that you are likely to need:
  • web pages to look at a list of each thing you defined
  • sorting
  • filtering
  • pagination
  • pages and forms to look at individual items
  • pages and forms to add new items
  • pages and forms to modify existing items
  • pages and forms to delete items
And Django provides all of this, with just a tiny bit of glue code.  But it's stashed away in the "Admin" interface, which is not supposed to be available to the public.  If you want to expose this data to the public, you are expected to completely rebuild all of that lovely functionality from scratch with lots and lots of repetitive code.

At least, that's what the tutorial wants you to think.  Until you get to part 4, which introduces "generic views" that eliminate half of the mess.  It says:

Generally, when writing a Django app, you’ll evaluate whether generic views are a good fit for your problem, and you’ll use them from the beginning, rather than refactoring your code halfway through. But this tutorial intentionally has focused on writing the views “the hard way” until now, to focus on core concepts.
 You should know basic math before you start using a calculator.
Screw you, tutorial writer.  You should have offered that as a choice on the first page of the tutorial.  Now I know never to trust you.

So, impressions after maybe 4-8 hours of Django hacking:

  • There's no standard way to do anything.  The tutorial alone provides two or three or four different ways to do things, and searching for help and examples produces lots of code that looks slightly similar but not really.
  • Django really wants you to think you are writing a Python program that looks like a website, not developing a web site that has bits of Python in it.
  • The request processing flow is on the complicated side.  To get one page to work, you need to put code in four or five or six different places:
    • urls.py
    • models.py
    • views.py
    • forms.py
    • a template page, which if your application is "dogs" is mysteriously in dogs/templates/dogs/yourpage.html
    • probably something else I've forgotten
I think I'll try a bit more coding, and then try out the big selling point, which is a huge library of prebuilt tools (reuse in the medium), and see how well that works.  After using Django for a bit, I'm further from committing to a platform than I was before.

No comments :

Post a Comment