4 ms·
I'm happy with <template> elements. No shade on JSX, but I prefer the abstraction of HTML, CSS and vanilla JS.
by palmfacehn 1y ago
I'm happy with <template> elements. No shade on JSX, but I prefer the abstraction of HTML, CSS and vanilla JS.
- cluckindan 1y agoI consider the slots-based approach clunky and prefer implementing my own templating system with simple functions returning HTML in template strings.
- palmfacehn 1y agoI did this in the past, but I found that templates simplified the process. The same functions I use to populate/update elements can be reused on existing elements and newly cloned template elements. It can be done in JS by returning strings of unpopulated elements, but then my display is further mixed with logic. I like to create the HTML and CSS as I'd like it with test data, then just wrap that with <template> tags. Easy to preview without triggering function calls or pasting it into code. Probably not important, but as I recall I think there was some minor overhead in translating from a JS String to an Element.
- pwdisswordfishz 1y agoEven better – return a DocumentFragment: https://stackoverflow.com/a/79233706 https://stackoverflow.com/a/79233706 I wish this were available natively.
- HelloNurse 1y agoCan you recommend examples and tutorials of happy <template> usage, showing advantages over building values for innerHTML etc. as text from strings and template string literals?
- palmfacehn 1y agoCanonical reference for me: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- HelloNurse 1y agoThis MDN page is where I first discovered the <template> element, and I wasn't very impressed: verbosely operating on one textContent at a time, using ordinal indices into very untyped querySelectorAll results, apparently gratuitous complications with document fragments and shadow DOM.
- palmfacehn 1y agoVerbosity never concerned me. Readability, maintenance, page weight and separation of concerns does. Typically I do not find myself using querySelectorAll within the context of a template element. When I do I am usually applying changes universally to all of the matched children within the element. The CSS class of the element reflects these things semantically. I find this highly readable. It also resolves most concerns around the type of the element. Of course in Vanilla JS, types are a mess. Even Microsoft's finest duct tape script doesn't fully resolve these issues. Overall I find Vanilla JS and browser APIs to be a lesser evil than the build systems, package managers and indirection of the React/Next.js approaches. After all, these compiled environments and their libraries will boil down to Vanilla JS when deployed in the browser.
- 90s_dev 1y agoI made this proposal because JSX is more generally useful than generating HTML. You can use it for configuration, or views for other GUIs like I do in https://90s.dev/os/ https://90s.dev/os/ or to describe basically any kind of tree.
- WorldMaker 1y agoTemplate elements don't have great Typescript type checking today. I've been very happy with both, writing things in TSX with deep type checking and then statically rendering them to Template tags. [0] https://worldmaker.net/butterfloat/#/stamps https://worldmaker.net/butterfloat/#/stamps