Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The time is right for a DOM templating API

justinfagnani.com

Post reply on HN
Print view View original

181–190 of 256 posts

Re: The time is right for a DOM templating API

#181

Post by 9rx »

taeric wrote: post #179
9rx wrote: post #178

Earlier quoted context omitted.

I still consider the templating language I shared before, even at the time of this comment, to be good. But, as recognized earlier, others may find it doesn't hold up to today's standards. "Good" is not only not a constant, but is also subjective. Do I really have to explain the entire universe here? Man.

You didn't share a templating language, though? You shared an example of a formatting/templating string, but didn't even indicate what level of format string it supported. Such that I don't know if you are sharing C's printf, bash's printf, PHP's... I can presume you don't intend to include CL's FORMAT. Even if I do have a softspot for it, myself.

> You shared an example of a formatting/templating string

Which is, you guessed it, a language! Okay, yeah, I didn't dive in so deep as to provide a formal specification for the language, or whatever it is you were hoping for, but if you really want to take this to silly town, I'm going to tell you that what you saw is the only valid input for this language and only specify that, so, maybe, unless you are having fun with this comedy routine (in which case, carry on; I'm certainly still entertained!), you can read between the lines? The question asking if I need to explain the universe was rhetorical, implying that I am not going to do that.

Re: The time is right for a DOM templating API

#182

Post by MrJohz »

vlucas wrote: post #168

I like the spirit here, but I would argue we need a few lower level APIs built into browsers first instead. It will be near impossible to get everyone to agree on a standard template system. What the browser CAN do, however, is provide some lower level APIs on how to apply diffs to the DOM in a performant native way. I would LOVE for something like this to exist in browsers natively: element.applyDiff(DocumentFragmen…

The article does link to the DOM part proposal, which would be one useful low-level API. It wouldn't work so well for VDOM-based frameworks, but for other frameworks it could simplify how they work and provide additional room for optimisations. It would also be useful for projects without a framework, particularly if the signals proposal was also adopted.

Re: The time is right for a DOM templating API

#183

Post by moritzwarhier »

taeric wrote: post #143
moritzwarhier wrote: post #105

Earlier quoted context omitted.

> 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. How do you come to this conclusion? It seems to me that what you mean is a general gripe with HTML+CSS, not with how it's generated. And why do you bring up absolute positioning? I hear this take on HN a…

I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own. Basically, my assertion used to be to draw out…

But flex layout is fundamentally different from tables, I guess you meant grid with that reference?

It's not that every website uses CSS grid for layout.

Coincidentally, I took a look at the DOM+CSS of a bluesky post just a few days ago (very weird coincidence, since that was the first time I opned bluesky for months), and it did use old-school tricks like centering using CSS transforms, presumably because renders a tiny bit faster than flex centering, or avoids layout calculations when elements are added in a virtualized list.

Virtualized lists are also a good example for falling back to specifying exact pixel positions and dimensions for performance reasons, but these are usually determined with help of JS. I think the transform I saw was a translateX(-50%) one, so centering.

I totally get the canvas-like approach, but in a way the constraint-based flex layouts fall into the same line of thinking for me.

The issue with absolute positioning is the need to manually specify positions and dimensions for elements, which makes it useless unless you are working within a fixed box or only relating to the corners of one rectangle.

It is explicitly meant to remove elements from the normal layout flow so they overlap each other by default.

Re: The time is right for a DOM templating API

#184

Post by striking »

froh wrote: post #160
wahern wrote: post #39

Earlier quoted context omitted.

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

here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt. I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances. but that syntax... and of cou…

Why not implement a DSSSL-to-XSLT compiler?

Re: The time is right for a DOM templating API

#185

Post by PaulHoule »

wahern wrote: post #39
taeric wrote: post #34

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…

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

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.

Re: The time is right for a DOM templating API

#186

Post by PaulHoule »

nine_k wrote: post #84
notpushkin wrote: post #62

Earlier quoted context omitted.

I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day. I also have a simple playground for XSLT: https://xsltbin.ale.sh/

XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks. But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful a…

Homiconicity can get you into trouble.

CSS and HTML have a dual relationship. You could certainly write CSS with an XML-like syntax but people would always get confused at whether they are looking at style or markup. Because HTML and CSS look completely different you never have that problem.

XSLT shares the same problem with the RDF specs coming out at the same time that it hid the production rules/logical nature of the system, had it looked more like

   -> $x
it could have been quite different. But production rules never really sold (got told that by the marketing chief of vendor at a hotel bar after a conference they sponsored) and it's an interesting question why. They can do all kind of neat things like manage asynchronous processes that happen over a long period of time (like having a loan officer approve a loan) but nobody ever tried to use them to deal with the async comm problem in Javascript as far as I can tell.

Re: The time is right for a DOM templating API

#187

Post by PaulHoule »

agumonkey wrote: post #90
nine_k wrote: post #84

Earlier quoted context omitted.

XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks. But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful a…

I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.

In some sense that's a strength. When things can happen in any order you can mash together two things and they work together.

When I was looking for my own revolution in software engineering I saw one part of the low code/no code puzzle was that conventional tools force you to determine what order events happen which was something laymen shouldn't be bothered to do. Some counters are: spreadsheets (they figure out what order to calculate it), make (does a topological sort), dependency injection tools like Spring (writing a FactoryFactoryFactory isn't so bad, but maintaining it is a disaster when a "small" change means you have to reorder the order in which you construct everything)

There is a "freedom is slavery" problem here. People saw the semantic web as "you're going to exhaust yourself arguing with people about standards and ontologies before you even start coding" and not "if my data is properly namespace I can throw data from 10 different sources together into my RDF database and start writing queries".

Re: The time is right for a DOM templating API

#188

Post by troupo »

WorldMaker wrote: post #177
troupo wrote: post #115

Earlier quoted context omitted.

> So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then? Array.from adds friction. The need to wrap querySelector in null checks adds friction. The fact that they are not composable in any way, shape, or form, with any DOM methods (and that DOM methods are not composable) adds friction. jQuery was the fore-runner of fluid interface design. Nothing in the DOM before, then, or si…

You don't need Array.from if you are using `for (const x of document.querySelectorAll(selector) { }` loops anyway or have a library like IxJS handy. ES2025 added map, filter, flatMap, reduce, forEach, and several other methods to all iterators (including NodeList directly, I believe, but definitely its entries(), keys(), values(), if not) [1]. It'll be a year or two at current pace before that is "widely accepted bas…

> including NodeList directly, I believe,

I listed all public methods and properties of NodeList. It does have a forEach, so there's not much need for `for of`

As for iterator methods, I completely forgot about that :) Yeah, you can/will be able to use them on .entries()

