I know r3f can do this good, but it’s for React. troisjs is vue side implementation, but it is not well maintained.
you normally wouldn’t write scalable applications in vanilla. there is no principled architecture and basing app infra on classes will create a challenge to put it nicely. the web as a whole has abolished this practice long time ago to such an extent that the “vanilla app” is near extinct. it doesn’t mean you can’t make some blob or module vanilla, and then integrate it into your app, by all means …
as for vue, there are
“vue-threejs” GitHub - fritx/vue-threejs: Vue bindings for Three.js
“trois” GitHub - troisjs/trois: ✨ ThreeJS + VueJS 3 + ViteJS ⚡
“drie” GitHub - janvorisek/drie: Drie is a Vue 3 component library for THREE.js made with TypeScript and Composition API.
“lunchbox” GitHub - breakfast-studio/lunchboxjs: Custom Vue 3 renderer for ThreeJS - https://docs.lunchboxjs.com/
i have no idea which one is best, probably “tres”? not even sure how much it makes sense for web frameworks to drive threejs tbh. vue svelte et al don’t seem to have an easy time, looking at the attempts. as an end user your risk will be high, you’ll make an app, next month the binding might be dead, or gets rewritten from scratch.
and it isn’t just the framework, it is the eco system that makes a difference. writing
<foo> instead of
new THREE.Foo() is nice, but an eco system is what eventually allows you to rapidly move forward, and they are the hardest part to establish. pmndrs exists because react is not a web framework, it naturally lends to driving three, and fiber being not a binding but a renderer has guaranteed longevity. there’s no risk so people started to come together.
I think it’s fair to say that most complex web applications are built with a framework these days, such as React, Vue, Svelte, Angular, etc. Complex applications often mean growing teams with evolving needs, and it’s easier to find solutions to common problems like state management, and to hire people, if you’re using a framework that is already popular and has established patterns. Both are much harder with complex applications built without a framework, which tends to evolve quickly into a bespoke framework that no one else understands. People still do so — sometimes very successfully! — but it’s not the norm.
That said, many applications do get built using vanilla three.js inside of one of these frameworks, without using a declarative wrapper around three.js like R3F + JSX provide. You can have a principled architecture while writing imperative three.js code, that is both popular and completely OK. And, the less your project is shaped like a “web application”, the wider the range of ways people find to structure that.
Thanks for the reply, I’m a novice web and three.js developer switch from mobile development. I haven’t found a complex vanilla three.js open source example project yet, the demos I can found are all very “state easy”, they don’t need a state management framework at all.
Now I have a project with a bit complex states, built with vanilla three.js, I do bad on it, I don’t know how to make it better.