←back to thread

The time is right for a DOM templating API

(justinfagnani.com)
218 points mdhb | 1 comments | 26 Jun 25 19:23 UTC | HN request time: 0s | source
Show context
taeric ◴[26 Jun 25 23:50 UTC] No.44392596[source]▶
Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop.

Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is inevitable that someone will want to template something that isn't well formed, but can combine into a well formed thing. And then you are stuck trying to find how to do it. (Or correlated entities on a page that are linked, but not on the same tree, as it were. Think "label" and "for" as an easy example in plain markup.)

If I could wave my magic wand, what we need is fewer attempts to make templates all fit in with the rube goldberg that is the standard document layout for markup. People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well. Sure, you might have to do math to get things to fit, but why do we feel that is something that we have to force the machine to do again and again and again on the same data?

replies(9): >>44392668 #>>44394054 #>>44394866 #>>44395165 #>>44395166 #>>44396349 #>>44396377 #>>44396559 #>>44400705 #
wahern ◴[27 Jun 25 00:07 UTC] No.44392668[source]▶
> Also hard not to feel like this is reaching hard to try and recreate xslt.

I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT.

I think where XSLT fell over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.

replies(10): >>44392743 #>>44393457 #>>44393524 #>>44393568 #>>44394220 #>>44396687 #>>44397104 #>>44397246 #>>44398865 #>>44403888 #
1. PaulHoule ◴[27 Jun 25 17:59 UTC] No.44398865[source]▶
The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering.

I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't.

I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.