- From: Tom Wilkinson <notifications@github.com>
- Date: Mon, 13 Nov 2023 11:05:39 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1035/1808838580@github.com>
What in particular about the proposal makes it difficult for non-JS backends to adopt? Why is it hard to generate HTML with `parseparts` attributes and `{{}}` markers in non-JS backends? As a fun aside, isomorphic architecture is also possible in non-JS backends. One of the major frameworks for Google, Wiz, uses a templating system that produces Java code that renders the same as the produced JavaScript code, https://github.com/google/closure-templates. But I still think even if there isn't a shared concept of template between the client and the server, this proposal could still be useful. I agree though, it would be much easier if this proposal included data bindings as a means to update DOM, rather than just providing DOM to JavaScript code. But, we have not yet proposed that alternative because exactly to your point it would make the proposal too costly to experiment with - the code that we are trying to replace would be far faster than code that used the browser to update DOM by passing in data represented in JavaScript or CSS, we believe based on benchmarks thus far. We're working to improve the data story here by improving JS bindings and passing data between JS and C++, but it's far more costly to pass a JS data object to C++ that it is to pass strings to C++. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1035#issuecomment-1808838580 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1035/1808838580@github.com>
Received on Monday, 13 November 2023 19:05:44 UTC