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

201–210 of 256 posts

Re: The time is right for a DOM templating API

#201

Post by WorldMaker »

troupo wrote: post #197
WorldMaker wrote: post #196

Earlier quoted context omitted.

You missed [Symbol.iterator] as a public method. I prefer the aesthetics of for/of over forEach in most cases, but it's as much personal preference as anything. I did briefly forget the distinction between Iterable (has [Symbol.iterator]) and Iterator (the thing [Symbol.iterator]() returns). You can use the Iterator helpers "directly" on the NodeList with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(som…

> with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(someNodeList).map(…)` I always feel like clawing my eyes out with most of the DOM APIs, or workarounds for them :)

[Symbol.iterator] is more the for/of API (protocol, more accurately) than a DOM API. It's an improvement today that the DOM APIs pick up niceties like direct [Symbol.iterator] in addition to Iterator methods like entries().

It's nice that there is syntax sugar for [Symbol.iterator] in both for/of and also the spread operator/deconstruction/rest operator (things like [...someNodeList] and const [item1, item2, ...rest] = nodeList).

In theory, the only missing piece is syntax sugar for Iterator.from() if you wanted to direct chain any iterable to the iterator helperrs. But in practice, that's also part of why the explicit iterator methods like entries() already exist and those are surprisingly well implemented (and have been for a while), including on NodeList.

Re: The time is right for a DOM templating API

#202

Post by ivape »

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.

Two way data binding and a jsx clone is kind of all anyone really needs.

Re: The time is right for a DOM templating API

#203

Post by yoz-y »

codedokode wrote: post #195

The web platform is over bloated. The proper solution would be a minimum set of APIs and set of reusable by many sites JS/Wasm libraries. For example, most of Web Audio (thing like filters and oscillators except for actually sending audio to audio card) could be implemented in Wasm making a browser simpler and not allowing to use it for fingerprinting. Also, base64 encoding/decoding, URL handling function, most of ca…

I think web needs an “actually standard” library. Something that vendors could ship with browsers but could be also updated to higher version of a site requires it (and cached forever).

That would allow us to not download a bunch of code every time.

Re: The time is right for a DOM templating API

#204

Post by ivape »

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.

That's kind of like saying React isn't just a bunch of a functions (it is). What do the JSX templates compile down to?

Re: The time is right for a DOM templating API

#205

Post by yoz-y »

troupo wrote: post #97
mock-possum wrote: post #71

Earlier quoted context omitted.

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.

It’s similar enough to html that anybody familiar with html and JS can pick it up. Quirks it has, but I like that using it mostly just feels like building a huge html string.

Re: The time is right for a DOM templating API

#206

Post by yoz-y »

austin-cheney wrote: post #72

DOM templating is just like JavaScript classes. Classes in JavaScript were requested since the earliest of times and always rejected until ES6 (2014), because they are/were: * always unnecessary * always artificial * only vanity * only desired by insecure persons not familiar in the technology * only qualified as bad idea but necessary because people were just going to do it anyways So far the DOM has managed to esca…

I’m curious. What is actually wrong with querySelector?

Re: The time is right for a DOM templating API

#207

Post by troupo »

yoz-y wrote: post #205
troupo wrote: post #97

Earlier quoted context omitted.

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

It’s similar enough to html that anybody familiar with html and JS can pick it up. Quirks it has, but I like that using it mostly just feels like building a huge html string.

> It’s similar enough to html that

"Similar enough" is a far cry from "It’s just html, in strings, in JavaScript"

> anybody familiar with html and JS can pick it up

Just like JSX. But no one calls JSX "just HTML" (and in React, with rules of hooks, it's no longer "just JS"). In Solid JSX returns actual DOM nodes btw.

> it mostly just feels like building a huge html string.

Because that's what you essentially do. lit runtime parses your custom string, converts it to proper HTML, concatenates that into a string, and then dumps into the document with innerHTML (it does set up data bindings etc. , so it's more than just thay of course)

Re: The time is right for a DOM templating API

#208

Post by tshaddox »

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…

I'd also argue that there are only superficial similarities between, say, React and Svelte. Yes, they both have a syntax based heavily on HTML, but they work very differently. React is the only major framework that works by having (mostly) normal JavaScript functions return lazy representations of markup (in the form of JSX). React has no template-level notion of looping or conditional rendering, because you use normal JavaScript for that.

Re: The time is right for a DOM templating API

#209

Post by austin-cheney »

yoz-y wrote: post #206
austin-cheney wrote: post #72

DOM templating is just like JavaScript classes. Classes in JavaScript were requested since the earliest of times and always rejected until ES6 (2014), because they are/were: * always unnecessary * always artificial * only vanity * only desired by insecure persons not familiar in the technology * only qualified as bad idea but necessary because people were just going to do it anyways So far the DOM has managed to esca…

I’m curious. What is actually wrong with querySelector?

String interpolation is so ridiculously slow. Epic slow.

Perhaps just as importantly is that is a crutch for many to avoid accessing the DOM in steps. You can read from the DOM with querySelectors but you cannot modify the DOM with them. If querySelectors is all you can do then you must use some third party template system because you have no idea how any of this works even though it provides maximal expressive freedom.

Re: The time is right for a DOM templating API

#210

Post by hsn915 »

WickyNilliams wrote: post #107
hsn915 wrote: post #104

Earlier quoted context omitted.

The linked proposal has many "features" that would be "needed" if you frame the problem in terms of a "template api", centered around "binding" variables, and what not. https://github.com/WICG/webcomponents/issues/1069 My proposal only adds one native function with nothing else: no new data types, no new apis.

Doesn't your proposal implicitly introduce the concept of a virtual DOM, which the browser does not have? You'd need to spec out what that looks like. It adds one new API from the users perspective but much more from the browsers perspective. Additionally the next generation of Frameworks do not use virtual DOM. Solid and svelte do not. Vue is moving away from it. Signals are directionally where they're all heading.

The API surface I propose only includes one function. No type needed.

It does not even require the target node to be created with a virtual dom in the first place. Just diff the node with the given tree structure efficiently.

Internally the browser might need to create a few accelerator data structures, but that's an implementation detail.

Post reply on HN