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

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?

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

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.

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.

I think a lot of UI could benefit from use of 3D.

I am tempted to re-write personal site using this.

Also, how accessible is this content from the perspective of a screen reader?

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.