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

61–70 of 256 posts

Re: The time is right for a DOM templating API

#61

Post by ethan_smith »

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

A native virtual DOM implementation would also drastically reduce memory overhead since browser engines could optimize diffing algorithms at the C++ level instead of requiring megabytes of JavaScript framework code to be downloaded, parsed and executed on every page load.

Re: The time is right for a DOM templating API

#62

Post by notpushkin »

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…

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/

Re: The time is right for a DOM templating API

#64

Post by bevr1337 »

MrJohz wrote: post #40
bevr1337 wrote: post #35

Earlier quoted context omitted.

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

And then some. Switching to react-native or other render targets can also be a doozy. Hopefully the references clarify all the features.

Re: The time is right for a DOM templating API

#65

Post by marcosdumay »

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…

XSLT is just not a good language. Every single attempt of making XML executables (and there were many) failed badly, always for this one good reason.

Re: The time is right for a DOM templating API

#66

Post by upghost »

Is there anyone else who feels kinda like declarative templating is actually kind of worse than jQuery? Don't get me wrong, I've been using React for nearly a decade. But the more complex my SPAs become, the more I wish I had imperative control of the DOM.

I think the reason is because the DOM is a leaky abstraction and at some level I would just prefer last write wins.

I realize declarative templating is supposed to handle that, but this starts to break down really quickly when you share mutable state between components.

Re: The time is right for a DOM templating API

#67

Post by parhamn »

upghost wrote: post #66

Is there anyone else who feels kinda like declarative templating is actually kind of worse than jQuery? Don't get me wrong, I've been using React for nearly a decade. But the more complex my SPAs become, the more I wish I had imperative control of the DOM. I think the reason is because the DOM is a leaky abstraction and at some level I would just prefer last write wins. I realize declarative templating is supposed to…

I think part of this is React folks think its a cardinal sin to invoke the dom apis directly. Sometimes it's just fine to capture a ref (and dare I say, query a component by a id) and do the work directly. In fact this is what most libraries that are "fast" and low-rerenders do (like the form ones).
Post reply on HN