Dropping Django
blog.brandonbloom.name
blog.brandonbloom.name
* start by using it as it is intended. Save lots of time by being up and running quickly.
* find a flaw.
* realize that the workaround is more work than rewriting a piece of the framework.
* stop using that part of the framework, but continue to use the rest of the code that you still haven't had to write.
I think a lot of us have come to the same conclusion as this author: the abstractions frameworks provide are often too high level. Very quickly the needs of your project cannot be served by their generalizations. Especially in a language like Python, it's often easier just to roll your own systems.
However, starting off with a framework is a great way to get off the ground quickly. If you were to write everything from scratch from the beginning, you might burn out before you even produce anything usable.
Personally, I think CherryPy is the way to go. You're probably not going to need to rewrite HTTP [1], so that's an abstraction layer with which I'm comfortable. Everything else will need to be easily customizable for your project.
[1] Unless the threaded model doesn't work for you, like it doesn't for our chat backend.
No, but it might be an argument to consider frameworks that make it easier to replace parts as they become more trouble than they are worth.
Here are my solutions for anyone interested:
* URL Routing: They mention only breadcrumbs functionality here. I created breadcrumbs by template inheritance instead. There are url routers split by application and by modules. Template inheritance tree resembles the url routing levels, so that each template has: "{% block breadcrumbs %}{{ block.super }} · current-level-text{% endblock %}" Simple, but works so far :)
* Authorization: My views are decorated with @require_auth() if they require authorisation, @require_auth('group name') if they require special privileges and @require_auth(redir_to='...') if user should be redirected to a special place after authorisation. (by default they come back to the same place) Simple and works.
* Authentication: I simply didn't use the standard user classes. I used my own model. I don't consider it dropping Django - it's more like not using standard helpers.
* Templating: So far I'm happy with the whole logic in the view. Not sure how complex their application is... I'd really like to see some samples that required programming in the template...
* ORM and Admin UI: Can't comment on this one. I'm writing for google app engine and simply using their object store. It feels more comfortable than RDB so far. But sometimes I use GQL if it's faster.
* Form Validation and Generation: I've created a couple of dynamic forms extended with dynamic fields by jquery, as well as some forms with fields and validation generated on the fly (from user input, or saved data)... I can't find anything that's not possible with django forms. Sometimes I customise forms as needed, sometimes the autogenerated ones are almost perfect. Again - not using helpers all the time is not "dropping django".
I'm a bit disappointed that they didn't provide more examples and their solutions... maybe we could learn something from that.
I'll admit I felt the same way at first, but I was honest with myself enough to stop toiling with django and set aside the time to learn how to program in python. Once I started pin-pointing the obvious advantages of writing application-level programs in python I started to grasp the underlying advantages of django's design and philosophy.
Also, it seems like a lot of the complaints are about contributed apps like authentication and the admin. It seems to me that he never really tried to learn the admin, or was using a very old version. And you don't have to use authentication at all, you can completely write your own, or fork the one that comes with it and make it work for you.
But the main thing that bugs me is that he obviously doesn't get opensource either. If you think you have a better way, get on the mailing list and suggest it, create a ticket, or implement your changes and submit a patch. Writing your own stuff, not releasing it, and complaining on a blog doesn't help anyone.
I haven't got time to actively participate in Django's development. Especially because I'm not particularly interested in the details discussed on the mailing list and I've already found components I'd prefer to work with (and, by extension, contribute to). I've got a product to build. I took some time to write down my thoughts and the key contributors are welcome to read my rant, ask questions, and learn from it.
There's no reason to contribute it back to the community, because it's specifically targeted to his needs (and therefore wouldn't be considered better by anybody outside his team). Spending even an hour polishing it up for somebody else's consumption would be a distraction.
That said, at least he documented things and presented his issues cogently so that the dev team can see where issues are, and possibly address them in the future.
The thing we use at Expat is incredibly fast and turns out really good code. It's the reason we can move so fast, and it's a competitive advantage. But I wouldn't release it to the world.
It just has too many optimizations for the way we like to do things. And there's still the matter of the order-of-magnitude gap in level of effort between something you use in house and something you can release as a product.
Right now, this guy has something stripped down to the bare essentials to do what his shop does. Ideally, he's shed all the useless garbage that naturally accumulates in any commercial framework the size of django. And as a result, the final product probably isn't of any use to anybody outside his team.
Web frameworks do their best to provide useful, general abstractions for writing web applications. Sometimes you need different behavior on a lower level to which the framework provides no interface. In other words, your particular application breaks the general mold in some way. It doesn't necessarily make sense to change the framework for each of these application-specific needs. Writing those portions yourself and not contributing them to the project seems like a sensible way to go.
If the framework is really trying to work for the entire universe of web applications, it will quickly become too bloated to be useful for getting simple, common apps off the ground. As a framework maintainer, you have to strike a balance between the set of applications that your framework can accommodate and the usability of the framework.
That said, the author's tone does seem to suggest that Django is doing a poor job as a web framework because it doesn't fit his needs. That's an unfair criticism. Django fits a lot of people's needs. It's not supposed to be all things to all people.
1. The default backend stores information through the User class, persisted to the auth_user table.
2. All backends are required to return instances of User when asked to find the user who matches a given set of credentials.
So in the first case, we use the User class as a persistent object store. In the second case we use it as a consistent API implemented by records coming out of auth backends.
Where the confusion comes in is people assuming that, since you have to return an instance of User out of your custom backend, you must also have to persist that instance to the auth_user table. Which isn't correct; you're free to just chuck information into an instance on the fly, and Django will neither know nor care (third-party code may make bad assumptions about being able to save that object, but third-party code should be introspecting to find out where the object came from before trying that).
Any rate, this is on my list of things to document more completely, and hopefully that'll help.
What did I say which indicates a lack of experience?
I didn't feel this way in the beginning. At first, I quite liked Django. It was a huge time saver. I don't even really dislike Django now, our project has simply out grown it.
Why am I obliged to engage the community when things are painful? I took an easier route: I choose less painful components.
Edit: I guess the article could be considered feedback :)
I've worked with four design firms now, three of them excellent, and none of them could have been expected to understand templating code. If you're asking your designers to work with a template language, you're doing it wrong.
This has nothing to do with whether you put logic in your templates or not. The designer's deliverable isn't a working site; it's HTML/CSS/PNGs, and it's a dev's job to pull that into the framework.
I think it's fair for him to say he wouldn't ever hire a designer like that but I think it's because he's only built sites where it makes sense to optimize for that.
It was architected from the beginning to be friendly to non-programmers -- the idea was that someone writing an article for the Lawrence Journal-World (or a designer) could easily use custom templating in a constrained templating language that developers can augment with custom tags and filters.
It surprisingly works incredibly well for that use case. The templating language strictly enforces view-separation -- the template author can't do anything the developer didn't intentionally let them do.
It can be ridiculously frustrating if you're expecting it to be a normal language -- for instance __getitem__, __getattr__, and __call__ all use the same "obj.property: arg" syntax. It calls hasattr at every call site to figure this out, and you can't use () or [] even if you wanted to. Fuck, you can't pass multiple arguments to a function!
However, zero logic is even less than Django templates. If it is the devs jobs to retrofit the HTML/CSS/PNGs with templating logic, it is an even bigger argument for choosing a developer friendly template language instead of a designer friendly one.
* the designer doesn't go anywhere near the real app and does all their work as mockups of HTML / CSS or even Illustrator / Photoshop. Developers do the work to integrate templates, designers at most fiddle with the CSS or bare HTML in the template and never touch any logic.
* the designer is reasonably competent to deal with the primitive programming in templates and is involved in the full lifecycle of product development
The bottom line is that if they are too leary of programming to cope with simple logic structures in a template then they are altogether incapable of working productively as part of the development lifecycle and should just hand their stuff to people who have those skills.
EDIT: Apparently I was mistaken, as the replies point out. I read the Django book, but I do not recall this chapter. My apologies.
search_fields = ('title',)
"Finally, the search_fields option creates a field that allows text searches. It allows searches by the title field (so you could type Django to show all books with “Django” in the title)."
Why read the documentation or look for examples when you can write a blog post screed and post it on HN?
For example:
- includes a test framework, but tests on a fresh project don't pass
- no relative paths in settings.py make it hard to work with other people (sure, since settings.py is python code you can write code to get around it, but I don't like that approach)
- you can't extend the User class (except by using deprecated code); the workaround is to create a one-to-one table but that's ugly.
- templates have their own control structures rather than using the ones pythonists already know (django's ifequals vs. python's if, for example)
If you're fed up with django, try Pylons. It is very loosely coupled, to the point where the recommended ORM and template system are separate projects (SQLAlchemy and Mako).
What next? Will web development come full circle to using raw SQL queries like Phil Greenspun suggested years ago? (Not that there is anything wrong with it)
result = db.select('table', what='id, name',
where='id>3', order='id', limit=5)
I used to be against ORMs ("Another layer? How inefficient"), but now I see them like compilers: They're easier to work with and, most of the time, SQLAlchemy does the job better than me (lazy-loading, etc.).
At the start of the project, when queries are few and datasets are small, all of the above worked great. But the further you get into the project, and the more complex things you are trying to do with larger and larger datasets, the ORM ends up blowing up in your face. For example, LINQ to SQL--which I want to emphasize I'm picking on only because I'm using it righ tnow--happens to silently and transparently convert from IQueryable (meaning that your LINQ will execute in the DB) to IEnumerable (which means you'll suck in all data required for filtering past that point), which means that you never have a good idea whether your query is going to be optimized or not unless you check the SQL being generated. When you have to do this a few dozen times, you start wishing you'd just written SQL in the first case.
The situation gets worse when you start getting into join-heavy queries. I've never seen an ORM that actually can cover everything you need to make an app performant. It doesn't handle full joins, or compound indices, or distinguishing between clustered and nonclustered indices, or calculated columns, or some other thing that, if you were in raw SQL, would easily solve your problem, so at that point, you start introducing raw SQL. The older your app gets, the more instances of this you get, until you'd have been better off simply using SQL the entire time anyway.
I love the idea of an ORM in theory, but I'm pretty solidly convinced these days that if you want objects, you should us an OODBMS, and otherwise, you should just embrace the relational model for what it is, and not pretend you're working with objects. For most people, that'll mean writing SQL and getting back query sets.
Linq to Objects, however, is freaking amazing. C#'s functional and querying features are like Python's generator expressions on crack, speed, steroids, and acid. Absolutely love them.
LINQ is great. LINQ to SQL is actually very good, so far as that goes; it just happens to be trying to do something that I'm not convinced can be done well.
Schema synchronization is just a major headache, no matter from which end you approach it (declarative -> evolution or Raw DDL -> reflection).
Once your number of databases exceeds 1 you are in trouble either way.
The implicit assumption that a schema definition would ideally be set in stone once and then never changed is a legacy carried over from the very early RDBMS days. And it's one of the biggest albatrosses to date.
But it does support a lot of stuff out of the box, so it's still my favorite python web framework, and I have probably set up about a dozen different Django projects.
http://docs.djangoproject.com/en/dev/misc/design-philosophie...
"The Django template system recognizes that templates are most often written by designers, not programmers, and therefore should not assume Python knowledge."
In my experience this has often been the case.
Another problem is unicode. Current Django assumes you will deal with all strings as valid unicode, which is actually different from pre-1.0 Django. There is no way to store an arbitrary sequence of bytes without a unicode encoding. This makes perfect sense for a newspaper website, but is problematic for many other applications.
Another problem is imports in general. Django does a lot of work in __init__.py files which causes problems integrating it with other systems that do a lot of things at run time.
I copied the chained actions model from Catalyst, and the routing is automatically generated. I also have template tags defined that construct these URLs for me (not uploaded in the repository).
I structure my views in a structure like ...
views/root.py
views/articles.py
views/users.py
views.root.begin -> views.articles.begin -> views.articles.item -> views.articles.show
What I find cool about Django is that the dispatching is really simple to understand, and it can be extended (and components aren't hard to replace in general).
I write off and hack around problems almost daily.
Also views can be served by callable classes, so an init function can populate the context (or a chain of them with class inheritance) and then the appropriate code can be run to serve the view.
Some of our apps have deeply nested paths (typically a no-no, but actually quite appropriate for our problem domain), so it is impractical to create a module and call "include" for each tree node.
As for callable classes: someone has to instantiate them. That's no different than our custom routing and authentication. I just choose function composition over class inheritence.
Our site: http://www.classlet.com
Announced here: http://news.ycombinator.com/item?id=679000
There is a new version on the way with a huge host of new features and some significant cleanup. The version that is live now is more of a proof of concept.