3 ms·

For context, http://groups.google.com/group/django-developers/browse_thread/thread/4f5b01719e497325/a60123ee5af0c566#a60123ee5af0c566 http://groups.google.com/g

by shabda 17y ago

For context, http://groups.google.com/group/django-developers/browse_thread/thread/4f5b01719e497325/a60123ee5af0c566#a60123ee5af0c566 http://groups.google.com/group/django-developers/browse_thre... My reasons for choosing Django templates over pretty much anything comparable. Everything else tries to make things easy for developers, Django templates makes things easy for designer.

snprbob86 17y ago
As a small team (read: 2 hackers), I have no desire to make things easier for the designers... because we have none. We're trying to get some work done and we can't really afford to hire anyone who can't wear every possible hat. Clearly, we aren't the target customers of Django templates, so we use Jinja2. Even if we had designers, I'm not sure they should be writing templates. I'd rather they be writing CSS and that the dev team be responsive to template change requests. If a designer needs a div or span or move some stuff around into a table, they should be able to handle basic template manipulation in any language... and those changes need to be code reviewed by a developer anyway. On a related note, I just wish there a more mature Haml implementation for Python. We use SASS and love it, but Haml is strongly tied to Ruby. GHRML doesn't seem to be well supported or maintained.
- blasdel 17y ago
  Django was written for a newspaper, where the most important external feature of the CMS was that users be able to mess with html templating without any input from the developers.
  - snprbob86 17y ago
    Django templates make sense in that context, but Jinja2 templates are 90% the same. You need to know one or two more rules about () and other metacharacters, but there isn't much cognitive dissonance in a switch-over. It is easier to call arbitrary code from Jinja2, which simplifies the life of programmers even when having to work with laymen editors. Django is no longer a newspaper-centric framework. Far more users of Django want a hacker-centric template language. Markdown and other markup languages are far closer to the needs that the Django template language once filled.
    - blasdel 17y ago
      I do prefer Jinja templates, and I plan to convert the Django-templated projects I have to them the next time I hack on them. I hate the parenthisis-avoiding dispatch mechanism that does a bunch of wasteful dynamic type-checks, all to make the syntax more obnoxiously clever. I hate the fact that it implements it's own shitty interpreter. It feels Ruby-ish in the most pejorative way. But Markdown doesn't fit the 'newspaper' usage model in anywhere near the same way -- Django templates let the writer do all kinds of layout fuckery in an idiot-proof, dev-supported, maintainable, extensible, {%benificent_adjective%} way.
      - snprbob86 17y ago
        But they aren't idiot proof. That's exactly the problem. If you can't trust the template writer to understand {{ foo.bar }} vs {{ foo.bar() }} how could you trust them to not do something with HTML, CSS, JS, or Django-templates which breaks the page? Either you trust your designers because you hire smart, multi-talented people. Or you want something simple, predictable, and completely impotent... you know... like a rich text editor...
- ubernostrum 17y ago
  Even if we had designers, I'm not sure they should be writing templates. I've never understood this attitude. Maybe it's just because I've worked for places which seek out talented people who know their stuff, but it feels way too much like unjustified territoriality on the part of developers.
  - snprbob86 17y ago
    If you got a talented person who knows their stuff, then they should be able to handle whatever template language you throw at them. Gimping the power and expressiveness of your template language happens for 2 stated reasons: 1) To make it designer friendly 2) To force you to put logic into back one layer If you have talented folks, #1 shouldn't be a concern. Any technical artist should be able to learn enough of any template language to be trusted to not break things. Just as one coder has to code review the work of another, someone should code review the designer's work. Maybe that's a developer, maybe it's a senior technical artist; it doesn't matter. Choosing the right tool for the right people puts a lot of trust in the fact that you choose the right people! #2 is idealistic bullshit. There is HTML-specific view logic. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. But imagine the case were you have an "Export to CSV" button. That is simply two different templates over the exact same data. The HTML version might need to do some smarts about grouping or human-readable adjustments. There will surely be some javascript that depends on particular elements and structure. Forcing all of that logic into template tags is just silly.
    - ubernostrum 17y ago
      If you have talented folks, #1 shouldn't be a concern. On the contrary; we don't expect programmers to master design and become Photoshop gurus, for example, so why should we expect designers to master what is, essentially, programming? There's a lot to be said for having different groups of people whose strengths are in particular domains. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. Actually, this only works in the most trivial (and thus non-real-world) of situations. Usually, API access needs to be mediated through additional logic (authentication, access control, rate limiting, etc.). Forcing all of that logic into template tags is just silly. I have to admit that I don't really know what you're getting at here. If you do have a case that's as simple as "use another template", well, you use another template. If you don't, no amount of program logic in templates is going to save you. Anyway, here's how I see it: 1. Django's template language is designed to permit enough logic to handle presentation, and to be easily extensible for cases where you need something more. 2. Jinja is designed to permit quite a lot of free-form programming constructs, and is not particularly easy to extend when you run up against a wall. These are fundamentally different approaches to "templating", and what I've found is that people who prefer, say, Jinja tend to just use it and move on. The people who stick around to argue are the ones who think that some particular tag or extra bit of logic should be made available by default in Django, and so are arguing about differences of degree rather than differences of kind.

