3 ms·

I'm actually surprised that jsx hasn't made it's way into the standard yet. That still seems a more likely outcome than react going away.

by jemmyw 1y ago

aatd86 1y ago
jsx is not really needed. We have templates. Besides it really is a dsl with a weird syntax. I'm doubtful it will ever become an ES standard. And for good reasons. That should be left to the different frameworks to handle.
- Bolwin 1y ago
  Templates are horribly limited compared to the free mixing of js and markup Jsx gives you
  - aatd86 1y ago
    If you use them raw, yes. They are just the building block you can build upon. And that's a really good building block. You can create your own parsers. I am doing exactly this for a framework that has yet to be released, full disclosure. Makes html clearly html, and javascript fully javascript. No bastardization of either one into a chimera. And the junction of the two is why the custom parser is required. But it is really light from a dev experience.
recursive 1y ago
JSX is syntax only with no defined behavior. Which standard would it make it into? HTML and javascript specs define syntax AND semantics. I sincerely doubt that either of JSX's syntax or its semantics under React's transforms would make it into a W3 or WHAT spec as they exist today.
- WorldMaker 1y ago
  The direct semantics of JSX are "transform this syntax into this nested sequence of function calls and this layout of arguments". That's been the case since nearly the beginning. The only real semantics "fights"/"changes"/"React-specifics" you can see in the compiler options in Babel and Typescript: what the function is named and how do you import it. Enough other libraries that aren't React use JSX that it is easy to see what the generic approach looks and find ideas for runtime configuration of "jsx function name" and an import strategy that isn't just "import these hardcoded names from these hardcoded React modules".
  - MrJohz 1y ago
    > The direct semantics of JSX are "transform this syntax into this nested sequence of function calls and this layout of arguments". Not exclusively. SolidJS, for example, transforms the syntax into string templates with holes in them. The "each element is a function call" approach works really well if those calls are cheap (i.e. with a VDOM), but if you're generating DOM nodes, you typically want to group all your calls together and pass the result to the browser as a string and let it figure out how to parse it. For example, if you've got some JSX like: <div> <div> <span>{text}</span> <div> <div> You don't want that to become nested calls to some wrapper around 'document.createElement`, because that's slow. What you want is to instead do something like const template = parseHtml(` <div> <div> <span></span> <div> <div> `); template.children[0].children[0].innerText = text This lets the browser do more of the hard parsing and DOM-construction work in native code, and makes everything a lot more efficient. And it isn't possible if JSX is defined to only have the semantics that it has in React.
    - recursive 1y ago
      > You don't want that to become nested calls to some wrapper around 'document.createElement`, because that's slow. It's really not slow. It might seems slow if you're using react behavior which re-invokes the "render function" any time anything changes. But eventually they get reconciled into the DOM which creates the elements anyway. And most other code bases are not based on this reconciliation concept. So I don't think that's a given.
      - MrJohz 1y ago
        It's significantly slower than letting the browser do the work for you. Obviously performance isn't the only concern, but (a) as a user, I don't want people wasting my CPU cycles unnecessarily, and (b) I've worked on applications where ever single millisecond counted, and the createElement approach would have made a material difference to the performance of the application overall. Also, there's no reconciliation happening here. In SolidJS, as well as in Vue in the new Vapor mode, and Svelte, the element that is returned from a block of JSX (or a template in Svelte) is the DOM element that you work with. That's why you don't need to keep rerendering these components - there's no diffing or reconciliation happening, instead changes to data are directly translated into updates to a given DOM node. But even if you don't need to worry about subsequent re-renders like with VDOM-based frameworks, you still need to worry about that initial render. And that goes a lot quicker if you can treat a JSX block as a holistic unit rather than as individual function calls.
SahAssar 1y ago
It sorta was, even before jsx: https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML

I'm actually surprised that jsx hasn't made it's way into the standard yet. That still seems a more likely outcome than react going away.

by jemmyw 1y ago

I'm actually surprised that jsx hasn't made it's way into the standard yet. That still seems a more likely outcome than react going away.

aatd86 1y ago

jsx is not really needed. We have templates. Besides it really is a dsl with a weird syntax. I'm doubtful it will ever become an ES standard. And for good reasons. That should be left to the different frameworks to handle.

Bolwin 1y ago
Templates are horribly limited compared to the free mixing of js and markup Jsx gives you
- aatd86 1y ago
  If you use them raw, yes. They are just the building block you can build upon. And that's a really good building block. You can create your own parsers. I am doing exactly this for a framework that has yet to be released, full disclosure. Makes html clearly html, and javascript fully javascript. No bastardization of either one into a chimera. And the junction of the two is why the custom parser is required. But it is really light from a dev experience.

recursive 1y ago

JSX is syntax only with no defined behavior. Which standard would it make it into? HTML and javascript specs define syntax AND semantics. I sincerely doubt that either of JSX's syntax or its semantics under React's transforms would make it into a W3 or WHAT spec as they exist today.

WorldMaker 1y ago
The direct semantics of JSX are "transform this syntax into this nested sequence of function calls and this layout of arguments". That's been the case since nearly the beginning. The only real semantics "fights"/"changes"/"React-specifics" you can see in the compiler options in Babel and Typescript: what the function is named and how do you import it. Enough other libraries that aren't React use JSX that it is easy to see what the generic approach looks and find ideas for runtime configuration of "jsx function name" and an import strategy that isn't just "import these hardcoded names from these hardcoded React modules".
- MrJohz 1y ago
  > The direct semantics of JSX are "transform this syntax into this nested sequence of function calls and this layout of arguments". Not exclusively. SolidJS, for example, transforms the syntax into string templates with holes in them. The "each element is a function call" approach works really well if those calls are cheap (i.e. with a VDOM), but if you're generating DOM nodes, you typically want to group all your calls together and pass the result to the browser as a string and let it figure out how to parse it. For example, if you've got some JSX like: <div> <div> <span>{text}</span> <div> <div> You don't want that to become nested calls to some wrapper around 'document.createElement`, because that's slow. What you want is to instead do something like const template = parseHtml(` <div> <div> <span></span> <div> <div> `); template.children[0].children[0].innerText = text This lets the browser do more of the hard parsing and DOM-construction work in native code, and makes everything a lot more efficient. And it isn't possible if JSX is defined to only have the semantics that it has in React.
  - recursive 1y ago
    > You don't want that to become nested calls to some wrapper around 'document.createElement`, because that's slow. It's really not slow. It might seems slow if you're using react behavior which re-invokes the "render function" any time anything changes. But eventually they get reconciled into the DOM which creates the elements anyway. And most other code bases are not based on this reconciliation concept. So I don't think that's a given.
    - MrJohz 1y ago
      It's significantly slower than letting the browser do the work for you. Obviously performance isn't the only concern, but (a) as a user, I don't want people wasting my CPU cycles unnecessarily, and (b) I've worked on applications where ever single millisecond counted, and the createElement approach would have made a material difference to the performance of the application overall. Also, there's no reconciliation happening here. In SolidJS, as well as in Vue in the new Vapor mode, and Svelte, the element that is returned from a block of JSX (or a template in Svelte) is the DOM element that you work with. That's why you don't need to keep rerendering these components - there's no diffing or reconciliation happening, instead changes to data are directly translated into updates to a given DOM node. But even if you don't need to worry about subsequent re-renders like with VDOM-based frameworks, you still need to worry about that initial render. And that goes a lot quicker if you can treat a JSX block as a holistic unit rather than as individual function calls.

SahAssar 1y ago

It sorta was, even before jsx: https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML