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].
[0] https://www.youtube.com/live/gkJ09joGBZ4?si=KX9ZwfWTixj6r55Y...
Could you tell us how Threlte compares with React-Three-Fiber in terms of feature parity and performance?
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.
[0] https://threlte.xyz/docs/learn/advanced/plugins
[1] https://threlte.xyz/docs/reference/extras/interactivity
[2] https://www.youtube.com/live/gkJ09joGBZ4?si=KX9ZwfWTixj6r55Y...
[3] https://docs.pmnd.rs/react-three-fiber/advanced/pitfalls
Svelte was so intuitive and I naturally thought 3D environments could be efficiently managed was when I googled "Svelte + three.js"
Coming from PlayCanvas, Babylon.js I'm super excited to see the development of Threlte Studio. What I like about DREI is that it lays out everything like a directory but I was reaching for the familiar "studio tool"
what is the ETA for Threlte Studio?
(I've taken "Show HN" belatedly out of the title of this one now.)
https://docs.pmnd.rs/react-three-fiber/getting-started/examp...
One of my favorites is the image gallery. I modified this so that clicking on an image take you into another room (gallery).
https://github.com/pmndrs/drei is a collection of examples and helpers.
Most impressive to me is the one using a GLTF model, video textures on text, reflections and more. A standalone version is
But even more impressive is the sandbox showing the not-very-many-lines-of-code at
https://codesandbox.io/p/sandbox/ground-reflections-and-vide...
A lot goes into putting a layer on top of threejs and I have run a fair number of head scratchers. But still the potential is huge. Using threejs has completely changed the way I look at website development. So if you are a svelte person I would definitely look into this. [edit for grammar]
I'm curious to hear about the changes.
A web app has two parts - navigation and tasks. What if I make it NAV forward? With google maps (or world) you get a picture of the whole world and you can easily navigate anywhere. Zoom in to 1512 Shattuck Ave, Berkeley, CA. Now zoom way out and go to New York City.
Why not build a tree map of the all tasks and places in you app that duplicates that map experience. When someone arrives at the website they see a tree map of the whole site. They can find a location: post in the group or add to the calendar or ... And perhaps after first visit you add a new place in the tree map for recent places or favorites.
When you find the place, there is a very limited, task specific overlay. Record your post then drag it onto the map? Write an email then drag it.
Question: does {grid, flexbox, floats, bootstrap, tailwind, material ui, etc} - present a better user experience than threejs?
Question: are there some places in a website (like navigation) that would be more effective with threejs?
And remember the big reason we don't use threejs. SEO [edit typos, clarity]
I was working on a proof of concept log viewer for example. Say each session has 10 logs, and esch of them is success, failure or netural. Instead of having something like
Session 1 - log one, log 2, log 3... Session 2 - log one, log 2, log 3...
I rendered all the logs in a session as being "behind" eachother, with a slight x,y offset and gave them colors, which you could then scroll through in the "z" axis. It's pretty nifty way of conveying more information in the same amount of space.
99% of websites don’t need threejs. But there’s a segment where it is a very useful tool.
For example any serious shop that provides appliances and furniture customization.
The same goes to car manufacturers. Even premium brands fail to deliver a nice immersive customization experience. And this is despite having all models with excellent quality due to the manufacturing and design.
The story is old as the world: always use the right tools for the job. Sometimes it is old school HTML, sometimes it’s ThreeJS and web assembly.
I think a lot of UI could benefit from use of 3D.
https://github.com/ando818/chess2
Codes probably bit messy but you can see the rendering of the board and pieces here. https://github.com/ando818/chess2/blob/main/src/routes/Board...
I found some 3D model files that came with the board and pieces in one gltf file, which threlte makes easy to extract out the nodes. Svelte reactivity also makes it super easy to move/position/scale/animate things, its just plain JS!
I was going to make a "Chess lounge" in the next iteration where you could walk around and watch other people playing in a cafe, but my interests moved on.
There isn’t much content though.
I have a habit of turning on NVDA, Android Talkback, etc. quite frequently to test when I'm working on a website, but even then, there are big differences between screen readers and a blanket statement of accessibility is completely worthless. People frequently tell me that something I tested on several Windows/Android devices doesn't work on Voiceover despite following the relevant standards. It's like browsers in the IE6 era, you need to explicitly test with as many as you can. And yes, it sucks.
Cool, but use with caution. The usual warning for graphics-heavy web stuff.
I agree with the sentiment and generally advocate for lighter and simpler webpages, but the 3D animations on this particular landing page were perfectly smooth on my 12 year old macbook. I was impressed, since these kinds of heavy animations usually run like crap for me.
what are they, in your words?
Disclaimer: I use React/React Native for the frontend at work, SvelteKit for quick prototypes, and R3F or vanilla ThreeJS when playing with 3D in the web. My days of working in ThreeJS for contracted work were long before R3F or even Svelte itself was a thing.
If you want to do declarative 3D and components without Svelte and React though there's always A-Frame or X3D.
I wonder if anyone really wants declarative 3D though. X3D/VRML has been around for 25+ years, and A-Frame for 8 years, and neither have become very popular (and several other formats came and went). Meanwhile three.js and imperative/procedural 3D generally is doing really well. I'm curious as to why that is.
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.
[0] https://webkit.org/blog/15162/introducing-natural-input-for-...
https://svelte.dev/repl/add20a88524c4f83aaeecbd7d873e731?ver...
There's likely an opportunity to do some abstraction here since it's a little clunky, but I've been holding off for the moment since these features are pretty new. We could potentially update the docs to make it clearer that this kind of configuring is possible. If you have any suggestions for either abstractions that we could add or more clear docs then don't hesitate, I'm all ears!
Also, how accessible is this content from the perspective of a screen reader?
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.
For those who prefer a more vanilla approach, A-frame [1] is nice.
I am tempted to re-write personal site using this.