by shabda 17y ago

snprbob86 17y ago

As a small team (read: 2 hackers), I have no desire to make things easier for the designers... because we have none. We're trying to get some work done and we can't really afford to hire anyone who can't wear every possible hat. Clearly, we aren't the target customers of Django templates, so we use Jinja2. Even if we had designers, I'm not sure they should be writing templates. I'd rather they be writing CSS and that the dev team be responsive to template change requests. If a designer needs a div or span or move some stuff around into a table, they should be able to handle basic template manipulation in any language... and those changes need to be code reviewed by a developer anyway. On a related note, I just wish there a more mature Haml implementation for Python. We use SASS and love it, but Haml is strongly tied to Ruby. GHRML doesn't seem to be well supported or maintained.

blasdel 17y ago
Django was written for a newspaper, where the most important external feature of the CMS was that users be able to mess with html templating without any input from the developers.
- snprbob86 17y ago
  Django templates make sense in that context, but Jinja2 templates are 90% the same. You need to know one or two more rules about () and other metacharacters, but there isn't much cognitive dissonance in a switch-over. It is easier to call arbitrary code from Jinja2, which simplifies the life of programmers even when having to work with laymen editors. Django is no longer a newspaper-centric framework. Far more users of Django want a hacker-centric template language. Markdown and other markup languages are far closer to the needs that the Django template language once filled.
  - blasdel 17y ago
    I do prefer Jinja templates, and I plan to convert the Django-templated projects I have to them the next time I hack on them. I hate the parenthisis-avoiding dispatch mechanism that does a bunch of wasteful dynamic type-checks, all to make the syntax more obnoxiously clever. I hate the fact that it implements it's own shitty interpreter. It feels Ruby-ish in the most pejorative way. But Markdown doesn't fit the 'newspaper' usage model in anywhere near the same way -- Django templates let the writer do all kinds of layout fuckery in an idiot-proof, dev-supported, maintainable, extensible, {%benificent_adjective%} way.
    - snprbob86 17y ago
      But they aren't idiot proof. That's exactly the problem. If you can't trust the template writer to understand {{ foo.bar }} vs {{ foo.bar() }} how could you trust them to not do something with HTML, CSS, JS, or Django-templates which breaks the page? Either you trust your designers because you hire smart, multi-talented people. Or you want something simple, predictable, and completely impotent... you know... like a rich text editor...
ubernostrum 17y ago
Even if we had designers, I'm not sure they should be writing templates. I've never understood this attitude. Maybe it's just because I've worked for places which seek out talented people who know their stuff, but it feels way too much like unjustified territoriality on the part of developers.
- snprbob86 17y ago
  If you got a talented person who knows their stuff, then they should be able to handle whatever template language you throw at them. Gimping the power and expressiveness of your template language happens for 2 stated reasons: 1) To make it designer friendly 2) To force you to put logic into back one layer If you have talented folks, #1 shouldn't be a concern. Any technical artist should be able to learn enough of any template language to be trusted to not break things. Just as one coder has to code review the work of another, someone should code review the designer's work. Maybe that's a developer, maybe it's a senior technical artist; it doesn't matter. Choosing the right tool for the right people puts a lot of trust in the fact that you choose the right people! #2 is idealistic bullshit. There is HTML-specific view logic. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. But imagine the case were you have an "Export to CSV" button. That is simply two different templates over the exact same data. The HTML version might need to do some smarts about grouping or human-readable adjustments. There will surely be some javascript that depends on particular elements and structure. Forcing all of that logic into template tags is just silly.
  - ubernostrum 17y ago
    If you have talented folks, #1 shouldn't be a concern. On the contrary; we don't expect programmers to master design and become Photoshop gurus, for example, so why should we expect designers to master what is, essentially, programming? There's a lot to be said for having different groups of people whose strengths are in particular domains. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. Actually, this only works in the most trivial (and thus non-real-world) of situations. Usually, API access needs to be mediated through additional logic (authentication, access control, rate limiting, etc.). Forcing all of that logic into template tags is just silly. I have to admit that I don't really know what you're getting at here. If you do have a case that's as simple as "use another template", well, you use another template. If you don't, no amount of program logic in templates is going to save you. Anyway, here's how I see it: 1. Django's template language is designed to permit enough logic to handle presentation, and to be easily extensible for cases where you need something more. 2. Jinja is designed to permit quite a lot of free-form programming constructs, and is not particularly easy to extend when you run up against a wall. These are fundamentally different approaches to "templating", and what I've found is that people who prefer, say, Jinja tend to just use it and move on. The people who stick around to argue are the ones who think that some particular tag or extra bit of logic should be made available by default in Django, and so are arguing about differences of degree rather than differences of kind.