5 ms·

It's hard to see this as anything other than an ad for rollup. There's been many attempts to modernize the Three.js codebase. Not sure why this is the one that

It's hard to see this as anything other than an ad for rollup. There's been many attempts to modernize the Three.js codebase. Not sure why this is the one that went through. I'm all for bringing Three.js up to date and applying modern JS tools to it. The maintainers of Three usually push back against these efforts. This PR still doesn't address the many fundamental problems with the quality of Three's source code and the attitudes of the maintainers. I wouldn't personally use Three on a large project, the low quality ecosystem will eventually harm you. It's designed as library to spin up small projects quickly. It's good at that. Beyond that I wouldn't recommend it. For the record I believe Babylon (another WebGL utility library) has similar problems with the source code. I don't have a suggestion for the "best" WebGL library to use.

TheRealPomax 10y ago
Is it, though? If "Hi, I'm the author of the ONLY tool that does bundling based on how ES2015 modules work, and applied that to your codebase, which made it both more useful to future developers and made it smaller as bundle" is an ad, I'd like to see more ads everywhere. Other than rollup there are no bundlers that perform ES2015 module bundling, which means there is no efficient tree shaking, no load-order independency, etc. I suspect the reason it went through is because it _actually_ modernized the codebase: unlike previous ideas, just swapping ES5 notation for a newer slightly more efficient ES6 notation, this refactor actually changes the load, parse, and bundle efficiency of the codebase, from a non-standard module style to what we've now collectively agreed on JS-native module should look like; something that before ES6 simply did not exist. There were choices made by individuals or organizations (commonjs, umd, etc), but only as of ES6 are modules _actually_ a formal construct in JS, with an official spec that formalizes how imports work. Any code changes that bring older codebases in line with the new spec are fantastic: this codebase just got massively future-proofed without any impact whatsoever on its integrity. (the one example that didn't run turned out to be a bug in the current example, not in the refactor)

TheRealPomax 10y ago

Is it, though? If "Hi, I'm the author of the ONLY tool that does bundling based on how ES2015 modules work, and applied that to your codebase, which made it both more useful to future developers and made it smaller as bundle" is an ad, I'd like to see more ads everywhere. Other than rollup there are no bundlers that perform ES2015 module bundling, which means there is no efficient tree shaking, no load-order independency, etc. I suspect the reason it went through is because it _actually_ modernized the codebase: unlike previous ideas, just swapping ES5 notation for a newer slightly more efficient ES6 notation, this refactor actually changes the load, parse, and bundle efficiency of the codebase, from a non-standard module style to what we've now collectively agreed on JS-native module should look like; something that before ES6 simply did not exist. There were choices made by individuals or organizations (commonjs, umd, etc), but only as of ES6 are modules _actually_ a formal construct in JS, with an official spec that formalizes how imports work. Any code changes that bring older codebases in line with the new spec are fantastic: this codebase just got massively future-proofed without any impact whatsoever on its integrity. (the one example that didn't run turned out to be a bug in the current example, not in the refactor)