4 ms·

That's an interesting opinion. JSX feels far more natural to me.

toastercat 5y ago
JSX also initially felt more natural to me aesthetically since it looks like HTML. But that's where those feelings end; JSX is not valid JavaScript, it doesn't extend the language in any meaningful way, it superficially resembles HTML which we all were already familiar with. Hyperscript or HTML helper functions are not only less typing, but indent more naturally and can live in regular .js files without need for transpilation or IDE plugins.
- bern4444 5y ago
  JSX allows for dynamically generating HTML elements that have access to values from JS without any work in binding the two together. That's pretty convenient. JSX is valid JS. It is converted down to the same thing as what you describe, function calls to React.createElement(). Which can also be used instead and aliased to a function if you prefer. Using "HTML" like syntax in JSX then let's React not have to invent it's own base components and let's you think about the "HTML" as HMTL. You could even alias all the elements to function names const h1 = (...) => { React.createElement({...}) } and then call those functions like so h1(...) across your components instead of <h1> ... </h1>. const MyComponent = () => { return ( div( h1(...) h2(...) p(...) items.map(item => li(item)) ) ) } A "component" is just a JS Object that you can manipulate and pass through wherever you want like anything else.
  - toastercat 5y ago
    > JSX is valid JS. It is converted down to the same thing as what you describe, function calls to React.createElement(). This is disingenuous. Browsers do not understand JSX, nor do most JavaScript engines. TypeScript also gets transpiled to JavaScript -- it is not valid JavaScript in and of itself, you require a build step. We can argue semantics, but I think it's pretty clear what I meant. > You could even alias all the elements to function names You've just recreated what I mentioned two comments above in this same comments thread. :) See: https://github.com/jorgebucaran/hyperapp/tree/main/packages/html https://github.com/jorgebucaran/hyperapp/tree/main/packages/... This is what I'm arguing for over something like JSX.
    - bern4444 5y ago
      I understand, and the browsers don't understand JSX is a fair point. I'm only illustrating that the difference between JSX and JS for React is about syntax and not the core distinction of why React feels easier to work with compared to angular/vue/svelte etc which all invent their own mini languages. JSX feels much more natural since it allows for the same JS everyone (hopefully) loves. Something like hyperapp/hyperscript can absolutely be used in place of JSX, but the HTML likeness that JSX enables feels more natural to me - and I think most - vs a bunch of h1(), h2() etc function calls. In the end, though, this is a trivial difference. A component expressed in JSX is really just a JS function call that ends up as a document.createElement() invocation.
- WorldMaker 5y ago
  > JSX is not valid JavaScript, it doesn't extend the language in any meaningful way It's semi-directly related to (subset of a) JavaScript standard which it evolves some of the more useful syntax for some modern needs. It's just not an "active" standard currently targeted by browsers today (in part because it need evolution): ECMA-357 aka E4X aka ECMAScript for XML. [1] There's currently no interest in adding browser support for JSX (either from the JSX spec itself or any browser makers), just as E4X support waned very quickly when Firefox was the only browser interested in supporting it, but that doesn't mean it is impossible to see browser support at all in the future. It was standardized once, it might be standardized again now that we have a better idea of what it might be used for in the wild. (I don't think it will be, mostly because there's an ecosystem of interesting non-React usages of JSX that would be hampered a bit if it wasn't just a transpiler step.) [1] https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML

JSX also initially felt more natural to me aesthetically since it looks like HTML. But that's where those feelings end; JSX is not valid JavaScript, it doesn't extend the language in any meaningful way, it superficially resembles HTML which we all were already familiar with. Hyperscript or HTML helper functions are not only less typing, but indent more naturally and can live in regular .js files without need for transpilation or IDE plugins.

bern4444 5y ago
JSX allows for dynamically generating HTML elements that have access to values from JS without any work in binding the two together. That's pretty convenient. JSX is valid JS. It is converted down to the same thing as what you describe, function calls to React.createElement(). Which can also be used instead and aliased to a function if you prefer. Using "HTML" like syntax in JSX then let's React not have to invent it's own base components and let's you think about the "HTML" as HMTL. You could even alias all the elements to function names const h1 = (...) => { React.createElement({...}) } and then call those functions like so h1(...) across your components instead of <h1> ... </h1>. const MyComponent = () => { return ( div( h1(...) h2(...) p(...) items.map(item => li(item)) ) ) } A "component" is just a JS Object that you can manipulate and pass through wherever you want like anything else.
- toastercat 5y ago
  > JSX is valid JS. It is converted down to the same thing as what you describe, function calls to React.createElement(). This is disingenuous. Browsers do not understand JSX, nor do most JavaScript engines. TypeScript also gets transpiled to JavaScript -- it is not valid JavaScript in and of itself, you require a build step. We can argue semantics, but I think it's pretty clear what I meant. > You could even alias all the elements to function names You've just recreated what I mentioned two comments above in this same comments thread. :) See: https://github.com/jorgebucaran/hyperapp/tree/main/packages/html https://github.com/jorgebucaran/hyperapp/tree/main/packages/... This is what I'm arguing for over something like JSX.
  - bern4444 5y ago
    I understand, and the browsers don't understand JSX is a fair point. I'm only illustrating that the difference between JSX and JS for React is about syntax and not the core distinction of why React feels easier to work with compared to angular/vue/svelte etc which all invent their own mini languages. JSX feels much more natural since it allows for the same JS everyone (hopefully) loves. Something like hyperapp/hyperscript can absolutely be used in place of JSX, but the HTML likeness that JSX enables feels more natural to me - and I think most - vs a bunch of h1(), h2() etc function calls. In the end, though, this is a trivial difference. A component expressed in JSX is really just a JS function call that ends up as a document.createElement() invocation.
WorldMaker 5y ago
> JSX is not valid JavaScript, it doesn't extend the language in any meaningful way It's semi-directly related to (subset of a) JavaScript standard which it evolves some of the more useful syntax for some modern needs. It's just not an "active" standard currently targeted by browsers today (in part because it need evolution): ECMA-357 aka E4X aka ECMAScript for XML. [1] There's currently no interest in adding browser support for JSX (either from the JSX spec itself or any browser makers), just as E4X support waned very quickly when Firefox was the only browser interested in supporting it, but that doesn't mean it is impossible to see browser support at all in the future. It was standardized once, it might be standardized again now that we have a better idea of what it might be used for in the wild. (I don't think it will be, mostly because there's an ecosystem of interesting non-React usages of JSX that would be hampered a bit if it wasn't just a transpiler step.) [1] https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML