mlsarecmg

This is a port, the original is here: https://github.com/pmndrs/racing-game It uses cannon-es (physics).

React-three-fiber is a renderer for Threejs but does not introduce overhead. Games and webgl is loop driven, so React solves that with a hook, useFrame, which binds components to the render-loop in a managed way. It could in theory outperform Threejs because it can schedule: https://twitter.com/0xca0a/status/1383165072554532865 or scale quality: https://twitter.com/0xca0a/status/1407371461447368705 These things would require a framework around Threejs.

that is not what is happening here. you can see the real difference here: https://twitter.com/0xca0a/status/1282999626782650368

it allows you to create self-contained components. that alone will eradicate so much boilerplate and complexity. it has a real pointer event system. it takes care of managing the scene reactively, it disposes of objects it does not need any longer.

you use this for the same reason you would use react for the dom. r3f is not a wrapper that duplicates the threejs export catalogue, it is a renderer/reconciler.

r3f does not have a performance overhead, it is literally zero. rendering is done in threejs purely, react only takes care of managing the scene. but it can, in situations where the app faces a lot of load, outperform three easily, because it is scheduled, just like a virtual list outperforms a generic list.

These apps all fall flat, which is the point i'm trying to make. They're robust from a design perspective, the tools we have to build UI are good enough, but they can't compete against native. Do you think that using Svelte in any those would make a difference? This is why React is attempting to find a solution.

The problem is essentially the same. Native apps are also conflicted with load, they have better means than we have on the web to deal with it, but it's still low-level and complex to orchestrate, threading for instance. Any one of those means pushes your app into async issuee, race conditions that you need to reconcile. With concurrent mode scheduling is a first class concept, your components won't be subject to race conditions. React maintains 60fps, high-priority content (user input, animations, transitions) can be ran fluidly while lesser priority content gets deferred. It has a good chance of outperforming multithreaded native apps with that model.

This demo illustrates the issue: https://youtu.be/nLF0n9SACd4?t=172 which is universal. You run into this on native platforms as well as on the web.

That is my point. They are robust from a UI perspective, but none them can compete against native due to the slow nature of the dom. This is why React is building a scheduler.

If you have an application that renders more items than Svelte can handle (not many, we're in the web, you have 15ms max per frame, on a single thread), it will simply keel over and die. Scheduling is natural in native systems, you have occlusion, prioritization and threading of course. Svelte has no means whatsoever to counter load.

With what React is attempting currently your app will render as much as it possibly can while maintaining stable 60fps, the rest gets deferred while it can differ between lesser and higher-priority updates. If you doubt how important scheduling is, look at practically any feasible list component, they're all virtualized. With React every aspect and corner of the application is like that. In theory it could outperform native apps.

Btw, there are countless of robust desktop apps being made with HTML: VSC, Whatsapp, Skype, Spotify, Notion, Hyper, Discord, Slack, ... thought most of them will still feel sluggish compared to a native counterpart. React will change that.

Learning the language is one part, but what enables you to make an application are patterns and paradigms: inflating, mvc, mvvm, immutability, functional. These work for all languages, you learn one once, you can apply it everywhere. It just so happens that maybe every 10-20 years a paradigm replaces another. Since i started writing code in the 90s this happened maybe three times. As far as i am concerned all this ever-changing js fatigue talk is complete rubbish. Even the tooling, we're using the same tools that we used 5 years ago (Webpack, Babel, TS, React, Jest, ...). Microsoft/Apple change their platform toolkits quicker than that!

Class lifecycles being replaced by hooks is a radical but much needed change. Learning it isn't complicated and it will enable you to venture on as everything around you sheds the class based component approach. Swiftui, Vue, Svelte and ofc React are just the beginning.

useMutableSource fixes these concerns. they all will light up green. some have it already as a draft or experimental, for instance zustand: https://github.com/react-spring/zustand/pull/160

with concurrent mode i think of what could be, web applications that can compete against native for the first time. as well as making making components that are resilient to async issues / making async a high level concept. there's a little churn for sure (for library devs, and a specific subset), but imo completely worth it.

this doesn't make any sense. cra is webpack, but in a way that doesn't blow up every week. you can use react without bundlers, but what is the point. you'll be sitting there, without a dev env, no hot reload, no module resolution, minification, types, jsx, babel, ... any single one of these will get you 1000+ packages on the dev side. none of this is going into the published build of course.

Yes, but it scales with the environment and device capabilities. Watch this, it explains it in detail: https://www.youtube.com/watch?v=nLF0n9SACd4

You can. This is what the demo does. The scheduler takes that amount and schedules is, which is the point. Every game engine does that (for instance frustrum culling). Games face an impossible amount of data, and schedule it. This is also true for native dev where you have priority dispatchers and threads. What React does is exciting because it schedules at the very root.

React has hooks. They are essentially algebraic effects. Check out some of the demos here: https://github.com/react-spring/react-three-fiber and look for "useFrame".

useFrame binds a single component to the render-loop. But in a managed way. Once the component unmount, it's getting taken out. You can also stack calls like that with something like a z-index, which is awesome for effects.

This game uses some of it: https://codesandbox.io/embed/react-three-fiber-untitled-game...

Check out this: https://codesandbox.io/embed/react-three-fiber-untitled-game...

Or some of the other demos here: https://github.com/react-spring/react-three-fiber

React lends extremely well to games, especially with hooks. Now you have reactive components, but also algebraic effects.

Concurrent mode lets React render asynchroneously. It will batch updates and schedule render passes. If you give it an impossible amount of load, so many render requests that it must choke, it will start to manage these requests to establish a stable 60/fps by updating components virtually and letting them retain their visual state, using back buffers, etc.

It contrasts how web frameworks and even native frameworks work. Native has prioritizing and occlusion, but i know nothing that schedules as deeply as this.

The demo in particular schedules a react renderer for threejs (https://github.com/drcmda/react-three-fiber). But it applies to any other target as well.

Npmtrends is a pretty good source: https://www.npmtrends.com/react-vs-vue-vs-@angular/core-vs-@... Vue has carved out a huge piece of the browser market, but it appears to have reached its peak.

React is hard to stop at this point as it swept over to other platforms. If it really gets to drive platforms with a single component standard and a unified events system, on the web, ios, android, windows, mac, linux, then i don't think a web framework will hold against this much longer tbh.

Why separate something from state, just to mix the view with pseudo code and injected state again. That isn't what separation of concern meant. React separates state from the view, because both should be apart, but the view and the code that forms it belong to the same logical layer, called the view layer.

It never did squish styles into a monolith. Strangely, that is exactly what Vue does with SFC, do you use Vue without?

The reconciler that makes this possible: https://github.com/react-spring/react-three-fiber/tree/3.x

And the small node tool that converts GLTF blobs into reactive, declarative markup: https://github.com/react-spring/react-three-fiber/tree/3.x/t...

React bindings are ready for testing: https://github.com/drcmda/react-zdog :-)

It's more like a performance test really, each "particle" is actually a React component animating its own course, just to see how far it can go. Makes for a cool effect anyway. Full code: https://codesandbox.io/embed/387z7o2zrq

I googled that, looks like an issue in FF: https://github.com/mrdoob/three.js/issues/9716 Basically i just channel through regular three without creating much of a dependency. If it doesn't work in react-three-fiber, then i doesn't work in threee-js. But they're so big that usually these webGL bugs are either fixed quickly by them, if it's their fault, or they're filling vendor issues.

Glad to hear that. If you need anything, ping me on github, i'm open to add functionality.

That would be one of the things i would love to explore. Does three do this automatically or is there something the app needs to specifically calculate?

I ran it both in Chrome and Firefox, seems to be working. Could i bother you for error logs?

This we had in place, but without react driving the scene we used manual Redux subscribes. Every change meant figuring out what part of the scene graph needed to be added/removed or changed. Basically the same problem one would face with jQuery and the dom.

I just started a week ago, didn’t polyfill the demos, but will do it when i get around it, nothing in there that wouldn’t work in FF. Would be super happy for GH issues (for instance error logs).

with managed i mean that the view is now merely a reflection of state. Basically just like with the dom:

    {condition && <div>hello</div>}

The div is there as long as the condition is true. But of course it can now also be a mesh, or a component that can clean itself up after the unmount.

We did this manually before, which usually meant watching out for objects to remove themselves, they'll have to communicate up their hierarchy to inform parents and so on. This wasn't straight forward in three, so there was a lot of prototype hacking and terrible things like that, i'm so glad this will be all gone.

Hey that's amazing, and your tool is really advanced! It's exactly the purpose of this, we're making a cad system as well and it's been hell with the current way of how we chose to do it. We're using redux and getting the scene graph to adapt with manual subscribers - it's led to something that is very hard to understand. That is why i'm writing the reconciler now.

The benefit of using tags (jsx) is that objects become fully managed. The most clear indication to me is still effects. https://codesandbox.io/embed/mo0xrqrj79 You can drop that in and it works. Make it conditional and once it gets unmounted the render loop goes back to normal. Almost magic, but then again, react for the dom had the same benefits.

I do a lot of 3d stuff at my job, first openGL, then three, but it's too easy to make a mess with the inflating approach and unmanaged variables everywhere. I hope this will make a difference.

PS. Full code for the demo: https://codesandbox.io/embed/ly0oxkp899