Hi, I'm the author of Threlte, thanks for posting it! If you want to see what we're currently up to, here's the talk I just presented at the Svelte Summit Spring[0].
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].
React-three-fiber was and still is a huge inspiration and I can’t thank Paul and the other contributors enough. Afaik they pioneered this relationship between a frontend framework and Three.js.
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.
No problem! I just happened to finish the Svelte tutorial yesterday and I was curious if Three.js could be brought to Svelte.
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"
I can’t say anything specific, but it will be available only with Threlte 8 as it’s depending on Svelte 5. Threlte 8 is the focus of our development but we of course want to wait out the official release. Threlte 8 is already published as `@next` if you’re feeling adventurous and the Studio will follow that in some days :)
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 am not sure this works - it is an exploration of a concept, not a conclusion.
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 dunno about full 3D, but I can see a lot of use cases for using perspective in 2D for enabling 3D navigation/viewing of objects.
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
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.
MY prototype tree map nav element is 2D - a plane. You can scroll around and zoom in. It seems good to me. On the other hand, there is a level of complexity that I still do not really understand. What about a cube with a different tree map (or other?) on each face. A rotatable cube does not break the paradigm. (Or a dodecahedron for that matter.)
Another thing I am thinking about is how will the user transition "into" a place? For example, a user finds email on the tremap and now wants to send one. What is the transition to writing an email? The kind of transition is the part I am curious about.
I personally find the concept of going "into" a place most appealing. It makes intuitive sense to me. I zoom into a building in NYC and click on it and I am now "in the place". But the tech part of me says "oh just do an overlay, make the canvas div hidden and put up a little text entry form". Does it matter?
I suspect but do not know that keeping the paradigm => going into a place on the map => would be more engaging, comprehensible, user friendly than suddenly breaking the illusion. But I am just guessing.
clicking on a panel takes you up close. It is pretty easy to add a feature so that when up close another click goes "into the panel". To a room of other panels or objects.
]
I was trying to find that gallary one earlier but couldn't find it. Looks neat!
What I am thinking of its more of a mix of a traditional website with some 3D elements.
Every navigation doesnt have to be 3D. For my example, I just put keyboard events for scrolling through the different axis but the information for each logs below the scroller still shows it a regular table format once selected
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.
This is amazing! definitely giving me Yugop vibes. I totally see these tools shaping a whole new style of online media. It certainly has the potential.
Wow, I was poking around and found this demo app[0][1] showcasing Threlte v6. The Technical Outline, particularly the explanation of the simplified car physics, is enlightening. It's essentially a Trackmania clone complete with a track editor, using Svelte/Threlte's advantages to its fullest.
For me personally, I much prefer SvelteKit's routing/state management over React Router/Navigation and Redux. Reactive UI to accompany ThreeJS scenes is probably just as easy in both Threlte and R3F, though I would again prefer Svelte's slot props for composability. This project in particular (from what I can tell) was showcasing V6's new Plugin system, and using their `@threlte/extras` library along with the Rapier plugin. R3F is much better in that regard, with a larger ecosystem, but it's exciting to see Threlte get closer to parity with R3F and Drei's R3F libraries; I'll likely choose Threlte over R3F now if there isn't anything from the React/R3F ecosystem I need.
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.
Declarative 3D in the form of a framework integration for Three.js is extremely popular and I would argue/assume it's currently the most used professional setup for a Three.js site with the most popular one being react-three-fiber. The declarative nature of these frameworks allows for things to be easily reused which forms the basis of an ecosystem.
Frameworks like react-three-fibre are popular because beginners can assemble existing components without knowing much JavaScript at all. It's common to see influencers in the space say things like "build this configurator with only 6 lines of code!" This speed and purported ease of use is what makes these tools so popular, not the declarative nature of the code.
Threlte/Sveltekit/Tauri is a cool combo. Recently I tried out Threlte and this is what I've come up with, it's not the best optimised and all models are free on sketchfab, helps having a modern pc for my 3d game environment
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.
Syntax is really nice, I'm just as impressed as the first time I saw Three.js as JSX (via react-three-fiber). It's nice to know I have this option if I ever use Svelte + Three.
Dang, I appreciate how smooth the scrolling is! I feel like so often when a webpage has scroll-based animations they stutter and lag. I didn't realize how nice the effect could be when it actually ran at my monitor refresh rate.
Been using it for about a couple of years now. Everytime I look at the docs, there is a new extra. And legrisch is wonderful. Discord is quite active. Amazing toolkit and can't wait to see where it goes.
Looks promising. It would be nice if the XR components exposed more configuration options. For example I don't see a way to use the transient pointer of the apple headset nor the depth buffer of the Quest 3.
Hi! @threlte/XR maintainer here. Both of those features should be pretty easy to use with Threlte since the package exposes the underlying WebXR APIs. Here's a repl example with both transient pointers and depth sensing:
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!
Nice, the documentation seems a bit lightweight at first glance. It would be good if it went to show how the home page animation was created and how interactivity could make this framework useful.
Also, how accessible is this content from the perspective of a screen reader?
Thanks! Threlte is "just" offering a declarative way to express Three.js. If you know how the `<T>` component and its props and event handlers work, you can use the Three.js documentation for everything else.
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.
Could you please elaborate on your comment? Do you mean you tested this tool and it's not accessible, do you mean you are concerned about the tool not being accessible, or is there a problem with the website linked? The reason I'm asking is because it is possible to make a 3D website accessible and I'm curious if you have any more info on this particular tool.
It is not accessible, or at the very least makes no statement about accessibility. Also, pretty much the single major issue to any new GUI to be honest, so everyone should always bring it up first thing. You have to be able to use an interface.
I don't think a framework can make a blanket statement about accessibility unless it's a negative one. Even if the framework does everything right, user error can completely break accessibility inadvertently. All such a statement does is give people a false sense of security that they ticked the "accessibility" checkbox, leaving people dependent on a screen reader, Braille device, with a motoric navigation difficulty, etc. completely stranded.
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.
"It is not accessible" is not a fair statement. Accessibility goes way beyond "it's not readable by a screen reader" – and even that is in my opinion rapidly changing with AI accessibility tools. See my other comment[0] that touches this topic briefly. Sure, we want and need to provide better solutions, but a lot of this is done by developers and there's little we can do about that.
I get the appeal of this stuff from an aesthetic perspective, but it's woeful from an accessibility standpoint and it makes your website completely unusable on older computers and not-that-old mobile devices.
Cool, but use with caution. The usual warning for graphics-heavy web stuff.
> makes your website completely unusable on older computers
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.
I have a small pile of Android phones of various ages and price brackets (gotta test stuff, y'know). Throw in heaps of Thinkpads of a certain vintage. IME, it's the age of the software that predicts browser performance much better than hardware. A 6-year old flagship phone that's stuck on Android 8 is a hot mess, while another one of the same age and similar specs on Android 10 runs great. Not sure why, but it's a consistent pattern across all these devices.
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...
[1] http://chat.threlte.xyz
[2] https://twitter.com/threlte
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
[4] https://threlte.xyz/docs/learn/basics/scheduling-tasks
[5] https://github.com/threlte/threlte
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
https://bfplr.csb.app/
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.
MY prototype tree map nav element is 2D - a plane. You can scroll around and zoom in. It seems good to me. On the other hand, there is a level of complexity that I still do not really understand. What about a cube with a different tree map (or other?) on each face. A rotatable cube does not break the paradigm. (Or a dodecahedron for that matter.)
Another thing I am thinking about is how will the user transition "into" a place? For example, a user finds email on the tremap and now wants to send one. What is the transition to writing an email? The kind of transition is the part I am curious about.
I personally find the concept of going "into" a place most appealing. It makes intuitive sense to me. I zoom into a building in NYC and click on it and I am now "in the place". But the tech part of me says "oh just do an overlay, make the canvas div hidden and put up a little text entry form". Does it matter?
I suspect but do not know that keeping the paradigm => going into a place on the map => would be more engaging, comprehensible, user friendly than suddenly breaking the illusion. But I am just guessing.
[ And did you look at the image gallery example?
https://lx2h8.csb.app/
clicking on a panel takes you up close. It is pretty easy to add a feature so that when up close another click goes "into the panel". To a room of other panels or objects. ]
What I am thinking of its more of a mix of a traditional website with some 3D elements.
Every navigation doesnt have to be 3D. For my example, I just put keyboard events for scrolling through the different axis but the information for each logs below the scroller still shows it a regular table format once selected
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.
[0] https://github.com/grischaerbe/threlter
[1] https://threltemania.xyz/
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.
https://crusaders-ashy.vercel.app/
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.
For those who prefer a more vanilla approach, A-frame [1] is nice.
[1] https://aframe.io/
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.
[1] http://chat.threlte.xyz
I am tempted to re-write personal site using this.
[0] https://webkit.org/blog/15162/introducing-natural-input-for-...
[1] https://www.w3.org/TR/webxr-depth-sensing-1/
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.
[1] https://github.com/threlte/threlte/issues
[2] http://chat.threlte.xyz
[3] https://github.com/pmndrs/react-three-a11y
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.
[0] https://news.ycombinator.com/item?id=40212705
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.