Re: The time is right for a DOM templating API

#189

Post by PaulHoule »

Mikhail_Edoshin wrote: post #155
wahern wrote: post #39

Earlier quoted context omitted.

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

XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse. The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on…

I thought Tim Bray's XML spec was one of the most beautiful tech documents I'd every seen when I saw it for the first time. Adding namespaces at that point in history though was a disaster. Back then developers just weren't used to that kind of rigor (when I first started coding Java I had to go to a website run by frickin' NASA to get a clear explanation of how namespaces worked.)

It didn't help that Microsoft dropped a stick of over-complicated standards that tried to bring RPC into XML. RPC has always been a cursed concept because between (1) trying to be intellectually coherent and (2) caring about performance RPC systems become incomprehensible and it doesn't matter if it is Sun RPC, DCOM, CORBA, "Web Services", Protocol Buffers, etc.

The fact that the "REST economy" is intellectually incoherent and could care less about performance seems to have helped it succeed. Right now I just wrote a javascript function that looks like

   const get_item = async (item_id) => {...}
and it does

   GET /item/{item_id}
and I have a Java function on the server that looks like

   Item getItem(String item_id)
and is tagged with some annotations that make it get called when that GET request. Jackson lets me write an Item as an "anemic domain object" that gets turned into the exact JSON I want and the only real complaint I have is that the primitive types are anemic so representing dates is a hassle.

Re: The time is right for a DOM templating API

#190

Post by ASalazarMX »

nwienert wrote: post #30
pier25 wrote: post #17

The web really needs native templating, reactivity, and data binding. I can't even begin to imagine how much CPU and bandwidth is wasted with billions of users downloading, parsing, and executing something like React.

React isn’t templating though.

Respect for focusing on semantics but not contesting the CPU and bandwidth waste. That takes honesty.
Post reply on HN