A response to Dropping Django | Hacker News Reader

A response to Dropping Django

uswaretech.com

86 pointszumda17 comments

The admin not allowing email addresses as usernames still irks me, such a seemingly pointless restriction in this day and age.

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.

'There are a few other questions raised, some of which I agree with(”Sadly, it[the admin app] struggles a little bit with nullable fields and is tricky to customize.”), and some which I dont, (”I will never write CSS by hand again.” - You shouldn’t be, someone else on your team should be doing that.)'

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.

If you want to use full blown python in a template - use a template tag.

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.

> logic in the presentation layer

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

"Yes, I know you can create your own tags..."

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.

The whole point is that I don't need to be protected from myself. I understand the benefits of an MVC architecture, so I don't need to be limited by the templating language. Just because I want to use python in my template doesn't mean I'm going to start throwing database accesses in there...

The implication that designers are not "big boys" is offensive. I will parry with: "big boys" often wield power they don't understand to theirs and everyone else's detriment. More importantly, if all the big boys get hit by a machismo bus who will be around to cook the spaghetti?

I think the parent's use of "big boy" was ironic; if someone is patronizing me, I might say "Listen, I'm a big boy, I can handle it." I don't see it as, necessarily, saying I'm in a class above others. Just that I can handle the responsibility someone else thinks I can't.

Yeah, I wasn't trying to suggest that I'm above designers or anything. In fact, I really respect good designers, because I'm not a great designer and I know how hard it is. However, the article is basically saying "Look, you shouldn't even be writing CSS, you're a coder! Coders code! You should hire someone else to do that!" This just seems a bit naive to me.

That's always confused me about template languages. They require knowledge of coding but don't include the full power of a traditional language. In a way it's the worst of both worlds. If you're designer is a only a Frontpage or Dreamweaver jocky, you're still hosed. If they grasp coding, why limit them?

The point isn't to limit the designer, but to constrain complexity creep.

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.

> Additionally, a good template language does not require knowledge of coding

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?

All the designers I worked with also knew a programming language (at a superficial level at least) and where quite capable of coding complex logic in Javascript (which is also part of the presentation layer). Our fear is that designers don't understand a more complex language, but how many of you worked with such people? (since web-design is all about the end-product, I can't imagine a good designer that can't handle logic). And even if the language guards against shooting yourself in the foot you can always find creative ways to fuck up.

Good designers seem to think that it is perfectly reasonable:

http://twitter.com/nathanborror/status/3416472007

I thought this was meant to disagree with my statement. This status message doesn't say Programmers = Big Boys, Designers = (What would you call it? little boys, girls, hobos?).

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 think the point you're missing is that no one was calling convention a "softball for the less manly application developer."

(I wrote the original Dropping Django post)

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.

I'm not a python or django developer, so I can't comment on the technical merits of what either of you are saying. However, this exchange has left me with a lot of respect for both of you. It's been very polite and professional, and hasn't fallen into the usual vitriol and holy wars.

Reply on news.ycombinator.com