
Your templating engine sucks and everything you've ever written is spaghetti - dools
http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you
======
peteforde
Every programmer is on a long, cyclical journey where every stepping stone
feels like a new kind of enlightenment. Blogging allows them to share their
brilliance with the world, showing how they are surely amongst the first to
attain their new level of purity and zen.

The funny thing about this post is that the author tells us to get off our
high horses and come down from our ivory towers... and then proceeds to make a
series of highly conjecturable claims presented with no factual evidence
beyond his own confident assertion that he's in the know. There's like, no
chance that in two years he'll be advocating for his new new philosophy.

In the meantime, I'm left to wonder "Iain Dooley who?" and be glad that I'm
confident enough not to read an opinion-as-fact article and assign it
significant credibility.

PS: A good first editing step is to ask "does my opinion-as-fact blog post
question the capacity and potential of a professional web designer to
understand simple concepts like string interpolation, and could they find this
insulting?" before assuming that you've got it all figured out.

~~~
dools
Whilst this article is indeed an opinion piece and strongly hyperbolic (and
perhaps even didactic), I'm not sure why that offends you. I don't have any
statistics about large or small organisations putting this into practice so
I'm not sure what other facts I could have included apart from the examples I
provided.

The capacity of designers to understand anything isn't the subject of the
post, so I'm not sure why anyone would be offended by that.

The idea is that it's easier to find someone to work on HTML/JavaScript/CSS in
a static HTML context than it is to find someone familiar with whatever
frameworks you're using and it's templating language, then to have that
installed locally (especially when you're not working with a long term in-
house team of designer/developers and don't have lots of time to spend on
training people).

I also personally find it far easier and quicker to iterate and test new
interface ideas quickly when working with static HTML so I like to be able to
view my templates outside of the context of my application/framework etc. and
then iterate without having to re-apply a bunch of templating code.

~~~
fleitz
It's ok to write a little polemic here or there but don't be surprised when
people react negatively to it. People are offended because you are saying they
are incompetent at their profession.

Have the humility to understand that many of us have been doing this for years
and have seen numerous attempts to revolutionize templating, and _gasp_ have
written webapps before the idea of templating really took hold.

If you want to persuade people to take up your ideas regarding DOM
manipulation in the controller, I'd suggest not starting by telling people
they are writing spahgetti code. It's a great way to get page views, it's a
poor way to persuade people.

People probably would have reacted much better to your argument if you started
with "Hey, I'm doing things this way and here's why it works for me" instead
of "You're all idiots who write spaghetti code". Embedding XSL selectors in
HTML attributes which is processed by a half-assed implementation of XSL in
PHP is the kind of thing I think when thinking spaghetti code.

What you don't realize is that you've invented a new templating language based
on XSL but with half the features. Those of us who've been around the block a
few times like to call this inner-platform effect. We've also seen this idea
before when it was pitched with J2EE and used XML with an XSL templating
system.

~~~
dools
Hi, thanks for the tips. I'm always interested in opinions on my writing style
and how to communicate better.

Regarding your critique of Fragmentify, that's actually not so much what I'm
advocating here as it is just the impetus for realising that there are 2
distinct components to templating which are: 1) the re-use of common assets,
and 2) the application of some "logic" to display dynamic data.

It doesn't matter what you use to fragment your markup (I personally think
that using XPath to manipulate an XML document isn't particularly off the mark
but whatever, to each their own). Dreamweaver allows you to edit common assets
pretty easily and then export a ZIP with head-to-foot complete HTML documents
in it. I'm sure there are a million other ways to skin that cat.

What I'm saying is that the separation between "display logic" and "business
logic" either doesn't exist or at the very least shouldn't be occuring between
the backend and the frontend.

You could, if you wanted to, put your "view rendering" code in some other
place in your application, but that's tangential to my case for completely
removing any and all logic from templates and working solely with (and
iterating solely with) HTML/CSS/JS when building your interfaces.

~~~
fleitz
Personally I'd never use it because I intensely dislike the syntax of HTML and
CSS and avoid it at all costs since discovering HAML/sass.

I find a text editor (vim in my case)/photoshop + haml/sass + live reload to
be my most productive workflow, one screen for the text editor, one screen for
the browser, when I save the browser reloads the page.

For me there are a lot of things that just work smoother by having the data
populated, when I work with designers I just take whatever they give me
(sometimes just a PSD) and work with it, if they need static HTML/CSS I just
use wget/save as webpage to save the html and assets.

------
simonw
Templating by manipulating the DOM is one of those bad ideas that just keeps
on turning up. At first glance it seems like a eureka-moment flash of purity,
but the practical realities of it are pretty horrible.

