Re: [WICG/webcomponents] DOM parts use outside of <template> seems unlikely (Issue #1035)

@tbondwilkinson Thanks for joining the party. 😀

> Code that does not fall into one of those categories is interesting to us, but not the MVP that we've agreed on up to this point (we're open to changing that, if there's feedback).

Consider this the feedback 🙂. I challenge you to find examples of (2) and (3) in existing userland framework that are not JS-based backends. The templating proposal is not dissimilar from how a lot of existing JS frameworks work today. But non-JS frameworks largely do not. Why is that?

I think answering this questions is the critical thing to do before proceeding further. Happy to continue this discussion in another thread if it helpful.

My belief is this: templating naturally leads one towards an "isomorphic" solution; which is a solution where the server and client environments are abstracted so that they appear (to the developer) as just one abstraction. And any non-JS language is at a disadvantageous position because it's much harder for them to present such an abstraction as those languages do not (mostly, and some with caveats) run in the browser.

> I think setting HTML content via CSS is a design direction we have been discouraged from exploring, but I'm interested in it as well. There was quite a bit of pushback on the CSS toggle proposal, where people questioned why CSS was now responsible for what would normally have been the domain of HTML

I have seen such feedback before too. A CSS-like solution doesn't necessarily need to be `.css`, it could be a new DSL that shares the same parser but has some different constraints.

Or maybe a CSS-like is not the answer. I'm mainly trying to get people to think about "binding from a distance" as a positive thing that helps decouple. CSS is just a natural thing to pull ideas from since it's an existing (and successful) DSL that does this. But we can invent new DSLs too.

> That remains an open question - but one that we're interesting in exploring next.

Great, please loop me in to those discussions, I'd love to be part of it. I'd also like to point out that CSS-like has some prior art. Of course it doesn't have nearly as much as templating, so no idea is fully baked. But it should have time to bake more before templating is chosen which, imo, would be a major mistake.

Some links:

- [Cascading Attribute Sheets](https://www.xanthir.com/blog/b4K_0) by Tab Atkins.
- [Corset](https://corset.dev/) a library by me, which implements some of the CSS-like ideas I've been discussing here.
- [XSLT](https://en.wikipedia.org/wiki/XSLT) I'll let the historians explain why that failed, but maybe there's something we can pull from it and bring into the modern web, that still accomplishes the "binding from a distance" desire?

> I want to be clear that our focus and priority has been on figuring out the technical feasibility of this space. Is it possible for us to design an API that has reasonable performance and replaces the existing JavaScript code that we have in frameworks for rendering and updating rendered content? That's the question we've been building benchmarks for and discussing in depth with browser and v8 engineers. Because without answering that question, any discussion of API shape could be wasted time if we don't properly know what trade-offs from a performance and feasibility perspective we're up against.

I would suggest adding "will non-JS frameworks adopt this?" as a question to answer. Key word being **will** they, not **can** they. You can talk yourself into something being possible more easily than you can explain why they will want to do it; **will** requires putting yourself in their shoes and thinking about their priorities.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1035#issuecomment-1806483528
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1035/1806483528@github.com>