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

241–250 of 256 posts

Re: The time is right for a DOM templating API

#241

Post by throwitaway1123 »

JimDabell wrote: post #238
_benton wrote: post #229

Earlier quoted context omitted.

You can with DSD.

You can’t. At minimum you need to call customElements.define().

You absolutely can. It's the primary purpose of the DSD (Declarative Shadow DOM), one of the many new specifications people complain incessantly about.

  
    
      
        ::slotted(*) {
          font-weight: bold;
          font-family: sans-serif;
        }
      
      
    
    
content

Re: The time is right for a DOM templating API

#242

Post by throwitaway1123 »

JimDabell wrote: post #237
_benton wrote: post #219

Earlier quoted context omitted.

Im not sure what you're referring to, they seem pretty straightforward to me. Create a class that extends HTMLElement, implement stuff in connectedCallback and attributeChangedCallback. Return a list of attributes in static observedAttributes. Or use some extended class if you want, there are plenty and they're easy to create your own.

Let’s take this example: Example :host { display: block; font-family: system-ui; margin: auto; width: fit-content; } ::slotted(img) { border-radius: 1em; } Check out this cool dog! customElements.define( "cool-dog", class extends HTMLElement {}, ); First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if yo…

> First off, what’s with the pointless JavaScript? There’s no need for imperative code here.

Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, including the Shadow Root." [1]

[1] https://web.dev/articles/declarative-shadow-dom#how_to_build....

Re: The time is right for a DOM templating API

#243

Post by moritzwarhier »

taeric wrote: post #240
moritzwarhier wrote: post #234

Earlier quoted context omitted.

The badge on something is a good example for using absolute positioning exactly for what it's meant for imho. With "canvas-like approach", I meant this part of your comment (not the web technology): > Basically, my assertion used to be to draw out what you have in mind on grid paper. I guess we were talking past each other because you equate templates and designs, and I didn't think of this usage of the term (the pos…

Another poster was pointing out that this is not necessarily what is meant by templates in the post. I can see the distinction, but not really sure it changes my view. Since the post is largely more javascript literals for dom objects, it is hard for me not to bring that back to the design implications? Literally comes back to "people love JSX" many times. Why? Because it lets them get things to the presentation laye…

I'm not sure if I can contribute anything more here.

Tagged template literals, aka "template string literals" are yet another technology adjacent to JS and HTML using the word "template". But it doesn't have much to do with the submission.

It's just a fancy name for advanced string interpolation in JS, and has no inherent connection to DOM elements or fragments.

But it is used by some technologies such as styled-components and Lit (the web component library).

styled-components is probably also where the obfuscated CSS-in-JS class names in the bluesky markup originate.

There is also a `` element that is used by ShadowDOM and web components.

But nothing of that is the essence of the post, these are just things that coincidentally use the word "template" (and, less coincidentally, the concept).

As far as I see, it is about the wish to standardize declarative data-binding to DOM trees.

Basically, a React-like API built into the browser, but less detached from native rendering algorithms.

Re: The time is right for a DOM templating API

#244

Post by troupo »

_benton wrote: post #227
troupo wrote: post #225

Earlier quoted context omitted.

You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through) Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped…

I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?

Usually a new feature:

- doesn't require 20+ web specs

- doesn't forget and then scramble to fix the most basic expected functionality like form participation

- doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans

- hopefully doesn't take 15 years to barely do what others have been doing since time immemorial

Re: The time is right for a DOM templating API

#245

Post by troupo »

_benton wrote: post #228
troupo wrote: post #226

Earlier quoted context omitted.

After multiple specs had already been pushed through, they finally decided to write down a list of what is still needed. 22 items: https://w3c.github.io/webcomponents-cg/2022.html In those things like ARIA are not a single spec. It's now close to five different proposals and a huge ARIA Object Model proposal. Similar thing with Form Associated Controls: it's not one spec. It's a bunch of specs fixing idiotic issues l…

Right but what were these required specs for the existing implementation?

I couldn't parse your question

Re: The time is right for a DOM templating API

#246

Post by troupo »

throwitaway1123 wrote: post #242
JimDabell wrote: post #237

Earlier quoted context omitted.

Let’s take this example: Example :host { display: block; font-family: system-ui; margin: auto; width: fit-content; } ::slotted(img) { border-radius: 1em; } Check out this cool dog! customElements.define( "cool-dog", class extends HTMLElement {}, ); First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if yo…

> First off, what’s with the pointless JavaScript? There’s no need for imperative code here. Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, i…

> The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively.

It's a pipe dream that doesn't work in practice. Because on its own declarative shadow dom is useless.

Re: The time is right for a DOM templating API

#247

Post by throwitaway1123 »

troupo wrote: post #246
throwitaway1123 wrote: post #242

Earlier quoted context omitted.

> First off, what’s with the pointless JavaScript? There’s no need for imperative code here. Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, i…

> The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. It's a pipe dream that doesn't work in practice. Because on its own declarative shadow dom is useless.

You clearly have an axe to grind, and I'm not particularly interested in proselytizing. If you don't find the Declarative Shadow DOM useful, that's fine!

The example I was responding to was using the Declarative Shadow DOM. My comment was intended to point out the simple fact that the imperative component definition the author was complaining about is superfluous, meaning you can safely remove that entire script from the example.

Re: The time is right for a DOM templating API

#248

Post by yoz-y »

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

Earlier quoted context omitted.

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

Is anything preventing JS from compiling the proper stepwise dom access if the querySelector parameter is a literal? That would basically push the interpolation into the parsing step.

Re: The time is right for a DOM templating API

#249

Post by jdkoeck »

JimDabell wrote: post #239
jdkoeck wrote: post #236

Earlier quoted context omitted.

It’s good you ended on the one thing JSX got right: everything is an expression. It’s that simple. There’s nothing imperative about evaluating a template, it’s entirely covered by functional programming techniques. You’re just producing a value. And yes, modern JavaScript uses tons of concept from functional programming, where it is understood that mutating values and triggering side effects should be a last resort.…

> mutating values and triggering side effects should be a last resort. Output is a side-effect. > This is why a good js programmer uses ten times more maps then he uses for loops. This is a) massively overstating things, and b) not relevant to a case where zero for loops can be used. > Maybe you don’t know how dominant React is today? Two third of JavaScript developers use React at work I checked those figures before…

It’s not an insult, if you think for loops are commonplace in modern JavaScript and React isn’t the dominant frontend framework by far (twice more used than the next in line, vue), you’re out of touch, it’s just a statement.

How can you not realize that producing a string or a tree of elements is a purely functional operation? There’s no side effect here. Are you familiar with the concepts of functional programming?

Re: The time is right for a DOM templating API

#250

Post by _benton »

throwitaway1123 wrote: post #247
troupo wrote: post #246

Earlier quoted context omitted.

> The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. It's a pipe dream that doesn't work in practice. Because on its own declarative shadow dom is useless.

You clearly have an axe to grind, and I'm not particularly interested in proselytizing. If you don't find the Declarative Shadow DOM useful, that's fine! The example I was responding to was using the Declarative Shadow DOM. My comment was intended to point out the simple fact that the imperative component definition the author was complaining about is superfluous, meaning you can safely remove that entire script from…

I'm so fascinated by the few people online who show up to anything web component related just to flame and complain. It's always the same things too.

DSD is useful for SSRing web components, which allows them to render and work without JS. But honestly, I don't get the obsession with doing stuff without JS, it's part of the html/css/js trifecta.

Post reply on HN