Starting from r109 three.module.js contain non transpiled classes

r109 introduced the usage of ES6 which is a good thing.

Reading the PR #17276 that made this change states that the classes get transpiled to ES5 syntax in three.js and three.min.js which is not sufficient. three.modle.js needs to have ES5 syntax too.

In fact other NPM modules depend on three.js such as Photo Sphere Viewer that got affected by this change.

We use this module on production and it caused our website to crash on IE 11.

[donmccurdy]

the ask here is that Three.js follows suit on many established standards in the open source community…

Are there references you could share explaining this standard? All npm packages should be published as ES5? They aren’t always, as a rule, but I’m certainly open to any guidelines we can find.

Out of the box, the library should work against the lowest common denominator runtime.

Developers using threejs may be writing applications whose final build output targets different ECMA features, from ES3 up to ES6+. By transpiling the library down to older JS versions we may also force some costs (code size, performance) onto developers who are targeting modern browsers. three.js is an unusually performance-sensitive library, and there has historically been some aversion to adding new build steps that mutate optimized code.

I don’t know whether those costs outweigh those you describe; perhaps not. But it would be nice to have input from authors of the bundling/transpiling tools here.

[dkurucz]

@mrdoob @looeee the ask here is that Three.js follows suit on many established standards in the open source community to enable wide consumption of the library on all platforms. It is known across the community that not all browsers follow the ES6 conventions out of the box, the main offender used by a substantial set of web consumers being IE11.

By asking developers to manually transpile the final build of the library as a runtime, you are asking developers to provide an extra configuration that is entirely self-composed in order for their application to be able to consume it. From a pure practical sense in the context of Three.js, this is a perfectly valid ask, but from the perspective of developers working on larger scale projects, Three.js in all likelihood not the only library being pulled into the project. Imagine if every library on github started adopting this mentality. Every developer would need to provide a compatible configuration, often times a very fragile and high-maintenance project-level configuration, based on the ECMA standard of the sum of all libraries required, to correctly transpile. The number of libraries can get into the tens, hundreds, and this is only for direct dependencies. Furthermore, they would be required to check, update, and change every time each individual library updates in a breaking way. When transitive dependencies start coming into the equation, it gets even worse. What this amounts to is a maintenance task that should be entirely avoided, as the minimal configuration for any library to correctly work as ECMA evolves over time will absolutely vary between projects and dependencies.

In addition to all of this, each time a library provided a breaking update, a developer would not only need to anticipate that it updated, but the developer would also need to spend time understanding how those updates affect their existing configuration. This isn’t a matter of understanding Babel at this point, it’s a matter of maintenance over time for every library that follows this avoidance mentality, forcing consumers to understand what the project needs to work correctly, and then playing referee for the sum of all dependencies, some which might actually have locked in a version of Babel until a subsequent release (Vue’s CLI and testing tools are a perfect example), which could actually trap them into pulling in multiple versions of Babel with multiple configurations. Out of the box, the library should work against the lowest common denominator runtime. Playing referee in this regard does not scale from a maintenance, time, and overall cost perspective, especially for small teams working on a limited budget who may rely on large numbers of libraries in order to be successful.

In an even mostly ideal world, the onus is on the developer of the library to provide some form of configuration that is guaranteed to work without requiring developers to spend time figuring out which Babel versions, configurations, and plugins are required for this specific project. Taking the responsibility as the browser ecosystem matures, you are able to alleviate, mathematically, potentially hundreds of hours at a time around domain-specific requirements that (may not yet, but will) exist for the library to ultimately work as you increment the version and adopt newer ECMA features, and you are able to guarantee that it will work the same way every time, since it will have worked prior to being pulled in to the consuming project. At the moment, you haven’t even established which versions of any of the above you will need to configure (are you ES2015, 2017? etc). Given the long list of available standards, https://en.wikipedia.org/wiki/ECMAScript, any developer will need to start off by guessing what features you are consuming.

I hope you reconsider because of how widely Three.js is used. This is not an exhaustive list, but please understand that the open source community does in fact typically provide the common reduced library runtimes for a very good set of reasons.