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

91–100 of 256 posts

Re: The time is right for a DOM templating API

#91

Post by nine_k »

silverwind wrote: post #85
hsn915 wrote: post #31

What we need is not templating. What we need is a native implementation of a virtual dom. More specifically, a native implementation of the "patch" function: patch(target_dom_node, virtual_dom) Where `virtual_dom` is just a plain-data description of the DOM. Most of the "slowness" of the DOM come from its requirement to be a 90's era Java style object hierarchy. Don't call it "templating". Just call it "virtual dom".…

Virtual DOM is a useless abstraction, there are numerous libs that perform fine without it.

It's a useful abstraction: you just build the full DOM with every change, a bit like a game engine. It makes so many things simpler.

It's not a free abstraction though.

Re: The time is right for a DOM templating API

#93

Post by nine_k »

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.

It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(

Re: The time is right for a DOM templating API

#94

Post by agumonkey »

nine_k wrote: post #93
agumonkey wrote: post #90

Earlier quoted context omitted.

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.

It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(

The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)

Re: The time is right for a DOM templating API

#95

Post by youngtaff »

nine_k wrote: post #88
tacticus wrote: post #59

Earlier quoted context omitted.

Was react ever about progress?

If you valued your sanity when developing complex Web UIs, React was a lifesaver. DOM sucks though, it's slow, it's heavyweight, it lacks transactions. We're stuck with it, and frameworks like React have to do the DOM diffing + patching thing, explicitly, in JS.

React was a solution to a ten years ago problem

Re: The time is right for a DOM templating API

#96

Post by troupo »

jlukic wrote: post #73

It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.

> It’s worth noting this was written by

by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing.

Safari argued that there should be a declarative ways for this 15 years ago

Re: The time is right for a DOM templating API

#97

Post by troupo »

mock-possum wrote: post #71
rs186 wrote: post #10

The author was a core contributor of Google's Lit project: https://github.com/lit/lit

Lit my beloved God I love lithtml’s tagged template literals so much more than react’s JSX or Vue’s 3-in-one thing. It’s just html, in strings, in JavaScript. Lit is just a way to make custom elements easier. Man it’s gonna suck when I have to move on from my current gig and get my hands dirty with react again.

> It’s just html, in strings, in JavaScript.

It's not. It's a custom HTML-like syntax with lots of custom and weird rules.

Re: The time is right for a DOM templating API

#98

Post by troupo »

jraph wrote: post #83
eszed wrote: post #29

Earlier quoted context omitted.

From bevr1337's comment, above: > its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes That's what I miss about it.

Doesn't querySelector(All) provide this?

Not entirely. There's a reason people do Array.from(querySelectorAll) to do more than just `forEach`

Re: The time is right for a DOM templating API

#99

Post by dominicrose »

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…

We don't know what good syntax for templating looks like because HTML is complex enough and many have tried making it more complex with things like Blade for PHP or HTMX for example. For some reason I've always preferred JS to HTML. React components with JSX is a good balance. Not everyone agrees but that's OK.

Re: The time is right for a DOM templating API

#100

Post by bryanrasmussen »

quotemstr wrote: post #54
shermantanktop wrote: post #25

A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues. This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example. If a proposal like this…

> A basic lesson we've learned over and over is that API/ABIs aren't final I dunno --- getElementById has been stable for, what, 25 years? "There's no such thing as a stable API" is something said by people unable or unwilling to create interfaces that last. It's a statement of personal resignation, not cosmic impossibility. There are tons of counterexamples. Application needs, like other needs, are infinite. You sat…

I think you'll find that even the most unstable APIs have extremely stable parts to them.

At the same time I don't think there is actually anything that most people would consider an API that is open to public usage that has maintained that kind of stability that getElementById has, which after all is something most people would describe as a method of an API.

Post reply on HN