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

31–40 of 256 posts

Re: The time is right for a DOM templating API

#31

Post by hsn915 »

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". Everyone knows what that means.

Re: The time is right for a DOM templating API

#32

Post by nwienert »

rictic wrote: post #21
quantadev wrote: post #6

Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way. In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course). There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ b…

The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.

I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.

I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.

Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).

Re: The time is right for a DOM templating API

#33

Post by krebby »

ericyd wrote: post #22

> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element. I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?

I think this is referring to the fact that React uses synthetic event listeners - it's cheaper to bind an event listener once at the root and do your own element matching than it is to continuously bind and unbind listeners.

https://react.dev/reference/react-dom/components/common#reac...

Re: The time is right for a DOM templating API

#34

Post by taeric »

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?

Re: The time is right for a DOM templating API

#35

Post by bevr1337 »

ericyd wrote: post #22

> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element. I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?

> React doesn't provide a way to explicitly bind to properties and events of DOM elements

We can nitpick this point because react has had a ref API for at least 5 years now. Given a ref, all DOM API are available. For events, SyntheticEvent will refer to a native event if it exists.

The SyntheticEvent abstracts vendor discrepancy. Under the hood, react can apply some optimization too.

https://legacy.reactjs.org/docs/events.html https://react.dev/reference/react-dom/components/common#reac...

Re: The time is right for a DOM templating API

#36

Post by quantadev »

Gualdrapo wrote: post #8
quantadev wrote: post #6

Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way. In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course). There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ b…

"If I could wave my magic wand..." at least 2 of 3 of the changes I'd made about the way frontend web is developed, would be about ` `s: 1. Making it possible to do something like and being able to load them from an external source 2. Making them "dynamic" 3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.

As a web dev you probably already know but #1 is slightly similar to `Web Components` but you're right we cannot load a web component right in the HTML where we use it. It makes sense though because if you use an Element in multiple places it wouldn't make sense to have 'src' in multiple places, so ultimately some kind of 'loading' at the top of the page is needed, and that's how WebComponents work, but I still like how you think.

#3 is a tricky one syntactically because HTML needs to be used by mere mortals and JS is a programming language used by us gods, so unifying all three would br tricky, but again I agree with you that would be awesome. Maybe some flavor of LISP would be both "powerful like a language" and "easy like a document".

Re: The time is right for a DOM templating API

#37

Post by Nextgrid »

sabellito wrote: post #24
mosdl wrote: post #9

I miss mozilla's XUL language (and XBL!), those were awesome.

My company, me as a solo dev, back in 2003-04 built a "single page app" using XUL and iframes. Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window. XUL was beastly back then though.

> Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window.

Out of curiosity, what does that app do to convince people to jump through such hoops? Would you mind sending a link to it?

Re: The time is right for a DOM templating API

#38

Post by quantadev »

nwienert wrote: post #32
rictic wrote: post #21

Earlier quoted context omitted.

The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.

I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing. I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popula…

I still have hope for Web Components to take off in the figure. I'm a React dev so I don't "need" them, but they may end up being some kind of capability that React can secretly, quietly embed into React core as some kind of optimization if that ever makes sense. Web Components is a great idea, but like I said it's just not quite as convenient as React, so it's currently somewhat irrelevant at least for me.

Re: The time is right for a DOM templating API

#39

Post by wahern »

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

Re: The time is right for a DOM templating API

#40

Post by MrJohz »

bevr1337 wrote: post #35
ericyd wrote: post #22

> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element. I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?

> React doesn't provide a way to explicitly bind to properties and events of DOM elements We can nitpick this point because react has had a ref API for at least 5 years now. Given a ref, all DOM API are available. For events, SyntheticEvent will refer to a native event if it exists. The SyntheticEvent abstracts vendor discrepancy. Under the hood, react can apply some optimization too. https://legacy.reactjs.org/docs/…

The synthetic event also adds its own abstractions though. For example, the `onChange` handler in React behaves very differently to the native DOM `change` event.
Post reply on HN