Does three.js need a "lite" rewrite? Here are my ideas

Questions
,
1

Maintainers and Contributors to three.js: What changes would you like to see if three.js were to be rewritten?

As a user and contributor for three.js for a few years now, I’d like to share some things that would be good reasons to consider a “three.js lite” version:

  1. Eliminate the need for a separate @types/three dependency by making three.js fully compatibile with TypeScript checking via JSDoc. There are inconsistencies between three.js and the third-party @types/three project, ESPECIALLY with TSL, which makes using three.js in TypeScript-enabled project difficult (e.g. missing properties, type mismatches, etc.). Aside from the inconsistencies, there is also the lag time between new releases of three.js and the corresponding @types/three release. In the spirit of three.js being a JavaScript-first library, JSDoc could be used to make three.js a fully TypeScript-compatible library, even in vanilla JavaScript. This would completely eliminate the need for a separate @types/three dependency. Because JSDoc has been greatly improved over the last several years, making heavy use of the @abstract and @template JSDoc tags would give you all the features you need for a professional library. I suspect this would greatly help with development of three.js as well because of TypeScript’s early-warning nature, but not actually require you to use TypeScript since JSDoc does not need to be compiled by TypeScript.
  2. Use the new ECMAScript 2022 # character for private class members. Vanilla JavaScript now supports truly private properties and methods with the hash # character. three.js is still filled with underscore _ properties serving as private or protected properties, and could benefit from true encapsulation of these properties using #.
  3. Resolve the lingering issues with updateMatrix() and updateMatrixWorld()/updateWorldMatrix(). Right now there are problems with the updateMatrix() and updateMatrixWorld()/updateWorldMatrix() methods: Calling a world matrix update method cannot recompute matrixWorld while matrixWorldAutoUpdate = false. You cannot request only world-matrix calculation while leaving matrixAutoUpdate = true. World calculation is coupled to local updates and descendant traversal, making custom calculation difficult to override.
  4. A three.js build is quite large, even after being minified. If you ask ChatGPT Astra to generate a standalone .html file representing a small 3D FPS game using nothing but raw calls to WebGPU, with no library at all, the final file size is around 50kb. When asked to generate the same game with three.js, the final file size is around 600kb. I’m wondering if there are things in three.js that can be simplified or removed?
2

three.js has used JSDoc since r172…

3

JSDoc can be used for two things: documentation and/or TypeScript type checking. Yes, three.js is filled with JSDoc, but it is only for documentation. My proposal is that it also be used for TypeScript type checking. Currently, if you try to run a build of three.js through TypeScript, you will get thousands of errors because of incomplete or invalid type assignments in the existing JSDoc.

4

it looks like @typedef, @property , @param and others are being actively used throughout latest additions to the lib…

I’m sure adding a PR with extensive definitions throughout the entire library wouldn’t be too difficult to get merged…