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

41–50 of 256 posts

Re: The time is right for a DOM templating API

#41

Post by wpm »

wahern wrote: post #39
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…

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

I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.

Re: The time is right for a DOM templating API

#44

Post by sabellito »

Nextgrid wrote: post #37
sabellito wrote: post #24

Earlier quoted context omitted.

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.

> 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. Out of curiosity, what does that app do to convince people to jump through such hoops? Would you mind sending a link to it?

It's a full management app for recruiting companies.

There are still 3 companies that use it (since 2008), so their employees don't have a choice really. The app does a lot, so to stop using it the companies would need to hire and migrate to 3-4 other services. I reckon SAP and the kind could do everything as well, but these companies are too small for that.

There isn't a website or anything anymore for me to show, and I haven't been involved in it for over 10 years.

Re: The time is right for a DOM templating API

#45

Post by nitwit005 »

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.

Re: The time is right for a DOM templating API

#46

Post by strix_varius »

pier25 wrote: 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.

With the TC39 signals proposal, part of that is making progress.

Re: The time is right for a DOM templating API

#48

Post by CharlieDigital »

strix_varius wrote: post #46
pier25 wrote: 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.

With the TC39 signals proposal, part of that is making progress.

Except React.....

Re: The time is right for a DOM templating API

#49

Post by d--b »

The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible.

I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one.

But these abstractions have a huge mental / implementation cost.

The problem, as with most engineering things is a tradeoff problem. The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.

Most apps out there don’t need to be crazy fast, and people will choose react because it’s just simpler.

But signals don’t really have anything to do with templating, do they? So why do we have to choose, could we have templating and signals as separate things?

Well OP thought about templating and realized you do need a way to tell the dom how to fit your templated node where it belongs and update it when things change.

And this is where these proposals fail. There needs to be a choice here. The API must pick a side (well technically it could allow for both, but ugh), and developers won’t ever agree which side it should go.

The big problem of UIs has always been how they update, not how they’re defined. Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not, all of them were painful AF. Then imgui come and say, well what if UIs didn’t have state at all. Ooh this is nice, but kind of hard on the cpu, so what do we do?

Well, perhaps one of the biggest reason for the success of web apps is in fact that the dom didn’t impose a way to bind data to its view. And so we may be doomed to framework hell.

Re: The time is right for a DOM templating API

#50

Post by dragonwriter »

d--b wrote: post #49

The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible. I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one. But these abstractions have a huge mental / implementation cost. The problem, as with most engineering things is a tradeoff problem. The r…

> Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not,

Microsoft used those at various times, but the only one it defined was MVVM.

MVC was Xerox PARC, MVP was Taligent.

Post reply on HN