Live data from Hacker News

Idea: using code rather than templates to generate HTML

github.com

41–50 of 74 posts

Re: Idea: using code rather than templates to generate HTML

#41
post #35

Earlier quoted context omitted.

Yeah, that's one of my objections. HTML is a designers tool, and generating it is basically a programmer working by what they perceive as an annoyance by shooting someone else in the foot. It also smacks a bit of "I see no value in how this is done so I'm going to generate it from code", which I think is ignorant, but that's my opinion. I also don't think it's as maintainable, but I have no evidence to back this up (…

HTML is a designers tool I thought the modern idea was that CSS is the designer's tool, and HTML should only be used for marking up content in the most semantically "correct" way (which has nothing to do with design).

It can be a little tricky (containing elements and wrappers mainly) but I agree with this concept. It's just hard to put into practice.

Re: Idea: using code rather than templates to generate HTML

#42

Earlier quoted context omitted.

I don't want too sound negative, but there are a number of reasons this is a less than feasible idea. First it's overkill. The reason we have a www at all is because HTML and its variants are dead simple. If the client decides that six key sentences should be yellow and emphasized, I go into my template and add a Yellow text! to my template. Using your generator, I now have to figure out a whole new way of doing that…

Er, or you could do Yellow Text! . But that's not even the best. What if he wants to change the color later? Special Text! . CSS classes should be used sparingly and by purpose: they should describe the function of the element, and not the look of the element. But that's just semantics ;) (har, har). ASP.net uses code generated html for a lot of things: server controls, some user controls, and so forth. It can be a p…

You could, but I get to use my yellow text elsewhere, sans emphasis. :P

Not calling it yellow I think is the more important piece. In fact class="sctmtdt" seems best to me.

* (Stupid Client Told Me To Do This) :-)

Re: Idea: using code rather than templates to generate HTML

#43
post #30
post #25

Earlier quoted context omitted.

For a project 1.5 years ago, I generated all my html via markaby from _why. It really kept my html very very clean, but the downside was that the designer guy didn't understand what the heck was going on so I haven't considered using it since.

you've hit on why html (or css or javascript) generators will never catch on. they do not fit within the traditional workflow. you cannot take a delivered html document and convert it into whatever html-generator you use. the designer will have no clue how to use your (hand) converted file in dreamweaver to make small changes. in the end, it just makes life harder for everyone and costs more money.

Your argument assumes workflows never change. If that were true, we would still be using whatever workflows our forebears used for every task. Since that is clearly untrue, workflows must be able to change.

However, given that business are formed to turn a profit, the standard workflow will remain unchanged until it is profitable to do otherwise.

If a markup-generating DSL was simple enough for designers to pick up quickly, it would make good business sense to push them through the transition.

Re: Idea: using code rather than templates to generate HTML

#45
post #24

Earlier quoted context omitted.

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. Deve…

What if you want to repeat a similar chunk of HTML in a loop? What if you want variables? Functions? ? 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.

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.

Re: Idea: using code rather than templates to generate HTML

#46
post #43
post #30

Earlier quoted context omitted.

you've hit on why html (or css or javascript) generators will never catch on. they do not fit within the traditional workflow. you cannot take a delivered html document and convert it into whatever html-generator you use. the designer will have no clue how to use your (hand) converted file in dreamweaver to make small changes. in the end, it just makes life harder for everyone and costs more money.

Your argument assumes workflows never change. If that were true, we would still be using whatever workflows our forebears used for every task. Since that is clearly untrue, workflows must be able to change. However, given that business are formed to turn a profit, the standard workflow will remain unchanged until it is profitable to do otherwise. If a markup-generating DSL was simple enough for designers to pick up q…

The workflow between you and your accountant hasn't changed for quite a while.

You still share information and work through a medium you can both understand - receipts and expense logs and invoices - that's what an HTML template is.

Re: Idea: using code rather than templates to generate HTML

#47
post #31

Earlier quoted context omitted.

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…

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.

Re: Idea: using code rather than templates to generate HTML

#48
post #18
post #5

Seaside ( http://seaside.st/ ) does this. And the approach taken to an extreme works very well. It supports components with states with example.

Reading over the comments on this thread, it appears that you don't get to generate HTML from code unless you're Avi Bryant. "I am Avi Bryant, your argument is invalid."

Seaside is for building web apps. The continuations make it possible to do the type of apps that would be impossibly difficult in most (maybe all) other web frameworks. On the other hand, it's not really optimized for your typical document-based website. In this case, the generated HTML is integral to the way the whole stack is put together. Even if you disagree with this decision (which indisputably raises the bar for designer participation), you can still respect the decision within the context of Seaside.

Replacing templates per se? Much harder sell...

Re: Idea: using code rather than templates to generate HTML

#49
post #31

Earlier quoted context omitted.

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 attenti…

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.

Re: Idea: using code rather than templates to generate HTML

#50
post #24

Earlier quoted context omitted.

What if you want to repeat a similar chunk of HTML in a loop? What if you want variables? Functions? ? 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.

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.

Post reply on HN