> *It's NOT a proposal to incorporate JSX into the ECMAScript spec itself.* It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.
My proposal transforms <foo bar={qux}>bla</foo> into { [Symbol.for('jsx')]: 'foo', bar: qux, children: "bla" }
It's self-contained, generic, doesn't rely on imports or globals, and avoids tag key collisions. It's the only way I can imagine it ever being standardized.
because react decided to return JSX like element syntax instead of being simply a function returning a dom element doesn't mean that this should be standardized.
True. Then can you suggest a standardized ECMAScript JSX proposal that doesn't turn this into a "children" key on an object? Would you just transform it into an array? ["foo", { bar: qux }, "baz"] ?
I 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/ or to describe basically any kind of tree.
Can 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?
This 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.
I 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.
> There has been no push for JSX standardization.
https://facebook.github.io/jsx/ is a mirage, apparently.
> *It's NOT a proposal to incorporate JSX into the ECMAScript spec itself.* It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.
(Emphasis theirs.)
Hi, I'm the guy who wrote this proposal.
tl;dr:
My proposal transforms <foo bar={qux}>bla</foo> into { [Symbol.for('jsx')]: 'foo', bar: qux, children: "bla" }
It's self-contained, generic, doesn't rely on imports or globals, and avoids tag key collisions. It's the only way I can imagine it ever being standardized.
I currently use JSX for:
* Creating custom GUI view objects in https://90s.dev/os/
* Using JSX as a convenient & composable string-builder in Node.js via https://immaculata.dev/ when generating all my sites at build-time e.g. https://github.com/sdegutis/immaculata.dev/blob/main/site/te...
* Using JSX to generate plain DOM objects in the browser in some of my sites like https://github.com/sdegutis/minigamemaker.com/blob/main/site...
because react decided to return JSX like element syntax instead of being simply a function returning a dom element doesn't mean that this should be standardized.
Given <foo bar={qux}>bla</foo>
React used to transform it into React.createElement("foo", { bar: qux }, "bla")
Now it transforms it into import _jsx from "react/jsx-runtime"; _jsx("foo", { bar: qux }, "bla")
My proposal transforms it into { [Symbol.for('jsx')]: 'foo', bar: qux, children: "bla" }
It's self-contained and generic, doesn't rely on auto-imports or globals, and doesn't have key collisions.
It's the only way I can imagine it ever being standardized.
What does <foo children={qux}>bla</foo> do?
This is a known ambiguity in JSX, to the point where TypeScript gives this error:
> 'children' are specified twice. The attribute named 'children' will be overwritten. ts(2710)
No, that's an ambiguity in React. JSX defines only syntax.
True. Then can you suggest a standardized ECMAScript JSX proposal that doesn't turn this into a "children" key on an object? Would you just transform it into an array? ["foo", { bar: qux }, "baz"] ?
I'm happy with <template> elements. No shade on JSX, but I prefer the abstraction of HTML, CSS and vanilla JS.
I 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/ or to describe basically any kind of tree.
Can 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?
Canonical reference for me: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
This 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.
I consider the slots-based approach clunky and prefer implementing my own templating system with simple functions returning HTML in template strings.
Even better – return a DocumentFragment: https://stackoverflow.com/a/79233706
I wish this were available natively.
I 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.