Hacker News Reader

Comment by tvon | Hacker News Reader

Not to rain on your parade, but this is a pretty ancient idea. I don't have links handy but I remember doing this with PHP (amusingly enough) around the turn of the century, and I'm pretty sure Perl has had something in place for eons. There are also a number of Python options if you google around.

Though, at least looking at the Python implementation it seems very clean and simple compared to others I've seen (though you're importing pprint twice), but then again I'm pretty opposed to the idea in the first place so I haven't really browsed the available options.

View on HN

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.

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

Designers being able to do it isn't the problem, justifying why designers should need to is the problem.

Ah, I was making a couple of assumptions:

  any DSL which generates markup must be more concise than the markup itself

Otherwise, there will have been no point in creating the DSL. This assumption is probably fair. An example of this would be Seaside's HTML generation DSL.

  a more concise language will be better in the long run

This assumption is flawed and doesn't take the designers' tools into account. A DSL would need its own tools before it became a valuable long-term investment.

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 (but I really don't want to be the guy who has to go decipher the code that generates a website two years later, I'd even rather deal with ColdFusion).

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.

Reply on news.ycombinator.com