What I don't like about this approach is that it forces me to learn a new language just to create HTML. I don't mean Smalltalk, but the specific "HTML generation API".
I have to know HTML anyway (because eventually I will have to debug it), so it seems preferable to me to also code the output in HTML.
Another approach against tag soup I have seen is xmlc, which manipulates the DOM tree of the HTML template. The xmlc project doesn't seem to be very active anymore, though.
Every web framework uses some sort of template engine. You're going to need to know the way it works and what syntax it uses and any gotchas that are there.
Also, the logic is going to bleed over into the HTML anyway. Why burden yourself with ugly line noise?
renderContentOn: html
50 timesRepeat:
[ html div
class: #SomeStyle;
onClick: (html element hide);
with: 'Who needs HTML?' ]
vs.
<% for x in range(50) %>
<div class="SomeStyle"
onclick="javascript:hide(this);">
Who needs HTML?
</div>
<% endfor %>
In the above example, I'm mixing the JavaScript with the HTML and I also see Python code (the last template engines I've used were Python-based). Three languages mixed into one template.
The Seaside/Smalltalk example, on the other hand, has one language with code that generates another language (which I don't have to touch at all, it knows how to generate a valid DIV element). So I just have to analyze the logic of the Smalltalk code and not the HTML or JavaScript unless there is a specific reason for me to do so (such as adding a new type of HTML element).
Just curious: how is xmlc not an extra "HTML generation API" that you have to learn?
I mean, it seems we're stuck here. Either we use tag soup templates, or we use some abstraction to express the structure of the page in the language of the generator code. The former requires less training and discipline, but complicates maintenance. The latter is a framework to which you'll need to adhere. No free lunch.
You have a point. I guess whatever you do, you need something to output HTML, and something to code logic. What I like about xmlc is that it stays within the standards. DOM is maybe too much to know for HTML developers, but still. It actually worked quite well to have "designers" create HTML templates and manipulate them in the servlet. The designer doesn't need to know anything but HTML, except that he has to use id tags where values in the template have to be manipulated.
Overall, I guess web development is always ugly :-(
I have to know HTML anyway (because eventually I will have to debug it), so it seems preferable to me to also code the output in HTML.
Another approach against tag soup I have seen is xmlc, which manipulates the DOM tree of the HTML template. The xmlc project doesn't seem to be very active anymore, though.