legrisch

Apart from that with Threlte I personally practice documentation-driven-development, so ecosystem packages are exhaustively documented. If you're missing something, let us know via an issue[1] or on Discord[2].

Accessibility is a topic we didn't care enough yet to be perfectly honest. Accessibility doesn't stop at screen readers though, it's about contrast, size, colors, motion, reachability, and so much more that we cannot provide and are a consumer topic. Naturally WebGL apps suffer from being practically invisible to screenreaders. There are workarounds[3] but essentially this has to be solved by consumers of Threlte (devs) and hopefully by browser vendors at some point in the future.

If you want, feel free to contact me on Discord[1] to provide feedback on how you use Threlte in your company, I would greatly appreciate it.

In essence, react-three-fiber and @threlte/core offer the same base functionality, which is to offer a declarative Three.js API for an established frontend framework. The technical approach however is fundamentally different: React itself provides an API (called a react renderer) to "transform" JSX into any tree-like data structure, whether it be a Three.js scene graph, a PDF or mails. Svelte (as of now) doesn't have that, so we had to get a bit creative and make heavy use of the Svelte Context API.

With Threlte 6 we introduced the Plugin API[0] which you may use to inject code into any component that instances an object. It's a very powerful feature that we use for many of the common abstractions in @threlte/extras such as interactivity[1] and which opens the door to more technically interesting and advanced use cases like the upcoming Threlte Studio[2].

On performance: react again works fundamentally different and therefore react-three-fiber is recommending to not use props for fast-changing object attributes[3]. Of course direct object manipulation is faster, as less computation is lost in "interpreting" a prop, but Svelte is generally faster in doing so, so we do not recommend against it – simple apps (which is the majority) totally work with fast-changing props. Starting with Threlte 8 which will support Svelte 5, prop updates happen granularly, so we don't have to apply all props whenever a single one changes. I do want to emphasize that for more demanding apps you would use a pattern that is independent of prop update costs and no significant overhead of react-three-fiber or Threlte would apply here.

In Threlte 7 we introduced a powerful DAG-based task scheduling system[4] that not only solved long-standing flexibility bottlenecks but also is the technical foundation of many interesting future features and use cases such as fixed physics updates (that are still correctly queueing with other tasks), easily scheduling tasks before or other tasks (e.g. running things after a frame has been rendered) or making complex orchestrations of updates across the entire app.

In terms of ecosystem react-three-fiber is of course much larger, that is just the nature of react vs. any other framework. We do however offer solutions for the most crucial things like physics, animation, layout and XR. Our ecosystem is centrally organized in a mono repository[5]. By that we can ensure that changes to @threlte/core properly cascade through all dependent packages. Organisationally speaking, I put effort in making sure that Threlte is run and owned by a team right from the beginning to make sure it's long-lasting and doesn't suffer from a single sight on things.

In essence, we're busy with two things:

Making Threlte Svelte 5 ready. It's a bit more work for us than for most Svelte libraries/frameworks out there since we poked into the component internals a lot, for example to make event handling more effective or run Svelte transitions on components rather than DOM elements. A lot of these things are now built into Svelte 5 and others (like transitions) we have to set aside for the moment.

The other thing we're working on is the Threlte Studio. I'm not sure how to best describe it yet, but you could say it's an editor that let's you visually modify your code. It's extendable, so you can adapt it to your workflow. We're really curious how far we can go with this, so to stay tuned, feel free to join our discord[1] or follow us on x[2].