Decent response to the original article, though I have to admit that I have a pet peeve about developers declaring libraries/frameworks "insufficient", "lacking" or "fundamentally flawed" as an excuse to write things themselves. Or maybe I'm just grumpy.
Ugh, this is just a totally unrealistic and out-of-touch argument. Look, I work on a website, and it's me and one other guy, and we both have to write frontend and backend code. It's not even remotely reasonable for us to just stop writing frontend stuff and tell our boss to hire someone else to do it. I fully understand why the Django templating language is the way it is, and it even makes sense, but it's not perfect for all situations, one of which is when the user is a big boy and can handle the responsibility of using full-blown python in a template.
What scenario do you require python in a template? I am a big boy, and the few times I have thought about needing python in a template I realized I need to do a bit more work in the view.
I think it is a great example of protecting 'big boys' from themselves. A year from now when you don't remember how you designed a section of your code you can trivially debug and test instead of trying to sort through logic in the presentation layer.
Also, it makes unit testing much easier having logic stop at the views.
Sometimes logic belongs in the presentation layer (if it is related to showing the information to the user).
Take the "if" tag for example. It doesn't support complex conditions (values can only be tested for values of truth, and it doesn't support parenthesis to define precedence) and adding an if block inside another if block is just ugly. To get around this, you usually construct a boolean value inside your view, but it often happens that this value is only relevant for one template (i.e. HTML). And if your view also returns JSON / YAML, that's not clean.
Also, QuerySets are lazy by default, and it goes beautifully hand in hand with caching template fragments, and this works for me since I usually can't cache whole pages (some fragments are more dynamic than others). But if you move template logic in your view, then you're going to have to worry about caching in your view too, duplicating logic.
Also, the if tag doesn't support "ifelse" ... what's up with that? Are designers too stupid to use ifelse properly?
Yes, I know you can create your own tags, but it would've been nice if these things worked out of the box, and it's not OK to define a tag that's not reusable (like in the case of a complex "if" condition that can't be expressed in the template directly), because that's extra work that doesn't pay off.
And since we are talking about designer-friendliness, how are designers going to understand working with such non-standard tags all over the place?
Now, thus far the Django templates haven't been much of a problem for me, but the projects I worked on in Django have been pretty simple. But I know they are not enough so I'm currently looking for alternatives (fortunately it is easy to replace).
Yeah, this is usually the response you get when you mention stuff like the missing ifelse, and it's totally ridiculous. Why should I go about reinventing this stuff? The whole reason I'm using a framework is to speed up development. You also risk everyone inventing it on their own in their own way, so now if you go try to work on someone else's project, maybe they've implemented it, maybe they haven't, and even if they have, it's probably not going to be the same way you implemented it, so now you're re-learning again for no added benefit.
Additionally, a good template language does not require knowledge of coding. I've had considerable success with providing front-end HTML writers with templates based on purely declarative custom HTML/XML tags.
Programmers write and document the tag libraries, HTML developers use them, and the HTML templates themselves are simple, easy to read, and generally declarative.
I don't think I ever saw an effective template language that doesn't require programming knowledge. The only exception is when you move all logic in tags, but even then logic gets mixed with presentation (just not in the main template), and the downside is that a tag is like a black-box ... if the scope is not clear, you have no way of knowing what it produces by not looking over its code (CSS files in ASP.NET end up containing general classes in most cases because of that).
That's because the presentation layer requires logic, for example ... if this happens, then show this, else show that. Or to show the breadcrumb, iterate through this list. Or is this DateTime value in UTC? Then show it in the user's locale. That's logic and it's a lot more then a template with holes in it to fill.
And where is this logic supposed to go if not in the presentation layer?
There is power in a template paradigm. Much like MVC is for people who "can't handle" hacking their entire program into a single executable, convention (guided suggestions or limitations) can do a lot for a group of developers even if they aren't collaborating with designers. If they don't recognize that, so be it (they will) but calling convention a softball for the less manly application developer is a crudely un-meditated suggestion.
I wrote a quick comment at http://uswaretech.com/blog/2009/08/a-response-to-dropping-dj...
Maybe I wasn't clear enough, or maybe this is just guaranteed flame war territory. But I think this comment sums up what I was trying to say better than anything: http://news.ycombinator.com/item?id=773510
I'm going to try to write more about our URL routing and authorization soon.