Native ecmascript module for React and ReactDOM

[PM5544]

Do you want to request a feature or report a bug?
This probably is a feature request since the root of this is considering the build tooling and questions on how to proceed with my efforts.

What is the current behavior?
No native ecmascript module output and the current build tools don't easily allow adding a native ecmascript module build target.

While investigating a workflow using a native ecmascript module version of React (and ReactDOM) in browsers I found no implementation which outputs native ecmascript modules.
One can use a wrapped version of the transpiled versions with added export statements but transpiling would not be necessary for browsers supporting ecmascript modules natively.
Even spread operators are supported by these browsers although they're not fully supported by AST generators or other tools due to the fact that the spec for that isn't finalised.

After some test projects and different build tools I built a simple proof of concept which outputs ecmascript modules that can be used in modern browsers.
The challenge (and question I have) is that the tools and settings used in the POC contradict the current build settings and tools.
So I am wondering if this is something that can be added as a build target or that this is something that is better suitable for an external repo for the time being...

I would love to make this happen but I would like to hear if this is something that is deemed worth while and if so in what would be the preferred way of implementing this.
During my investigation I did not find an easy way of doing so without changing a considerable amount of code and build tooling. Making this a relatively high risk endeavour.
Webpack vs Rollup, different settings needed for Babel, and named exports instead of CommonJS module.exports pattern to name a few, and all the effects those have on the build process make this somewhat complex.

To clarify some things, these are links to the POC's:
repo which outputs native ecmascript modules for React and ReactDOM: https://github.com/wearespindle/react-ecmascript
repo with a minimal setup to test if a working app can be made these modules in a browser: https://github.com/PM5544/module-test

What is the expected behavior?
Preferably a build target for native ecmascript modules.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
not relevant

[TrySound]

@PM5544 Seems like a duplicate of #11503

[PM5544]

This somehow did not turn up in my former searches, so thanks for pointing this out.
While it has overlap, the point of the linked issue is different in nature I believe. It misses the build target without transpiling or has much less focus on it. And that is the biggest reason for the incompatibilities between the current build process and the one in my POC.

I'm curious what you think of this.

[TrySound]

Do you have size differences between bundles and benchmark about bundles performance? AFAIK there's not big deal using untranspiled version. Not sure about now, but before there was performance regressions with es6 code in browsers, but es5 is fast.

Adding esm version makes sense for browsers and bundlers, it was discussed in linked thread. But providing also untranspiled version without significant benefits will introduce a lot of mess for users.

[PM5544]

I haven't compared the transpiled and untranspiled versions before but checking the react versions on disk yields 57.796 (for the UMD unminified version) vs 56.265 bytes (for the unminified untranspiled one in my POC) a difference of only 1531 bytes.
This highly unscientific comparison focussing only on file size does not really favour any of the two.
What the actual effects are on parsing and such remains to be investigated.

Some random reasons for wanting a build target for native esm is that it greatly simplifies the development setup lowering the threshold for new developers, it might prevent the gap between the Webpack approach and what is doable natively in browsers from getting bigger, and that it can be done natively which progresses the web as a platform.
When we all keep using transpiled into es5 versions of code browsers will not have any incentive to optimise for these new use cases.

I'm really curious what mess it would add for users and what you would believe to be significant benefits.

[TrySound]

#10164 (comment)

[gaearon]

Closing as overlapping with #10021.

[PM5544]

Ah that one also has a lot of overlap, but still it does not completely cover this issue I believe. It misses the ESM native export and import functionality which support for has greatly improved since than.
Do the combined issues you linked to mean that I should give up my efforts to get a native ecmascript module build target a reality or is there another point you're trying to make?

Ah, clear since this issue was closed while typing...

[TrySound]

@PM5544
"Add a "module" entry in package.json" means "ESM native export and import functionality"

[gaearon]

We try not to have issues covering the same problem. #10021 is precisely about ESM. But that’s impossible until we fix #11503. Both issues already exist; I don’t see a value in having yet another one open 🙂

Edit: fixed links

[PM5544]

@TrySound @gaearon thanks for clearing that up, I'll monitor and try to participate in the other issues.