FAQs

How is it different from X?

Svelte GL

Svelte GL was an experiment in creating a WebGL component framework from scratch. It was designed for tiny JavaScript bundles, and it succeeded — the JavaScript for this New York Times story is less than 30kb zipped — but reimplementing all the features rightly expected by users of Three.js would be an impossible task.

Svelthree

Svelthree is an existing project that brings declarative component-driven development to Three.js. The two projects have many similarities, but ultimately have different enough ideas about API design that it makes sense for them to be separate.

React Three Fiber

React Three Fiber is a React component library for Three.js. It is a work of art, and Paul Henschel’s twitter feed, where he frequently shares examples of projects built with R3F, is required reading.

Svelte Cubed is inspired by R3F in many ways. There are however some key differences:

Note that these are written from the perspective of a Svelte Cubed maintainer; to get a clear understanding of the different trade-offs you should strive to become familiar with both libraries

  • Idiomaticity. R3F is able to render your scenes at 60fps because updates happen ‘in a unified renderloop outside of React’. As the performance pitfalls page makes clear (“don’t let React near animations”), it’s not recommended to use component props to frequently update objects, but rather to have a separate useFrame update that mutates refs rather than using React idioms like useState. In Svelte Cubed, you use the same declarative approach (including using Svelte’s built-in motion primitives) as elsewhere in your Svelte apps.

  • Component library versus renderer. Svelte Cubed is a set of components, which demonstrates how easy it is to build declarative interfaces around existing libraries. R3F is a renderer, which demonstrates the flexibility of the React paradigm. The relative merits of these approaches warrant a longer discussion than belongs here, but it’s a philosophical difference worth noting.

  • Treeshaking. Three.js includes a lot of stuff, and as a result it’s a fairly large library. Usually, you can cut down on the bundle size with treeshaking — for example, if you’re not using DodecahedronGeometry in your app, then as long as you’re using a modern build tool it won’t be served to your users in production.

    In R3F version 7 and below, that’s not possible. The reason is that elements like <mesh> and <dodecahedronGeometry> are PascalCased and looked up on the THREE namespace at runtime. Because of that, it’s not possible for a bundler to treeshake anything from the library — no matter how simple your R3F app, you will pay full fare. There’s a good reason for this design decision: because React re-runs your component code on every state change, any code like new THREE.Mesh(...) will re-run frequently, at great expense, unless you go ham with useMemo. By converting JSX elements to Three classes, R3F is able to avoid that.

    As of version 8, you can enable treeshaking by explicitly ‘extending’ the R3F element catalogue.

Paul was kind enough to respond to these points on Twitter.

Overall, R3F is more battle-tested and feature-rich. Svelte Cubed doesn’t yet have physics integrations and turnkey interactivity, for example. These things are planned for the future, but in the meantime if you need to build a WebGL app quickly and you already know React, R3F is the way to go.