You're Doing It Wrong

Sweet, sweet irony. It's not every day that you see a post titled "You're Doing It Wrong" that's, well, doing it wrong.

I've worked on plenty of sites of varying complexity. If your templates have anything more than trivial logic in them, You're Doing It Wrong!

Adding complex programming constructs back into the templating language is NOT the way forward. It's the way BACKWARDS. It's where we came from. Templating languages are intentionally simple because you're NOT supposed to have lots of complex logic in your template. Sure, you might have a little bit of if/then/else and a bit of looping, but beyond that, if you need anything more than that, you're doing it Very Wrong.

As for ending up with huge templates - again, Jeff is Doing It Wrong. To avoid having monster spaghetti templates, you're supposed to break down your templates into their elements, much like you break down your large pieces of functionality into classes and methods.

It's amusing to watch server programmers come up with a thousand different ways to abstract away HTML. If you've ever worked with a good interaction designer, the best thing you can do is let them write views in something as close to HTML as possible. Every attempt to auto-generate sections of the view is something that will need to be worked around at some point. A lot of these frameworks seem to come from the mentality that design is just a programming problem that can be solved by pushing code out from the backend. A lightweight templating language (smarty, velocity, etc etc) should be all you really need. Poking holes in the HTML and inserting data is precisely the right way to do it.

> Templating tends to break down because it forces you to treat code and markup as two different and fundamentally incompatible things.

Well of course code and markup are two different things, but incompatible? Not really.

We use HTML templates simply to let the designers play with the templates without our interference. It also makes changes easier to integrate. Otherwise we could use a DSL and transform the syntax tree in valid xhtml (which many people are already doing).

> Rather than poking holes in HTML to insert code, we should simply treat HTML as code.

Actually that means poking holes in your code to insert HTML. And it's worse IMO.

While I like some of the articles Jeff has published on his blog, but I've long since deleted the blog's feed from my list because the signal to noise ration is really awful.

I liked this post, and I think it speaks to a major problem in areas of software development that involve a lot of logic but are considered "not programming." A lot of effort is put into technologies that allow "non-programmers" to work with these tiers of app development, and I think they generally backfire.

The most common one is tag libraries in place of scripting. The Java world is probably the biggest offender here. The JSTL started out as a way to create cleaner looking pages - and maybe it has - but the spec got to the point where they were recreating the entire Java language as a separate set of tags. Supposedly, these tags are easier for "non-programmers" to use, but by the time you're setting properties for objects and using conditionals and loops, you may as well admit you're a programmer.

I'm no big fan of long jsp pages, but I prefer Rails's approach to scripting: if a task requires programming logic, use a programming language.

Ultimately, I found the "you're doing it wrong if you include scripting in a view" to be very unconvincing, especially if the tags you replace it with end up recreating the programming language you're not supposed to be using in the first place.

Markaby is pretty sweet:

  html do
    head { title "Boats.com" }
    body do
      h1 "Boats.com has great deals"
      ul do
        li "$49 for a canoe"
        li "$39 for a raft"
        li "$29 for a huge boot that floats and can fit 5 people"
      end
    end
  end

I first ran into this issue several years ago, while I was using PERL (blargh).

PERL has packages that allow you to put your HTML inside your code, or allow you to put your code inside templates.

It soon became clear to me that neither is the win - the only real difference is "if I don't escape (via a quote character or a <? or a <%), what is a character considered - HTML or code?".

The problem is that code is there are two different conceptual trees - the HTML tree with nested elements, and the code tree with nested logic, and these trees do not have a 1:1 correspondence.

This is not a simple problem, and there are not simple answers.

Programming in Ruby and Rails for the last few years, I've become a fan of partials, but the tradeoff that you get is that for greater ability to read one file, you lose locality of reference ( http://en.wikipedia.org/wiki/Locality_of_reference ) - you might have a table row in one file, and the data data in another file entirely.

In general, I am a huge fan of straight text based editing, and always raise a dubious eyebrow at proposals for graphical editors and strange new editing tools.

...but I seriously wonder if there's some solution off in the space of a different kind of editor that lets you switch back and forth between viewing the code tree and the presentation tree...

So he wants to use PHP, then. Uh, I mean, the way PHP used to be written, with code and HTML mixed.

I'm dumbfounded that he does not notice the circular nature of his proposal.

Scala also has in-line XML literals.

Pretty much every Lisp has a way to express markup directly as S-expressions.

I really hope this doesn't start a trend of not using templates. Templates may not be perfect, but they're the best we've done so far (Seaside aside).

He's about 1/3 of the way to reinventing BRL.