Live data from Hacker News

The time is right for a DOM templating API

justinfagnani.com

21–30 of 256 posts

Re: The time is right for a DOM templating API

#21

Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way. In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course). There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ b…

The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.

Re: The time is right for a DOM templating API

#22
> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element.

I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?

Re: The time is right for a DOM templating API

#23
post #14

Earlier quoted context omitted.

I <3 jQuery but, no.

What no? Why can't we have nice things, like concise, easy to remember, not overly elaborate syntax?

jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?

Re: The time is right for a DOM templating API

#24
post #9

I miss mozilla's XUL language (and XBL!), those were awesome.

My company, me as a solo dev, back in 2003-04 built a "single page app" using XUL and iframes. Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window.

XUL was beastly back then though.

Re: The time is right for a DOM templating API

#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 succeeds, it lives a time in the sun, but then spends most of its useful life being the old thing that people are trying to work around, just like the DOM API, just like ECMA versions, just like old browsers, just like every other useful bit of tech that is part of the system but can't be touched.

Is it possible to think about entropy, extension and backcompat as primary use cases?

Re: The time is right for a DOM templating API

#26
Yes, it's weird that Browsers were so fast to ship CSP rules to prevent XSS attacks by limiting the use of inline scripts but so slow to ship a templating mechanism which would largely solve the problem.

It's like creating regulations which require a specific solution before that solution exists.

Re: The time is right for a DOM templating API

#29

Earlier quoted context omitted.

What no? Why can't we have nice things, like concise, easy to remember, not overly elaborate syntax?

jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?

From bevr1337's comment, above:

> its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes

That's what I miss about it.

Re: The time is right for a DOM templating API

#30
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.
Post reply on HN