For any change to the page more complex than tweaking copy or maybe changing
an element (a ul to an ol for example) you'll have to update both the HTML and
the DOM manipulation code - killing your separation of concerns.

Even worse, you have to have a complete understanding of how what the DOM
manipulation code does before you can edit any of the HTML at all - otherwise
you might accidentally kill the page by changing the order of two seemingly
unimportant elements, or deleting an unused div.

You'll also be forced to make all sorts of compromises in your markup to
accommodate the templating layer, which will drive your front-end engineers
crazy.

Finally, there are extremely useful aspects of regular template languages
(like template inheritance and includes) which don't map at all neatly to a
DOM manipulation engine - so you'll probably have to compromise on those and
end up inventing your own weird attribute-driven template engine.

I'd suggest approaching this idea with caution. There's a reason most popular
template engines are designed the way they are: practicality beats purity.

~~~
dools
Actually, my suggestions is just to encourage template implementation and
refactoring with impugnity. There are perhaps ways of refining workflow to
ensure that ids and classes are perhaps changed less than other aspects of the
markup and used as hooks to "animate" the templates, but any time lost fixing
broken templates as a result of an incompatible change pales in comparison to
the time spent going back and forth between designers and developers to fix a
problem where the scope happens to fall in between 2 skillsets (particularly
when dealing with people in different timezones).

~~~
simonw
I remain skeptical, but I'd love to hear about a collaborative project that
used this technique succesfully

~~~
dools
Yes I have to put my money where my mouth is. I'm thinking the best way to do
this will be to take a relatively simple application and have it built
entirely through outsourced labour, then I can publish a more objective (and
factual :) assessment of the merits of the method.

------
pyre

      > As soon as I'm looking at more than one programming or
      > markup language in the same file, I'm looking at
      > spaghetti code.
    

By this definition the following is 'spaghetti code':

    
    
      $dbh->do("delete from my_table");
    

Following his logic:

    
    
      1. Realize there's SQL and Perl in the same line.
      2. STOP EVERYTHING
      3. Start attempting to fully abstract SQL into Perl
         so that no one will ever need to write a line of
         SQL again.
      4. Die an old man, never having accomplished this task.

~~~
notaddicted
I've actually seriously considered keeping all my SQL queries in their own
files, and reading them into local variables on load. It would allow them to
be tracked and edited individually... but I now use an ORM.

~~~
ExpiredLink
> .. but I now use an ORM.

"ORM is an anti-pattern":
<http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern>

~~~
einhverfr
Agreed ORM's are usually very sub-optimal. They make sense only because
application developers aren't db people. And this is the problem.

I suspect for certain parts of some apps, ORM's might work OK. But in general
for applications of any complexity they will break down hard and fast, and
lead to bad db design, bad performance, or both.

~~~
MatthewPhillips
ORM is just less work. If you write in OOP you are already creating objects
anyways. Then writing get, save, and update procedures is just a lot of extra
work.

~~~
einhverfr
The problem is then you build databases around your ORM but if you are doing a
single app database, why use an RDBMS at all?

In other words, I see an ORM as an antipattern because the subset of cases
where it works really well at bridging the gap you probably don't really want
an RDBMS in there anyway.

And if you do make it work (encapsulating your db behind updatable views)
without running into this, it's a heck of a lot more work than hand-coding
SQL.....

------
luigi
I was inspired by this project for Node:

<https://github.com/hij1nx/weld>

And I tried the concept using Nokogiri in Ruby. I found that in practice it
gets really tedious. I had to make sure that every single element I wanted to
manipulate had a unique id. Then I had to account for updating the content of
an element versus an arbitrary attribute for that element. Or adding an
attribute, like some data-* attribute. I realized why string interpolation is
just so much easier.

There's also the problem where the DOM parser changes the original HTML in
some way. How will it deal with conditional comments for IE? Or slightly
malformed HTML that you want to keep that way?

I ended up going back to Handlebars.

------
Harkins
Instead of including if/then/else logic in the template, templates are
duplicated for each branch and the logic is pushed up to the controller. This
takes on hand-managing duplicate code (because there will discrepancies
between the "logged in" and "logged out" version every time someone forgets
they need to change two files, or doesn't notice there is a second version to
touch) to avoid having any code in templates (which it labels as technical
debt without support).

This does not seem like a worthwhile tradeoff to me. And the author doesn't
address loops, which often want to have special treatment of first or last
elements, even/odd rows, and other small bits of logic. When you combine these
things, you're going to have a combinatorial problem, I can just imagine a
shopping cart table with templates like
shopping_cart_item_list__table_row__last_item__logged_in__even_row__multiple_quantities__discounted_item.html

