New JSX Transform

My initial reaction on this is that this looks like a nice (if minor) DX improvement. Not having to type out `React` when it's seemingly not referenced anywhere makes sense.

The underlying signature change is also interesting. If you need to support IE9, then doing `jsx(name, {children})` is going to save a lot of array slice calls that would otherwise be needed for the `React.createElement(name, attrs, ...children)` signature.

On the plumbing side, there's something that bothers me about this change: given this is seemingly a small life quality improvement, it affects a lot of tooling infrastructure (babel, typescript, etc). From a purist perspective, this has a "cancerous" feel (as opposed to being "encapsulated"). This doesn't mean this is a "bad" change per se, but I do feel like it feeds into the idea that "software these days is way too complex"(tm) that has been popping up recently.

There's a subtle aspect of this change that may not be immediately apparent. One that, imho, significantly regresses JSX as an independent syntax outside of React (i.e. makes it much more coupled to React than before):

JSX is an SGML/XML-inspired syntax, and SGML/XML are languages with 3 dimensions of element definition: names, attributes and children.

Internally, React elements are represented in 2 dimensions, with children managed as a "magic" attribute, with the reserved magic key "children" (this is for performance reasons I believe). Before now this has always been an implementation detail of React. JSX is flexible enough that other libraries could provide an element factory method with a fully featured 3-dimensional internal representation. This change removes that flexibility.

To clarify the change, currently JSX compiles to:

  createElement(name, attributes, ...children);

  _jsx(name, { ...attributes, children });

Sorry for bringing up this seemingly tangential question, but honestly the only thing I can think of when I see React stuff these days is that Facebook is behind it.

JSX is really a way to describe a hierarchy of deferred function calls independent of their callers. This could be tremendously useful in a number of different contexts, not just UI. What would a state machine look like if the states could be described in JSX? What would rx.js look like if this mechanism was available?

The current tooling makes experimenting with possible alternate use cases pretty awkward, and so basically no one is doing work in this area.

I believe that these changes, particularly the `jsx` and `jsxs` auto import, will make it even harder to separate JSX as a concept from React and React-like libraries. It'll make it harder to standardise JSX, which is frustrating as it's the most supported ECMAScript syntax extension by a long way.

My modest proposal is that a JSX element desugars to a call to a block scoped identifier called `jsx`, so I can do something like this:

    import { jsx } from 'react';
    import { elementCreator } from 'somelib';

    const someFunction = () => {
      const { jsx } = elementCreator();

      return <iAmNotAReactElement />;
    };

    const MyReactComponent = () => <div>cool</div>;

I understand that there are perf optimisations that React can do if they control all of this. But I feel like they're looking at this too narrowly, from only the perspective of UI. They have the power to open up a lot more opportunities.

I do feel Typescipt tries to over-accommodate React compared to other frontend frameworks. The jsx code is pretty gnarly in TS and this makes it even more complicated for little gain.

Magic imports are a big no no. The whole idea about import/export syntax is that a module explicitly imports what it uses and other modules can only import what it exports.

I can understand React.createElement -> jsx function. Preact, mihthrill and others use the h function. This already works without new transform.

It seems that with React hooks and special JSX transforms, the authors are trying to prioritize cleverness over simplicity and clarity.

Now every project you have to grapple with the decision “is this automatic or classic?” and what about the next version, is it “super automatic” runtime?

    function foo(props) {
      return <h1>hi!</ht>
    }

    function foo(jsx) {
      return function foo(props) {
        return jsx.createElement('h1', ...);
      }
    }

EDIT: added as comment https://github.com/reactjs/rfcs/pull/107#issuecomment-696978...

I wonder what plans the React team has for JSX. I liked the prop forwarding style that ReasonReact had, but I guess that's not compatible.

However from my experience out in the day to day world (which is largely outside Bay Area Silicon Valley), this is not the case. Indeed, HNers and forward thinking devs here were the first comers to React, largely. I know I was on it pretty early (and walked a way more than once!) but the reality is its just picking up major steam in other places, the so called 'shadow developer' communities, like large .NET shops that when I talk to them at conferences, desperately want to move away from Angular, and React is often a choice (Vue is gaining steam here too. I think this second order of developers will decide how big each get, IMO).

Through that lens, its amazing they're taking these steps to find the balance between 'magic' (auto imports!) and lessening the syntax you have to learn as you grow development. There are so many shops, in enterprise in particular, full of 'shadow' developers most of us never meet or hear about, that are hungry for this kind of thing. Angular has some foot hold here, but Microsoft has been keen on trying to give alternatives, one of which is React (and MS here still has a lot of weight) and I think React will have staying power and growth by making itself more appealing to these kinds of developers. These are the kinds of devs who still use jQuery in 2020 (not that its bad! I swear I don't think that outright), even for new projects. There's a ton of the web ecosystem that has not and does not develop with these things in mind.

I have witnessed this with hooks. Hooks made React more approachable to development teams I worked with because class components had an unintended side effect - Developers made all of the logic encapsulated by the component inside methods - where extracting functions would have been easier to test and been far more modular - simply because thats OOP to most devs (right or wrongly). So you'd end up with 10K line classes that do all kinds of byzantine things with extremely tight coupling.

With hooks, functions become the pattern, and the library (can we just call it a framework already?) really molds the developer into best practices of extracting components and using component composition.

Basically, if you aren't just looking to reach the HN crowd, these changes are great. Thats been my experience so far. React has been growing in popularity at places I've worked and other developers I know see this too (many of which develop at consultancies, PHP/Wordpress shops, .NET shops etc) because of the change of paradigms as well as stability, of course, have made it much more maintainable.

This says very little of the overall web ecosystem, which still has a major churn problem (same for the ecosystem around React, too much churn and breaking changes, over minimal upsides, I've observed)

Since I'm rambling, I wonder what React would look like if Web Components V1 was a thing when it first came out.

It's unfortunate that they don't expand on this. Is the reduction on the number of concepts simply that one doesn't need to import React? I doubt it. So what does this new transform enable in the future that will reduce the number of concepts you need to learn?