this is a mistake, draco isn’t shipped by three, you need to put the binaries into your /public
other than that, i wouldn’t use timers for anything, all this can do is fail. wouldn’t also want to tie my app status to something as fragile as xhr data. you have async/await, you know exactly where loading starts and ends.
oh, indeed, that is news to me. though it is useless either way because you can’t fetch from node_modules. maybe three authors weren’t aware of it, but this is basically just extra weight.
that would be also a wrong path. it may work now but it will fail in production. there is a folder for static assets, it is usually called /public. every static asset has to be in there: glb models, binaries, etc. the bundler or build tool will copy its contents into /dist, the output folder. it won’t copy from arbitrary folders and they’ll be missing when you build the site ready for upload.
It’s a nice convenient place to have reference to though, also bodes well for non bundler environments such as the official three examples but yes as you say in a bundled production would ofc fail…
seriously though, packages usually only contain runtime and otherwise declare their dependencies in package.json. it would contribute to slow overall dx and bloat if they didn’t. like if each package would do what three does node_module would weigh terrabytes.
it’s all a bit odd. i’m guessing it’s because the people that dislike tools so much still prefer node & npm to install three, then copy node_modules whole into their projects. and that’s why three needs to carry inlined dependencies. but they all live on npm
I don’t think it’s about disliking build tools as such but levels of access to all methods of using the library, in the sense that it can be included into any project from the old way of web development (including the most simplistic usage for beginners) up to the use of node and more complex production builds… i agree on your point that in the three npm package there may be excessive includes but one thing that doesn’t make sense when using npm to install three is that for every directory holding a project, every one of them needs to include it’s own node_modules folder, install of three as well as any other dependencies, so for example 10 seperate projects means 10x installations of three + any other node dependencies, this surely seems like way more bloat than simply downloading three once from source and using import maps to declare where that folder and other dependencies are, being a lot more minimal on storage resources… i guess it’s down to a plethora of factors such as if someone is completely new to programming for the web, what scale of project is being built, if just for fun or for production, what hardware resources are being used, if being included into a modern or old environment, etc. etc. etc. as a highly comprehensive web 3D library (if no the most) three seems to be preserving this inclusive accessibility for good reason…