And what's with the really confrontational tone? This article would've been
improved by spending a couple hundred fewer words putting words in the
reader's mouth and insulting their tools/code. There's a chance this could be
useful in some situations, but I sure don't want to spend any time talking to
this guy.

~~~
dools
Loops with special treatment for first and last items is quite simply dealt
with by including a list of items (for example) in the static HTML mockup, the
first and last of which is different from the middle one.

EDIT: Also in response to the issue of double handling, I did mention this in
the article:

 _In that second example of course, we've got a bunch of duplicate markup, but
that's not our problem. That is the job of whatever system you're using to
fragmentify your templates and re-use common assets_

------
voidr
> A typical example written in PHP would look like this:

That's not how templating works, that's just some messed up code.

I totally disagree with the idea that having static HTML as templates and
transforming them with DOM manipulation is better then templating. When you do
DOM manipulations you make assumptions about the structure, if that structure
is changed by somebody, you are screwed. The less assumptions you make the
better. Also last time I checked DOM parsing was a relatively slow process,
even if it would be better than templating it still has to justify the
performance overhead.

Also let's not forget that writing if's are easier than writing DOM queries.

Templating allows separation of view logic and business logic, I find it much
cleaner to have the view logic in the templates, this is in fact what the
author complains about, but how is having both database calls and layout logic
in the same place cleaner?

------
snprbob86
Funny, we've been doing this with a modified-Backbone.js site and have found
it requires tedious, manual management of an excess of IDs and classes, plus
an error-prone mountain of jQuery expressions.

What I'd really like to do is go 100% the other way: all functions, all the
time.

A view could just be a named function, accepting the object(s) to be rendered
as arguments, define some closures for callbacks/event handlers, then return a
DOM structure.

~~~
Animus7
I've been doing exactly that in my more recent projects, and it works
extremely well for simpler views/shallow DOMS.

But it turns into write-only code pretty fast when you have tons of callbacks
flying around for highly interactive elements.

~~~
snprbob86
For one-off actions, like the "save" and "cancel" buttons, callbacks don't
descend into madness. Most UIs have very few _commands_ which need true event
handling. And the ones that do, the commands are often pretty simple one-
button -> one-command. Sometimes many-buttons -> parameterized-command.

For everything else, you can use data-binding. If you're already writing
lexically scoped render functions, you can trivially create a data-bindable
local object in a variable to eliminate the event management process. Instead
of an onclick event for a checkbox, you can trivially set the checked property
to be equal to an observable value box containing a boolean. With the right
abstractions, callback spaghetti is not an issue.

