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.

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

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.

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.

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?