[templates] A declarative JavaScript templating API
Related to many template, template instantiation, and DOM parts discussions (but especially https://github.com/WICG/webcomponents/issues/777, https://github.com/WICG/webcomponents/issues/682, and https://github.com/WICG/webcomponents/issues/704) I wonder if we should add a JavaScript-based templating API? I think JS-based templating would be extremely useful and help with a lot of issues and questions: - Ergonomics and convenience: Templating in JS is an incredibly common thing to do on the web, yet there's no built-in API for it. Developers have often asked for a built-in declarative way to build and update DOM. - Safety: We can provide a safe way of interpolating untrusted values into the DOM protecting against XSS. - Clarify the MVP for DOM parts: Templating in JS can cover a lot of open questions for template instantiation, like those brought up in https://github.com/WICG/webcomponents/issues/682, like what the expression syntax is, how to do conditionals and looping, how scoping works, etc. - Performance: As shown by several JS libraries, the DOM Parts model can be used to construct very fast DOM renderers. Fast, stable DOM updates as a platform feature would be a performance feature. - Improve the initial value delivered by DOM Parts: The DOM Parts model can be used for fast templating, but given some Chrome prototypes a native implementation _might_ not be a large performance win over similar userland implementations. There is still a lot of value in offering built-i
Posted by justinfagnani on Aug 16, 2024, 4:57 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
[templates] A declarative JavaScript templating API
Related to many template, template instantiation, and DOM parts discussions (but especially https://github.com/WICG/webcomponents/issues/777, https://github.com/WICG/webcomponents/issues/682, and https://github.com/WICG/webcomponents/issues/704) I wonder if we should add a JavaScript-based templating API? I think JS-based templating would be extremely useful and help with a lot of issues and questions: - Ergonomics and convenience: Templating in JS is an incredibly common thing to do on the web, yet there's no built-in API for it. Developers have often asked for a built-in declarative way to build and update DOM. - Safety: We can provide a safe way of interpolating untrusted values into the DOM protecting against XSS. - Clarify the MVP for DOM parts: Templating in JS can cover a lot of open questions for template instantiation, like those brought up in https://github.com/WICG/webcomponents/issues/682, like what the expression syntax is, how to do conditionals and looping, how scoping works, etc. - Performance: As shown by several JS libraries, the DOM Parts model can be used to construct very fast DOM renderers. Fast, stable DOM updates as a platform feature would be a performance feature. - Improve the initial value delivered by DOM Parts: The DOM Parts model can be used for fast templating, but given some Chrome prototypes a native implementation _might_ not be a large performance win over similar userland implementations. There is still a lot of value in offering built-i
Comments (0)
No comments yet. Start the discussion.