Hacker News Reader

Comment by randallsquared | Hacker News Reader

The reason why not is that eventually you will want to hand the site to a designer and not have to do a half-hour of work on it every coupla weeks for the rest of its life. Making things easier for the designer reduces your total work; forcing the designer to work inside the HTML your tool produces will either limit the nifty things she can do, or require you to come back and touch this code again and again. Even the tiniest templating system is more flexible.

(Sorry; pet peeve. ;))

View on HN

Indeed, the most effective team will be at least minimally cross-disciplined. I think the desire to generate HTML via code is just a case of unfamiliarity. I've been writing code since 1986 and HTML since 1994, and I have to say that there is no advantage to generating via HTML per se (frameworks like Seaside notwithstanding). If you have a decent text editor it can color and edit templating languages just fine.

Developers should write HTML for the same reason that business people should learn to edit HTML--it's the best canonical format for all stakeholders.

What if you want to repeat a similar chunk of HTML in a loop? What if you want variables? Functions? <Insert general purpose programming language construct here>? The world has spent too much time trying to hammer programming language constructs into XML-based languages and templating systems. There simply has to be a better, way, but no one has successfully come up with one that satisfies everybody yet.

That's where template systems like Django's and stuff like PHP come in handy. I can pass either off to a designer who knows HTML and they are off to the races.

Certainly there could be a better way, but HTML and CSS are what we have (and frankly they work pretty well considering that the web comprises mostly documents). Emitting HTML from a programming language can be useful, but it doesn't solve the fundamental inelegance of nested markup. Solutions like this are just indirecting the problem, adding another layer of complexity without a meaningful abstraction.

...considering that the web comprises mostly documents...

I found this interesting. I've been doing web stuff since 1996, and I would have agreed with you back then. But these days my perception is that the majority of stuff on the web should be considered to be applications rather than documents.

Fair enough, though I would consider many many web apps to be document-oriented. It's a slippery definition to be sure.

My project, phpSprockets (http://code.google.com/p/phpsprockets/) does nested markup by working as a node system. After all, if you're going to generate HTML in code you might as well do it in an object oriented way.

$table = new Sprocket( 'table' );

$tr = $table->tr();

$tr->td( "OMG I'm in a sprocket" );

I've done similar things using XElement in C#, though using PHP's magic methods makes for very short readable code.

I agree that templates are handy for separation of concerns though.

If you've designed your markup well, this argument is a red herring; the designers aren't changing the markup, just the styling. It's also just not the case that templating schemes address this pain; any time your designer changes (bad) markup, you're likely to have to alter the code that produces it.

Well, I guess I wasn't smart enough to ever design my markup well. :) I actually think that if you believe markup can be designed to be perfectly flexible using the CSS we have currently (or had in 2004, the last time I actually had an original thought about this), it's probably the case that you haven't encountered a sufficiently imaginative designer.

Templates can be incredibly simple and require no further attention, but even slightly more complex ones like Smarty work really well, in my experience.

I'm not really even thinking about the complexity of the template language, as much as I am about the fact that all of the template languages shred your HTML document into tens of little fragments of HTML. There's always an impedence mismatch between the devs and the designers, no matter what you use.

I agree that virtually no designers will be able to work directly with something like Markaby; but then, nobody asks them to. They hand the designer the unstyled output of Markaby.

Reply on news.ycombinator.com