Comment by jasonlotito | Hacker News Reader

Comment by jasonlotito | Hacker News Reader

Parent Full thread

Anything that requires you to write HTML in something that isn't HTML isn't sensible. Sure, go ahead, add tokens to the HTML that can be parsed out and rendered differently, stored in a cache or something. But as soon as you're forced to write in another language to get HTML, you've lost.

Edit: To elaborate, as some have asked: I'm speaking in terms of HTML templating. Having the software render your HTML form for you, or rending out a table full of data is fine. But by and large, the HTML should remain HTML. Granted, in this case, your not writing HTML, your writing code to generate a form. Not sitting there adding HTML attributes, which is handled for you.

As to why I disagree with this approach? At it's core, portability. You can now no longer take an HTML file and use it. You have to rewrite everything into your strange, personal, customized, non-standard language and hope everything comes out alright. Their is also the learning curve in bringing anyone else on board. You also suddenly lack the ability to use any of the tools associated with HTML. Abstraction for the sack of abstraction is silly.

If you have multiple functions for every single tag, your essentially taking HTML and just making the syntax your own. This "(ul '(id "navbar" class "horizontal_list")" is no better than HTML, but it isn't special or unique. It's cumbersome. Your also limited by the framework (which you hope will add new tags as they appear, and support the customization HTML offers).

I'm not against HTML generating code. I'm against rewriting HTML as code. Maybe someone can explain how

(ul '(id "navbar" class "horizontal_list")...

is better than

<ul id="navbar" class="horizontal_list">...

Edit 2: Also, it should be fairly obviously, but all of this is of course just my opinion. =)

At it's core, portability. You can now no longer take an HTML file and use it. You have to rewrite everything into your strange, personal, customized, non-standard language and hope everything comes out alright.

This thing generates plain, standards-compliant html. Just like the rails app I'm porting over to it. If you can't easily take html and port it in/out of whatever tool you're working in, you're doing it wrong. Even with all the abstractions, partials, specialized rails functions, I was able to port the majority of the view layer over in a lazy Sunday afternoon.

Maybe someone can explain how (ul '(id "navbar" class "horizontal_list")... is better than <ul id="navbar" class="horizontal_list">...

It's not any better. Well, there is the part where if it's invalid, there'll be an error instead of some mangled html that browser tries to fix on its own, and you don't have to remember to close the tag, but those are really somewhat minor.

The principle of lowest friction is that this templating system must, at the very minimum, match, if not exceed the ease of HTML. So the above is not very different, but when it grows larger, you can abstract away the repeated calls, make your own tags (as I show with the image and link-to "tags") that make the html more readable and vastly more DRY.

And again, it all goes out to nice html. Take that and import it into whatever framework you're headed off to.

I'm going to take the stance of: "I don't see the usefulness of it, but that doesn't mean it can't be useful." Maybe it's working within the limitations of a particular language that doing something like this is the best way. Maybe I'm completely missing some clear and obvious sign.

> The principle of lowest friction is that this templating system must, at the very minimum, match, if not exceed the ease of HTML.

Realizing also you mentioned as it grows larger, abstraction occurs, this is where I don't see the value. For anyone to use this templating system, they need to know HTML and then they need to know this templating system (which amounts to learning a programming language). Mistakes in the templating system will result in HTML errors. Maybe I've just had too many bad experience with systems like this where fixing the HTML would have been easy, except I had to go through a templating system that abstracted away critical parts.

I'll assume I'm just missing something, or I've had this problem your solving before, and solved it in some other way. Like I said, I don't see how this method benefits anything (and I've done my fair share of work on the web), but I'll chalk that up to a failing on my part to grasp some concept. =)

How have you lost? I write my HTML in a very similar way to the linked article, and I don't think I lose at all. In fact, I much prefer it.

It is more consistent. All of my code is now (in my case) Scheme. This makes it easier to change things as you don't have to go between two different languages. And it is simpler.

My favorite reason is the fact that I can use S-Exps. I no longer have to type the ending tag. I remove the possibility for spelling it wrong, or forgetting the slash. And it takes less space and is easier to get the placement correct, as you just utilize paren matching.

The paren matching really is key. I was blown away by how intuitive it is. Previously I had preferred haml, but without paren highlighting it can be hard to tell the depth you're working at relative to another tag.

This could be solved by some editor placing arrows showing which tags are parents to your current position, but I don't think that's available (at least not in emacs, sadly), and paren highlighting is.

Also, never missing a closed tag, mispellings, abstractions, etc. All very nice. When loading a broken page in chrome, it's crazy how much the html will be transformed, so that it's hard to tell why the page renders a certain way. A bit easier with this approach.

I agree. It looks really clean. I'm not about to throw out haml for it yet, but I'm definitely intrigued.

If you do it this way paredit works for html too :)

Which Scheme libraries/modules are you using?

I use Chicken Scheme with the Awful web framework. I also use the the Chicken Eggs: html-tags (sexp based HTML generation) and html-utils, along with many other supporting modules.

Care to elaborate at all? I'm not sure I understand. Would haml/erb fall under the same umbrella statement?

HTML is great, but there are a few areas where it's tough to do things, like abstracting repetitive elements. There are plenty of ways around this using other languages, and perhaps the best solution for someone like you would be writing html snippets and using javascript to replicate them, thus writing purely in html?

I edited the original post to explain, since I got several requests for that. But I did want to "reply" just to say I replied above. =)

Not true, the are advantages to programatically generated HTML using a mini language that simply can't be ignored. See http://seaside.st

I hope you're homophone trolling.

%ul#navbar.horizontal_list

Reply on news.ycombinator.com