This is hosted by and taken care of poimandres, a larger developer collective. We have revived other open source projects with questionable status, like cannon, which hasn’t seen a commit in 5-6 years. We are also involved in managing threes types.
Likewise, many people must have noticed that jsm/examples goes no where and is treated more like a dumping ground. We are supposed to copy/paste it into our projects and then adapt it, but that is not how most people have used it. Naturally that causes some friction as these classes and helpers were mostly left catching dust, some have issues and bugs that haven’t been fixed merely because someone might rely on it.
I was always convinced that jsm is one of the greatest assets three has. I hope this can help to move it forward even if it’s a radical move to just fork it. But that will allow it to receive more help, devs that rely on it daily can have stake - and overall, it goes into the hands of the larger community. That is, if that experiment works out.
Our main goals are:
Real, npm/node conform esm modules with marked dependencies
Class based, optimized for tree-shaking, no global pollution, exports instead of collections
for the unnecessary, negative PR around it for another initiative
Both here and on twitter you announce it more like an aggressive corporate takeover, and splitting three into “three community vs pmdrs community”, rather than just focusing on one community willing to add value to three (from my personal pov - it kinda feels more than ungrateful to the current maintainers of three spending their days on fixing other, essential issues.)
Regardless, extending examples (which, I mean, are called that way for a reason ) sounds like a great idea for people who use them in production - so it’s likely a good step towards safe modernisation of three.
How are you planning to address the inevitability of the files becoming out of sync? A lot of bug fixes and features will wind up being requested in the three.js repo. Not that it’s necessarily bad if they do but in some cases critical fixes or spec adjustments might only happen in the three.js repo. GLTFLoader and some of the WebXR example code is pretty monolithic and people who are contributing to the spec of those are maintaining and writing that code. Will there be an easy way to migrate those updates in? To that end I think I’d feel less comfortable using this stdlib version of some of those files if they don’t wind up including those contributions.
I don’t necessarily mean that as a negative but I am curious. I’m excited to see where this goes but fragmentation is a concern. I do think it would be good if three.js as a project would embrace other people owning the examples entirely so the focus can be on building out the core of the library.
good question, and i really don’t know. at this point a little bit out of sync is a better trade-off than unfixed bugs or features that never make it. the idea is generally that people get to make fixes and additions when they need it.
our libraries will completely move to stdlib, i can see that happen for things like spline as well, that way they have more control.
i fear about GLTF, we will have to streamline fixes. i don’t think this can be automated with auto-formatting, modern syntax and types.
I do think it would be good if three.js as a project would embrace other people owning the examples entirely so the focus can be on building out the core of the library.
i have been asking for this often. it’s not the intention to fragment, but sometimes it needs a little push.
we just have to address the way people use code nowadays. types, tree shaking, esm, modules, npm, bundlers, tests, in my opinion that is what it takes to make front end wake up to webgl.
It actually would be so awesome if three examples were actually recreated with r3f.
Although I think stdlib is more about ES6, tiny bugs, and node compatibility - and after some discussions on discord, also about just taking a bit of the maintenance burden of the three core team backs. That’s why it’s still kind of an awesome idea - wrapped in a few frustrated tweets
it would indeed be awesome, but no plans. this is just plain maintenance. similar to cannon-es. it has to be vanilla so that everyone benefits.
the problem really comes down to maintenance. it looks like 2 or 3 people maintain three + extras. maintaining something that big is taxing. it has about 400 open issues and 130 open prs. now we could have an alternative that invites more people to the review process so that these classes can move forward in a much quicker pace.
for the unnecessary, negative PR around it
for another initiative
) sounds like a great idea for people who use them in production - so it’s likely a good step towards safe modernisation of three. 
