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

251–256 of 256 posts

Re: The time is right for a DOM templating API

#251

Post by JimDabell »

jdkoeck wrote: post #249
JimDabell wrote: post #239

Earlier quoted context omitted.

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

You are being insulting because every time we disagree, you ignore half of what I am saying to assume I don’t know what I am talking about. Two informed people can disagree but you don’t seem to get that. A conversation is not a competition where one person gets to prove the other person is ignorant.

Take “React winning”. We disagree that React won because I don’t think 66% of a market is “won”. But you jumped to the conclusion that I just didn’t know what I was talking about. Then I clarified that the difference in our opinion is not the knowledge of the market share but our judgment of it, and I gave the example of Android not having “won” the smartphone market with ~72% of the market… and you just ignored that and doubled down on calling me out of touch.

Take the use of map(). I am very clearly distinguishing between common usage and defined semantics. The gap between the two was what I was complaining about. But you ignored what I was saying and decided that I don’t know map() is used a lot in modern JavaScript, when that was the core of my complaint!

And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.

Your approach to disagreeing with me is to ignore half the things I say so that you can attack me for being clueless. You need to do better.

Re: The time is right for a DOM templating API

#252

Post by jdkoeck »

JimDabell wrote: post #251
jdkoeck wrote: post #249

Earlier quoted context omitted.

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?

You are being insulting because every time we disagree, you ignore half of what I am saying to assume I don’t know what I am talking about. Two informed people can disagree but you don’t seem to get that. A conversation is not a competition where one person gets to prove the other person is ignorant. Take “React winning”. We disagree that React won because I don’t think 66% of a market is “won”. But you jumped to the…

I still think you’re misunderstanding what React is optimizing for. When you say "React has to force you into making everything an expression", you’re describing its core philosophy, not a constraint. JSX is built around the idea that rendering is just data transformation. It's UI as a function of state. That’s why using map() is idiomatic here. You’re building trees, not iterating imperatively.

Also, it bears repeating that React isn’t just slightly dominant. 82% of JS developers have used it according to the 2024 State of JS survey, and for good reason. It shaped the modern frontend mindset in a way that Vue or Angular haven’t, despite their own merits. For instance, many frameworks came up with their own version of hooks. It's telling that most new frontend frameworks are aiming for the "better React" position.

I realize we just have different interpretations of what "winning" means in a fragmented ecosystem, but it’s worth acknowledging how much React has set the tone for modern web development. UI as a function of state (and using map() a lot...) is here to stay.

Re: The time is right for a DOM templating API

#253

Post by taeric »

moritzwarhier wrote: post #243
taeric wrote: post #240

Earlier quoted context omitted.

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

I only mentioned tagged template literals, as they were called out by the article as an unsung hero. Presumably, they are an example of what a good template language looks like. If so, they don't give me hope that we know what a good template language looks like.

The idea of the post seems to be encapsulated in the web components issue and discussion. Agreed that it looks largely about data binding to DOM trees. To paraphrase you, "seems like advanced DOM interpolation in JS." Which, I just can't bring myself to agree that this looks good. Happy to be proven wrong in time.

Re: The time is right for a DOM templating API

#254

Post by nitwit005 »

owebmaster wrote: post #231
nitwit005 wrote: post #45

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.

Go to the what's new page for a react release, and there's quite a bit, with minor releases then adding to that: https://react.dev/blog/2024/12/05/react-19#whats-new-in-reac...

After several releases, it's a lot.

Re: The time is right for a DOM templating API

#255

Post by strbean »

JimDabell wrote: post #251
jdkoeck wrote: post #249

Earlier quoted context omitted.

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?

You are being insulting because every time we disagree, you ignore half of what I am saying to assume I don’t know what I am talking about. Two informed people can disagree but you don’t seem to get that. A conversation is not a competition where one person gets to prove the other person is ignorant. Take “React winning”. We disagree that React won because I don’t think 66% of a market is “won”. But you jumped to the…

> And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.

I think you're wrong here. The point at which the rendered template is actually stuffed into the DOM (and hence the screen) is I/O, sure. But the creating / rendering of the template is a pure function, which is what we are dealing with here.

Re: The time is right for a DOM templating API

#256

Post by nwienert »

ivape wrote: post #204
nwienert wrote: post #30

Earlier quoted context omitted.

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?

Missed this but - there’s a very meaningful difference between templates and React at least how most people think of templates.

React lets you return dynamic tree structures and insert code anywhere inline in that structure. Most templates explicitly don’t allow that for good reason. Further, most but not all templating frameworks have special syntax for conditional logic and loops.

If JSX is templating then templating has no meaning. Would createElement() be a template? In that case all functional programming is.

Post reply on HN