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

131–140 of 256 posts

Re: The time is right for a DOM templating API

#131

Post by bapak »

mock-possum wrote: post #74
stevage wrote: post #68

What exactly is the problem with having the higher levels of web development supported through libraries (React, Vue etc) rather than directly in the browser? Why does this need to happen?

FTA, which I agree with: > Developers need to reach for a library, and thus tools like npm or a CDN, to do many basic things. This adds to the overhead of getting started. It makes simple static files and devtools less useful than they could be. There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default. Remember when you could just dr…

> It would be nice to get to do that again

The answer to this is both "never gonna happen" and "you already can."

You already can ship a React app in pure JS and even import modules via ESM in the browser from CDN. Performance will suck but you can.

You'll never be able to actually have a complex web app that you can just drag into the browser. As the base API expands, so do the ambitions.

Heck we've had PHP 4 years after HTML just to fill in some blanks, people will always want more than static code.

Re: The time is right for a DOM templating API

#132

Post by bapak »

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 don’t like React but I disagree with this sentiment. First of all you can already opt out of declarative DOM and knock yourself out with innerHTML and ref.

Second, what can you do with imperative control of the DOM that is less practical with the declarative one? I can only think of certain methods (attachShadow(), showModal()) but even then you're a 10-line component away from making it declarative.

Re: The time is right for a DOM templating API

#133

Post by nchmy »

nine_k wrote: post #88
tacticus wrote: post #59

Earlier quoted context omitted.

Was react ever about progress?

If you valued your sanity when developing complex Web UIs, React was a lifesaver. DOM sucks though, it's slow, it's heavyweight, it lacks transactions. We're stuck with it, and frameworks like React have to do the DOM diffing + patching thing, explicitly, in JS.

Nah.

https://svelte.dev/blog/virtual-dom-is-pure-overhead

https://news.ycombinator.com/item?id=43971164

Re: The time is right for a DOM templating API

#134

Post by ch_sm »

youngtaff wrote: post #126
youngtaff wrote: post #95

Earlier quoted context omitted.

React was a solution to a ten years ago problem

You can downvote it but it doesn’t make it any less true Alex Russell has written swathes of arguments about Reacts performance issues https://infrequently.org/2024/11/if-not-react-then-what/ The DOM has become much faster since React started over a decade ago, the VDOM really isn’t needed anymore even for app like experiences React is about developer preference over user experience

Agree that react isn’t the best implementation of the concept, both in terms of ergonomics and efficiency. But a react-like framework is still very much needed to create complex apps in the browser. So IMHO react is a solution to a very current problem, only not an ideal one.

Re: The time is right for a DOM templating API

#135

Post by jdkoeck »

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…

> Hard not to laugh out loud at "We know what good syntax for templating looks like."

First of all, it's not very nice to laugh in the face of someone advocating for progress on the web platform, which benefits everyone.

Second of all, yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been adapted for all kinds of frameworks, and it's undeniable that all js templating systems converged towards common attributes: templates-as-expressions, composition via nesting and control flow with just javascript (instead of specific template syntax).

Re: The time is right for a DOM templating API

#136

Post by 9rx »

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…

We do know what is good. We may not know what is perfect, but perfect need not be the enemy of good.

Re: The time is right for a DOM templating API

#137

Post by jraph »

troupo wrote: post #115
jraph wrote: post #102

Earlier quoted context omitted.

So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then? Genuinely asking, I have no clue what's being alluded to without being clearly mentioned in this thread.

> So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then? Array.from adds friction. The need to wrap querySelector in null checks adds friction. The fact that they are not composable in any way, shape, or form, with any DOM methods (and that DOM methods are not composable) adds friction. jQuery was the fore-runner of fluid interface design. Nothing in the DOM before, then, or si…

I agree that DOM lists not being real arrays is a pita. I can understand why for getElementBy* methods which return live lists, but it's less clear for those methods returning fixed lists.

But to me, these are minor inconveniences and habits. A thin wrapper can get you there easily if you care enough. I personally dislike this array/element confusion that jQuery adds.

Re: The time is right for a DOM templating API

#138

Post by EasyMark »

shermantanktop wrote: post #25

A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues. This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example. If a proposal like this…

Isn't that why you have versions and maintains backward compatibility with older versions, and don't change the "old" interfaces?

Re: The time is right for a DOM templating API

#139

Post by [deleted] »

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…

[deleted]
Post reply on HN