Live data from Hacker News

The time is right for a DOM templating API

justinfagnani.com

231–240 of 256 posts

Re: The time is right for a DOM templating API

#231

If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed. There has been long running complaints about how many UI frameworks there are, and how often they change. It's settled down some, but I don't expect that situation to change for a long while.

> If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed

Not related to the templating thing but I have the impression we are witnessing the last React big change with RSC. This change made them lose a good % of developers, a next one would kill it.

Re: The time is right for a DOM templating API

#233
post #39
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…

Its annoying that support stopped at earlier versions, it grew so much more later.

Re: The time is right for a DOM templating API

#234
post #191

Earlier quoted context omitted.

But flex layout is fundamentally different from tables, I guess you meant grid with that reference? It's not that every website uses CSS grid for layout. Coincidentally, I took a look at the DOM+CSS of a bluesky post just a few days ago (very weird coincidence, since that was the first time I opned bluesky for months), and it did use old-school tricks like centering using CSS transforms, presumably because renders a…

I did mean grid, there. And don't get me wrong, I don't necessarily want everything absolute positioned. I just find it amusing when people try to get a badge or some such on something and then herculean efforts they will go through to get that badge exactly where they want it. So, with bluesky, the amount of markup that goes into the footer menu of each post would be what I'm looking at. Tools were clearly used to g…

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 post also is not about this).

Templating is not necessarily for full pages always, that defeats the purpose of templating languages in the first place to me.

> Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements.

Agree. And using modern CSS is a great way to reduce the number of "div"s.

> But I am curious on why so many nested divs seem to be needed all of the time.

I fought many these battles in my jobs, and often it's just for flexibility, because different components are written in a modular fashion. Minimizing the DOM tree size is my goal too, but often the version with less nesting requires a bit more thinking and breaks more easily when elements are added or changed.

CSS gris vs nesting flex containers is a great example for that.

Other times it's just laziness / people don't care.

Re: The time is right for a DOM templating API

#235

Earlier quoted context omitted.

JSX is as much a new language as Vue’s templating. JSX extends JavaScript syntax; Vue extends HTML syntax. If you’re working on generating markup, it makes more sense to do that at the markup level than constantly switch between markup and imperative JavaScript. It might use JavaScript for control flow, but does it really count when it uses it in a way that is not idiomatic at all? It’s not idiomatic JavaScript to us…

The difference is that JSX is using control flow from an actual programming language, whereas Vue is shoehorning control flow into declarative markup. This is the single reason React won the frontend framework market: they got the templating right. PS: in modern JavaScript, using map rather than for loops is more idiomatic!

> This is the single reason React won the frontend framework market

Don’t be silly, the front-end landscape is a lot richer than you make it out to be. React hasn’t “won”, the last time there was a clear winner in front-end, it was jQuery.

> PS: in modern JavaScript, using map rather than for loops is more idiomatic!

No, it’s not, and this is exactly what I was talking about. for loops and map() serve distinct purposes.

for iterates through a series of elements.

map() transforms a series of elements.

It’s possible to use them both for the same things, but there is a very clear semantic difference between them. One doesn’t replace the other, they mean different things.

In the context of “I have a bunch of elements I want to iterate over and output”, what you want is a for loop. The reason why React devs have been convinced map() replaces for loops is that React has to force you into making everything an expression, so instead of writing for when it’s appropriate and map() when it’s appropriate, they have to write map() everywhere.

Re: The time is right for a DOM templating API

#236

Earlier quoted context omitted.

The difference is that JSX is using control flow from an actual programming language, whereas Vue is shoehorning control flow into declarative markup. This is the single reason React won the frontend framework market: they got the templating right. PS: in modern JavaScript, using map rather than for loops is more idiomatic!

> This is the single reason React won the frontend framework market Don’t be silly, the front-end landscape is a lot richer than you make it out to be. React hasn’t “won”, the last time there was a clear winner in front-end, it was jQuery. > PS: in modern JavaScript, using map rather than for loops is more idiomatic! No, it’s not, and this is exactly what I was talking about. for loops and map() serve distinct purpos…

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. This is why a good js programmer uses ten times more maps then he uses for loops.

Maybe you don’t know how dominant React is today? Two third of JavaScript developers use React at work (https://2024.stateofjs.com/en-US/libraries/front-end-framewo...).

It feels like you’re out of touch, have you used JavaScript lately?

Re: The time is right for a DOM templating API

#237

Earlier quoted context omitted.

Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to. My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make brow…

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 you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual.

Now, I’ve noticed that since the text is a caption for the image, I should actually use and . So let’s do that:

    
    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 {},
        );
    
Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that?

It’s because web components can’t style anything other than their direct children. You can style the when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an in a to associate it with a .

What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one:

    
    Example
    
        img {
            border-radius: var(--border-radius);
        }
    
    
        
            
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                    --border-radius: 1em;
                }
            
            
        
        
            
            Check out this cool dog!
        
    
    
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    
Now let’s say I want to put a second element on the page. What does that look like? You define the template once and then just use a bunch of times? That would be the obvious thing to do, right? Since it’s a template?

Nope. Every instance of the web component needs its own . The best you can do is write some JavaScript to copy the template into each one.

The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.

Re: The time is right for a DOM templating API

#238

Earlier quoted context omitted.

It should have been possible to declare and use simple web-components - which use a template and a CSS class - without any Javascript.

You can with DSD.

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

Re: The time is right for a DOM templating API

#239

Earlier quoted context omitted.

> This is the single reason React won the frontend framework market Don’t be silly, the front-end landscape is a lot richer than you make it out to be. React hasn’t “won”, the last time there was a clear winner in front-end, it was jQuery. > PS: in modern JavaScript, using map rather than for loops is more idiomatic! No, it’s not, and this is exactly what I was talking about. for loops and map() serve distinct purpos…

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 I posted that comment to double-check my memory. Two thirds is not anywhere close to “React won the market”. Android has ~72% global market share, but I’m sure you wouldn’t say that Android has won the smartphone market.

> It feels like you’re out of touch, have you used JavaScript lately?

We disagree, that doesn’t mean I’m out of touch. Try not to be so insulting.

Re: The time is right for a DOM templating API

#240
post #191

Earlier quoted context omitted.

I did mean grid, there. And don't get me wrong, I don't necessarily want everything absolute positioned. I just find it amusing when people try to get a badge or some such on something and then herculean efforts they will go through to get that badge exactly where they want it. So, with bluesky, the amount of markup that goes into the footer menu of each post would be what I'm looking at. Tools were clearly used to g…

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 layer that is their browser.

I took some time to dive into how extensive JavaScript has made the word template in their world. I confess it reads a bit excessive to me. More than a bit, really. Tagged templates, in particular, look like one of the biggest foot guns I've ever seen.

I took it to design because I don't know of any other real reason to template the DOM other than for design purposes. Indeed, reading on the linked proposal, this is to make reactive things on a page. And that will have to be married to a design at some point. Often the entire point of introducing names that are exported from data to a rendered document is for the presentation implications of it. Otherwise, you'd just output the data?

Post reply on HN