------
einhverfr
Well, the only time I have ever said exactly this was about SQL-Ledger which
used a home-brewed template system (which sucks big time) and which is mostly
spaghetti code (in the true sense, of logic wandering aimlessly between
modules in ways difficult to understand and predict. Of course the fact that
the template system sucked and the code was spaghetti were unrelated except
the fact that they were authored by the same (IMHO inept) developer.

On to the article though.... I think that what the individual is discussing in
fact is something different, which is the need for stable API's between layers
of the application.

I am very skeptical of his idea that all projects can benefit from his
proposed solution. Indeed in areas like complex reporting, a template is
conceptually simpler than HTML mockups that have to be populated by
Javascript. At that point XSLT on the client starts making a lot of sense....
However, not at all sure that's always a win compared to templates. But then
XSL files pose all the issues he is complaining about!

The beauty of templates on the other hand is the ability to create diverse
output. XSL is no different there. One can create a LaTeX file, an HTML file,
a CSV. Anything else. For systems that need that diversity, going with HTML
and Javascript is a net loss.

------
antirez
Solution: don't use templates, generate HTML from code with a DSL that makes
HTML and code the same thing. There is no longer the designer/programmer
separation, now with CSS designers can do everything if your HTML layout makes
a bit of sense. Also there is no need to generate complex HTML as it was the
case N years ago, it is mainly a semantical affair, and fits perfectly inside
the code.

Templates suck, they fake an abstraction layer that actually does not exist
since the code and the template are strictly connected in all the non trivial
cases. It's just a lame substitution layer forcing you to switch from one file
to the other while coding.

~~~
dools
I think that having a separate DSL that abstracts HTML/CSS/JS is not the
answer. When you abstract HTML (or SQL or whatever) you find that eventually
your abstraction basically has to do everything that the thing you were
abstracting needed to do in the first place.

I think the "just use CSS" or "we can boil HTML/CSS/JS down to a subset of
reusable chunks" doesn't work. It's simpler to just let these technologies be
what they are, and remove the need to care!

~~~
antirez
You are right, I don't mean "abstract HTML", I just mean to provide a way to
generate it from code using the same syntax of your code. This is what I use:

[https://github.com/antirez/lamernews/blob/master/app.rb#L138...](https://github.com/antirez/lamernews/blob/master/app.rb#L1388)

For instance to write

    
    
        <foo>
          <bar id="4">content</bar>
        </foo>
    

You write:

    
    
        H.foo {
            H.bar(:id => 4) {"content}
        }
    

So everything you can write in HTML you can write in this DSL, there is no
real abstraction, but it is Ruby code like in all the rest of the application.

~~~
dools
Okay so now here is my problem with this: I can't just find whoever knows
HTML/JS/CSS and get them to work on this by sending them a ZIP file with the
interfaces in it. They have to install the environment and application and
then iterate using this DSL, refreshing the page to see it in the browser.

It is far easier to find a really good designer, who knows HTML/CSS and a bit
of JS (probably jQuery) than it is to find a really good designer, who knows
HTML/CSS and a bit of JS (probably jQuery) and then is also comfortable
configuring a Rails environment and also proficient enough with coding Ruby to
learn quickly and without support or input, this custom DSL.

There are already so many people that have the skills you need, why force the
issue? Let the technologies be what they are. In my experience, communication
between team members is the single highest cost in building software. Unless
you're a designer/developer or you're working with a small team on your
startup and you happen to have all the skills you need right there in one
office and timezone, you'll need to confront the issues of resourcing,
iteration and staff changeovers - what I'm advocating is that we play to the
prevailing skill separations and reduce the communication overhead.

~~~
draegtun
Think of your HTML as being data along the same lines of JSON, XML or any
other data feed. Then tell your _designer/front-end person_ to just create the
necessary CSS & Javascript to apply to it.

Thus you remain in full control of the data (HTML) and you've completely
separated the design (CSS) & behaviour (JS) logic that gets applied to it.

------
extension
Views have logic, sometimes very complex logic. If views are not allowed to
have "code" in them, or are functionally crippled in some way, then
presentation logic is probably going to get mixed in with the domain model,
because there won't be any other place to put it. The programmer needs to have
complete discretion in where they draw the line between domain and
presentation.

This codeless view mythos arose because HTML includes a lot of rich
interactive capabilities, and it's tempting to declare that these capabilities
are all you will ever need in your presentation layer, but that is arbitrary
and false.

In most other contexts, e.g. GUI programming, a codeless view is nonsensical.
Code is everywhere. And if it's difficult to write nice view code, that's
likely a problem with your programming language and/or your APIs.

Also, don't conflate model/presentation separation with server/client
separation. Ideally, they are orthogonal concerns. To create the best UX, your
views, and possibly your models, will have to straddle the network.

In short, don't let your technology stack dictate how you modularize your
application.

------
thurn
What he's describing is best realized in the Enlive templating library for
Clojure. You perform a suite of transformations on regular html files.

~~~
draegtun
_Push style template_ is a phrase I've seen used to describe these kind of
templating systems: <http://news.ycombinator.com/item?id=2238885>

------
CyruzDraxs
The moment a programmer thinks they know the ultimate solution to a problem is
the moment they understand the problem the least.

No, templating is not perfect. Nothing a programmer does is perfect. Our job,
as programmers, is to make stuff suck less. We break stuff until it works. We
squash bugs until we can't find any more. That doesn't mean what we've built
is perfect. It means what we've built is the best we could build with our
current understanding of the problem.

I don't think of spaghetti code as the presence of logic in presentation code,
I think of it as a lack of separation of what SHOULD logically be abstracted.
I find the code it labels evolves over time as the common abstraction level of
things increases and we move closer and closer to fully isolating concerns.

------
ronreiter
You are plain simply wrong. First of all, logic in templates is something
which is OK to have. Different templates display information in different
manners. Second thing, I don't think you've seen how awful and unmaintained
code which manipulates DOM instead of templating looks like.

~~~
dools
The point I'm making, though, is that the challenge of solving
"maintainability of DOM manipulation code" is a simpler problem to solve than
the creation of the perfect templating language.

What's more, a good DOM manipulation strategy and library can be really easily
ported to any language, freeing up your templates to go wherever you may feel
is appropriate in the future.

------
rickmb
The main problem isn't templating engines. And although a better solution is
always welcome, a bit of procedural code inside a template is not a big
problem either.

The real problem is that so many projects and frameworks don't have a powerful
enough View layer that is _separate_ from the (preferably optional) templating
engine. In many cases it's even worse, and the templating engine _is_ the
entire implementation of the view layer. This pushes a lot of view logic into
the templates, where it quickly degenerates into spaghetti. (In even worse
cases, any logic the templating engine can't handle gets coded inside the
controllers, and view logic starts leaking through the layers.)

Fragmentation into purely static templates is only a solution if you've dealt
with with all the other view-related issues, and still end up with too much
logic in your templates. And by "too much" I mean that it results in errors
and maintenance overhead, not just that it looks ugly.

Intensive use of logic inside templates is definitely a code smell, but you
have to be careful not to address the wrong problem. The templating method
itself is rarely the root cause.

------
llimllib
Yeah, well, your website sucks and doesn't load.

~~~
dools
It seems to be serving that page in around 5 - 7 seconds but it's pretty
heavily loaded. Yes I wish I'd gotten around to doing all that stuff that I
know I should do in order to make it load faster than it does right now.

PS: If the site didn't load, how do you know it sucks?

~~~
ichc-werker
Hey dools, these two images are broken for me:

Instead of splitting up the task of templating in the following, arbitrary
fashion: [broken]

We can create a non-arbitrary, completely objective separation where the
view/template layer truly contains no logic what so ever: [broken]

Cool article; made me think about how I've been handling views. I think I
agree with you, but I'll need to mull it over for a while. Thanks!

~~~
X-Istence
He has hotlinked to ditaa.org and that server has fallen over.

~~~
dools
Yeah unfortunately - I didn't actually mean to do that. I don't even have a
cached copy of those images :(

------
barumrho
But now aren't you putting design into logic?

~~~
saurik
At first I thought this (and even typed out a long explanation of "the reason
why you cannot make the assumption that your resulting document will be
manipulated with DOM" involving "what if you want to change the presentation
layer to PDF"), but then I realized that nowhere did he advocate mixing the
DOM manipulation into his other logic; it could just as easily be a completely
separate pile of "presentation to HTML" code that was entirely unrelated to
the "generate content to present" layer.

~~~
barumrho
Hmm. I do understand what you are saying, but in most cases where you are
outputting HTML, how is this really different from using templates? I see
templates as a way to reduce redundant code. The examples on the blog post are
simple (e.g. removing a node, which is easier with 'if' statement), but it
will probably be messier.

Regarding alternative formats like JSON or PDF, I guess you can add a layer
there.

~~~
saurik
First off, let me be clear (as I'm concerned that your bringing up this
unrelated "messier" argument is the beginning of me being used as a proxy for
the author): I am not generally arguing in favor, I was simply countering that
specific argument against. I will now describe why they are different, but I
do not want this to be taken as a defense of the method.

The way it is different is that it is an inversion of control inside the
template, not that it is changing up the layering. You still have a "construct
data" layer and a "present data" later, and you can still swap out the
"present data" layer with something unrelated, such as a normal template
engine or whatever else you wish to use to generate JSON or PDF.

However, inside the "template", rather than having HTML with embedded logic
(where you can almost envision the HTML calling into the logic to insert text
or execute flow control at specific points), you instead have logic that
manipulates the HTML via DOM, modifying the HTML to contain text at specific
points. You could probably even make a compelling argument that these are
duals of each other.

------
wwweston
I've been thinking about some of the ideas in this rant for a while now. I
might not have put it in quite such an opinionated manner (templating systems
aren't usually my biggest problem), but I pretty much agree with a few things:

1) Fragmentation is a problem, particularly with some templating systems.
Layouts should almost always be a single file. Things going inside the layout
should probably be single files.

2) As long as templating means sprinkling extra tokens to process throughout a
document, there's going to be some coupling problems. Transforming a document
based on some external criteria is an interesting alternative.

There's certainly a number of transformation based solutions out there, some
of them pretty powerful. But as I was thinking about this a few years ago, it
occurred to me that maybe I don't want a powerful uber-transform set so much
as I want a simple descriptive set of semantics for _addressing_ content into
nodes of a document.

Then I thought about where I'd seen this kind of thing come up before in the
realm of document styling: DSSSL and XSLT vs CSS. The simple descriptive CSS
won out and has worked out more or less well.

So... I came up with something I called `CAST` (Content-addressed Style
Templating):

<http://weston.canncentral.org/web_lab/CAST/about.html>

Basically, you use a subset of CSS selectors (or XPath queries) to pick out a
node of a document, then you specify a content rule, and the engine drops a
content string into the document node.

I ended up writing my blog around the idea. I ended up being pretty happy with
a very simple set of rules, despite the fact that there's not much too the
system beyond that -- for example, there are no rules for conditionally hiding
a node based on whether or not it's needed, no rules for repeating certain
nodes. I think those things might be nice, but it turned out if I was willing
to push a _little_ bit of the view down into model layer, I didn't need them
at all, and I was (I kindof tend to think that any application is going to
have a bit of model-view bleed-across anyway, you just have to figure out how
you'd like to manage it).

If anybody's curious, this post made me get off my behind and put the code up
on GitHub:

<https://github.com/westonc/CAST/>

But it's in PHP, which I suppose will probably turn off a lot of the cool
kids, so I should probably write a Ruby or Clojure version. :)

~~~
dools
Yep this is pretty much the idea. The key thing is, though: however you do it
on the backend, that's entirely a coding problem. DOM manipulation sucks?
Well, solve that problem, which is where something like your CAST library
comes in.

It's easier to solve the problem of making a nice, easy way to "address"
content (I used "animate" but basically they're the same thing :) than it is
to solve the multitude of problems caused by choosing a technology stack and
creating templates in it for your application.

~~~
einhverfr
To be clear, the primary use case here is in a case like Etsy, right? This
doesn't work so well when we want to have a consistent interface to create
HTML, PDF, CSV, XLS, and ODS files, correct?

Presumably DOM manipulation really can't be done beyond applications which are
HTML-only in any reasonable sense without getting back to the things you don't
like about templating, right?

~~~
dools
Well, the thing is that if your target output isn't HTML, then you wouldn't
need to do any DOM manipulation. You'd just output whatever else it is you
want to output (JSON, XML, PDF, whatever).

If you had, for example, a bunch of PDF code as a "template PDF" then you
might just load that and do string replacement on whatever placeholder text
you have in there - but yeah the primary use case I'm thinking of is in
implementing web based interfaces.

~~~
dools
Sorry einhverfr I can't reply to your comment - but what I think you're
talking about is trying to abstract display for HTML, PDF, LaTeX, whatever
into a common markup language or template, then repurpose that markup for each
output format. Does that sound correct?

So like, you'd want to be able to have something like:

    
    
      <article>
            <title><% print article.title %></title>
      </article>
    

then do something like:

    
    
      $tpl->article = fetchSomeArticleFromTheDb()
      $tpl->output('template_name',Format::PDF)
    

My argument to that would be that there's no realy need for that abstraction -
you don't gain anything by it because you have to have some abstracted output
engine that is capable of doing that HTML can already do, which is like, HTML
:)

Hey, I'd love to continue the discussion, but I think the HN comments are kind
of limited in how much they want you to discuss here, feel free to email me
iain@workingsoftware.com.au

EDIT: oops, code formatting

~~~
einhverfr
Just to be clear, I am not entirely hostile to the idea here. I just think
that there are plenty of cases where generating high quality printed content
or the like doesn't work with it and templating is a lot cleaner in those
environments. And when your application already requires templating for a
reason like that, adding an entirely different way of handling another output
format adds needless complexity.

One of the useful applications of dools' ideas is that you could have a mockup
which included lorem ipsums or other dummy text. This would make it easier for
web developers to test layout.

OTOH, as I say, I am not at all convinced that it is a net win for programs
that generate multiple formats of output./

------
carsongross
The idea of templating as a separate activity from coding is what, in my
opinion, is wrong. It comes from the days when "front end" guys didn't want
javascript or "back end" logic in their files. Personally, I would just prefer
that the code _for_ a button be located _with_ that button. Crazy, I know.

Back in the day (2001) I didn't understand the separation of logic and
presentation, although I grudgingly admitted that the front end guys had a lot
of stuff to worry about that I didn't understand (cross browser issues,
rendering issues). These days, with jquery and widely available standards
compliant browsers, plus all the design resources available on the web, we
should all be both front end and back end developers, to a greater or lesser
extent.

So we should strive to have clean code, but that, IMO, doesn't have nearly as
much to do with separating concerns like templating and application logic as
the "pure-templates" guys think.

I disagree with the "pure-model" and "pure-controller" guys on the back end
for the same reasons. They fall into the same platonic manichaeism: the world
is a mess and if only The One Pure Way were followed, we'd be good. Instead,
grouping things logically as best we can and trying to minimize spooky action
at a distance ("where the _hell_ is the code associated with this button
coming from?!?!") should be the goal.

------
cousin_it
I agree that putting code in templates can lead to spaghetti. But the OP's
proposed solution seems suboptimal because loosely coupling the template to
the application code via "template animation" will lead to convoluted code
with lots of hardcoded IDs on the application side, and brittleness on the
template side because there's no way to see which IDs are used by the
application.

A less extreme but more practical solution would be to disallow code in
templates by making templates accept a data structure, like JSON, and giving
them the bare minimum of capabilities to render it. So looping over an array
is okay, checking for the existence of a property is okay, but querying the
database from the template is impossible by construction. This way you also
get language independence because many languages can generate JSON. Also, you
can have compile time error detection (for both the template and the
application code) if you use some sort of schema for the data structure, like
Thrift or Protocol Buffers.

------
dendory
I always get entertained reading the latest stories about templates and the
latest innovations on how to make web sites work, and how (language x) is so
old now, and everyone should use (language y) because it's more logical. I
built my own custom CMS in 2008 and have been slowly improving it, and to this
day I have a full dynamic site working on less than 600 lines of PHP, HTML and
JavaScript. No JQuery, no need for a dozen includes, or keeping up to date on
the latest patches of 12 different code bases. Yet the site keeps chugging
along, even got to the front page of HN without any issue handling the load,
while some sites mysteriously go down, but it's never the developer's fault,
they just had a problem with their backend db server, or forgot a critical
patch, or ne of their libraries didn't behave well with another library under
heavy load...

Not sure what my point is, I guess that there's something to be said for
keeping it simple, and not chasing new technologies without reason..

~~~
dools
Glad I could entertain :)

------
cheeaun
This approach reminds me of hquery (for Ruby on Rails) by choonkeat:

[http://blog.choonkeat.com/weblog/2008/10/hquery-an-
unobtrusi...](http://blog.choonkeat.com/weblog/2008/10/hquery-an-unobtrusive-
server-script-implementation.html)

<https://github.com/choonkeat/hquery>

~~~
dools
Yes! In fact, in the Q&A he even says this:

 _Nope. "hquery" is just a library I wrote to do USS in Rails. I believe any
language / framework can have its own USS renderer._

I'm totally in agreement on this. Any language or framework can address this
very simply - we don't need "one to rule them all".

------
jasonlotito
So, he's trying to rewrite XSLT. Gotcha.

------
eob
Been working on something like this for a while and nearing a big push of
version 1 to github. Glad others feel the same way!

~~~
dools
Make sure and post about it when you do - I definitely want to see more
momentum around this and was pleasantly surprised when I saw that solutions
already existed. My favourite thing about it is that it transcends
"technology". The fact that you've been working on this is no loss to someone
else who's been working on something similar as the cost of changing from one
solution to another is so dramatically low when all the value is retained
within the templates themselves.

~~~
eob
Likewise. Two other template engines you might be interested in are
Knockout.js (<http://knockoutjs.com/>) and the template engine from the Lift
web framework. Both play relatively well within HTML.

And Stanford has done some nice work on segmenting the DOM into semantic
chunks. The site appears to be down now, but it's usually hosted at
<http://bricolage.stanford.edu/>. Check out their paper on the "Bento"
algorithm.

~~~
sorenbs
The lift book is worth a quick look if you are interested in templating
engines. In short, instead of logic in the view, css selectors are used on the
server side to transform small chunks of the website in a statically typed and
safe (the dom structure is carried around as xml instead of a string which
makes it possible to prevent most of the common security problems on the web)
way <http://simply.liftweb.net/>

------
judofyr
I've talked about "template animation" (or "mockup-driven development" as I've
called it) before, but focused mostly on how to achieve static files that can
easily be opened in the browser (without any server components) and still be
modular (layouts/partials): <http://timelessrepo.com/mockup-driven-
development>

This article seems to solve modularity by splitting it out into different
files. On the same page you can have dozens of modules that can have several
different states;how are you supposed to combine them all? How do you say
"this page contains a sidebar, a blog post, comment section" and that there
should be a "new comment"-form if the user is logged in and "delete"-links if
the user is a moderator? In the example in the article, it seems that would be
solved by having blog_post.html, blog_post_logged_in.html and
blog_post_moderator.html, where 90% of the content in the files are
duplicated.

Beside, in the example templates you can't actually open the templates in a
browser (because it only contains the content, not the stylesheets, script-
tags etc. that you need). So if the designer wants to see how it actually
looks, he still needs a server that can wrap the layout around it.

Okay, but maybe you don't need the "view this template without running the
server"-requirement. I'd still argue that dools' current approach is brittle.
The reason is that he's now tying together two layers (the template layer and
the animation layer) and there's no easy way to see what the animation layer
will actually do. This means that small changes in the template might
invalidate the animation. You really don't want to re-write the animation just
because the designer switched from <h3> to <h2>.

This problem is easily solvable though: Use custom attributes which doesn't
conflict with HTML/CSS:

    
    
        <form>
          <dl class="error" id="whatevsError" animate="error">
            <dt>You have to do something about this</dt>
            <dd>The reason we ask you do do this is so that we can laugh all the way to the bank</dd>
          </dl>
          <dl>
            <dt><label for="whatevs">Whatevs:</label></dt>
            <dd><input type="text" name="whatevs" id="whatevs" /></dd>
          </dl>
        </form>
    

However, as you're adding more features to these attributes, you'll actually
end up with _another template language_ ; it just happens to be encoded in
HTML/XML. From here on we might wondering, why should we "hide" the logic
inside attributes (where it can be easy to miss) when we can use a more
distinctive and effective syntax?

To summarize:

\- If you want to separate the template and the animation (so that you can
easily change the template without updating the animation) you need to stay
away from HTML/CSS-semantics and use custom attributes/tags that you know
won't conflict.

\- If you use custom attributes/tags you've essentially created another
language which deals with the logic for you.

\- If you don't care about the "view the templates without running a server",
you might as well use a completely different syntax (which probably is going
to be easier to understand than the "hide everything in the DOM"-approach).

~~~
dools
These are great points, and I certainly agree that some convention is required
in template development to ensure "less brittleness". I think it's simple
enough to do this with ids and classes, though, and even when it _does_ break,
the time it takes to fix it is going to have a pretty trivial impact on your
overall project because the problem is solvable, quite simply and without much
hunting around, by one person without the need to communicate with anyone else
on the team.

Regarding the logic issue, I don't think you'd realistically end up with an
intractable number of logic variations. If you have extra links that are there
when the moderator is logged in, they should be there in any template with
that structural element in it and then removed if the person logged in isn't a
moderator.

Granted, though, I have to put my money where my mouth is and port one of my
existing applications over to using this methodology (which is, in fact, what
I plan to do so the proof the pudding will be in the eating).

Regarding the issue of "viewing the template without a server" - in the case
of Fragmentify, all the frontend dev needs is the standard apache/php that
ships with OSX. This is considerably less complex than having an entire
framework/application environment installed and kept current. That being said,
however, the _way_ in which templates arrive at the "animator" is not the
animator's problem. Dreamweaver lets you edit common assets and then exports
head-to-foot complete HTML files in a ZIP, so just use that. So long as the
"animotor" has complete HTML files to work with, that's all that matters.

~~~
hetman
You're assuming the breakage will be something obvious and clearly visible. No
doubt many of them will be.

However, I would foresee plenty of breakages in obscure or not immediately
apparent places which may not be noticed for some time. For example they may
be minor (yet still very annoying for users stumbling on them) or apparent in
only certain circumstances.

~~~
dools
Well - that's kinda what testing is for. It would remain to be seen whether or
not this proves to really be the intractable problem you're imagining it to be
- let's not forget that any other method will also produce bugs. The question
is whether they're produced at the same rate or not. I have no evidence to
really say whether or not what you're imagining would be prohibitive to using
this method but my (strong) opinion is that it wouldn't be (time will tell as
I put this into practice though, and I'll be following up with more posts
about it).

------
djbender
This is so confrontational, I couldn't even read it. Stop putting words in my
mouth.

------
X-Istence
I've been waiting about 4 minutes for his web server to send me down the bits
for the site.

\---

Your hotlinks to ditaa.org seem to be down because the server on the other end
is serving stack traces ...

------
DarkMeld
Having to loop through arrays to translate data into html elements is the
majority of the problem. I'd be happy with just a solution to that.

------
Alexandervn
Isn't this all the same?

<span><?=$salary?></span> <span>{{ salary }}</span> <span id="salary"></span>

~~~
bergie
There is one important difference: the server-side templating engine will
probably retain the _id_ attribute in the last case, meaning that the
templating information remains usable also on client-side.

We use RDFa for somewhat similar purposes.

------
buster
Isn't this 2011 where web pages use Ajax and contain a lot of logic, because..
well.. Javascript and stuff?

------
zobzu
its a little more like native software's gui. that is, with website
templating, its, well, template driven. pieces of codes are here and there in
the template, following template's will.

with software, your app is code driven. the gui follows what the code tells,
instead.

even if in both cases you have a mvc these days.

------
jeremymcanally
Sounds like he wants Pakyow: <http://pakyow.com>

~~~
dools
Hmm not really. I mean, what I want is HTML/JavaScript/CSS and then absolutely
anything I choose on the backend. The framework is completely irrelevant. The
fact that there is an "itemprop" attribute in the Pakyow view construction
already invalidates it as an option for achieving what I'm putting forward
here.

------
gnorsot
I hate templating. There are just so many engines to choose from and you end
up writing your own because none of them can do what you really need.

~~~
ronreiter
What are you building there? A nuclear reactor?

~~~
einhverfr
Probably a web-based one at that.

~~~
zobzu
Show HN: our HTML5 nuclear reactor.

Oh dear. "BUT, ITS SANDBOXED ITS OK!" :)

~~~
einhverfr
Only functions properly on worstations powered by Intel Unobtanium Chips ;-)

------
yycom
An article without a byline has zero credibility.

------
rimantas
They guy is wrong thinking that business logic does not exist. Then it all
goes downhill from there. Extremely narrow view of the world he does not even
try to uderstand.

