Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> don't use templates, generate HTML from code with a DSL that makes HTML

I agree. This is how I've done it for last few years and have recommended it before on HN.

ref: http://news.ycombinator.com/item?id=1518096 | http://news.ycombinator.com/item?id=705706 | http://news.ycombinator.com/item?id=705800

also: Web Development as Tag Soup - http://news.ycombinator.com/item?id=252185


> There is no longer the designer/programmer separation, now with CSS designers can do everything if your HTML layout makes a bit of sense.

I'm sorry, but this is simply not true. You can't just magically move elements around in CSS without changing the markup. And even if you can accomplish a lot, many things will become very awkward as you try to tweak CSS in ways that was never intended.

I think we must just accept that we have a markup language (HTML; <p>, <strong> and so on), a way to style that (CSS) and a layout engine (CSS+HTML; <div>, <span> and so on).


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!


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

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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: