I have been slowly transmuting my typical React web apps into threejs/fiber&drei things. This has worked well. Very, very well. The proportion of three/f//d code to React code I write has completely reversed. It appears that I now use React mainly for hooks. So 3/f/d + hooks + text input => a functioning desktop app?
The simplest way I know of now to use three/f/d on a Linux desktop is Electron, etc.
It occurs to me however, that I have a GPU, a ton of software that provides an OS layer, an application layer, a browser layer, wrapped in an Linux application,that then allows me to draw with the GPU. That does not really make sense.
I know there are hardware drivers, Cairo, Chrome, expo_gl, node-canvas, Electron, GTK+, etc.
Is there a way, or a way to build a way, to run a three/f/d application without all the layers, and especially the chrome layer?
And as a bonus question, if one finds a way to run 3/f/d without a full browser, is there a way to get the benefit of hooks without full React?
I realize this is a poorly formed question and that I donât know what I donât know. So thanks for any thoughts.
Reactâthreeâfiber (and its helpers like Drei) work by letting you describe three.js scenes declaratively using React. In doing so, they rely on a full React runtime (with hooks, reconciliation, etc.) plus a browser (or browserâlike) environment that provides a DOM, event handling, and a WebGL context.
Removing âthe chrome layerâ:
While it might seem wasteful to wrap a desktop app in layers such as Electron (which bundles Chromium) when you only need GPUâaccelerated rendering, those layers provide critical functionality. For example, they supply the WebGL API, window management, and a JavaScript runtime that React and three.js depend on. In theory, you could build a leaner system by using a minimal OS windowing layer combined with a native OpenGL (or headlessâWebGL) context (e.g. via libraries like headlessâgl or using ExpoâGL on some platforms). However, doing so would force you to reâimplement many features that browsers and React already handle (like event loops, the DOM, and hook reconciliation). The practical tradeâoff is that these browser wrappers, though âheavier,â let you work with a familiar, wellâsupported ecosystem.
Using hooks without full React:
React hooks are an intrinsic part of Reactâs runtime. They let you manage state, side effects, and lifecycle behavior in a predictable way. If you try to run your threeâf/d code outside of React (or without the full browser environment that React expects), youâd lose that builtâin hook system. While you could âroll your ownâ hookâlike system, it would essentially be reâcreating a miniâReactânegating the benefit of stripping away layers.
In summary:
The most practical solution remains to use a minimal browser wrapper (like Electron, Tauri, or NW.js) on desktop. These provide the necessary environment for React, reactâthreeâfiber, and WebGL to work together efficiently. Building a custom solution to âcut outâ the browser layer would require a massive reâimplementation of many lowâlevel features, and if you still want the benefits of hooks, youâd have to bring back a Reactâlike runtime anyway.
Thank you very much for taking the time to respond to this. I have some goals without knowing how to achieve them and perhaps it would help to state those clearly
Provide an alternative to the current web experience. We use 3d graphics in games, but why not on the web? The superficial appearance is that we have a graphics chip with layers of software that abstract OS services - like linux, then a browser -like firefox, which is loaded with code so we can implement html and css based graphics. In my opinion html/css provides a worse user experience than 3d. If that was true (that 3d was better) would we achieve that by adding yet another layer?
The Linux desktop. Accepting the unproven and tested theory that 3d interfaces are better for users than 2D, then wouldnât the same truth apply to a Linux desktop? I am a fan of Linux and wish it had a better user interface, especially for some kinds of applications. (why canât my terminal window be on a cube I can rotate to get another vim window etc?).
By âbetterâ I mean more functional. An immediate example for me is navigation. âcd âŚ/âŚ/other/frogs/are/here.â Or multiple flat âDesktopsâ. But in 3d graphic land we have tiling map (leaflet) style navigation and can go any place in the world in one interface.
Maybe this is wrong headed but before I started doing more Electron stuff (sigh) I just was wondering if there was some better route!
Just to be clear the thought was more about taking the firefox or chrome code and removing vast portions. (Although that could easily turn out not to be feasible).
One uneducated guess: the effort to strip down a browser to a bare minimum that can run Three.js ⌠might be greater than to write such browselet* from scratch.
* browselet - I just invented this word to describe a stripped down browser
I thought it might help to clarify what I am thinking about with one of the first tinkerings about navigation. I took the imagegallery demo and added to it.
This concept of âroomsâ, and rooms in rooms, does not scale well to a 1000 rooms, but it still it is worth thinking about. For example could discourse.threejs.org be rooms?
My next effort, was how to use that kind of navigation with typical react pages. I made a room that takes a user back to react land, by transforming the canvas div into a burger menu icon. I donât have a demo but will try to get one.
The problem with both of these is that I want a navigation system that is capable of easily navigating massive amounts of data and a massive number of categories. The best paradigm for doing that is the leaflet.js and google maps tiling. Not geographical data, but for example everything on the threejs forum.
In the process I have ended up asking myself why I need/want/use react in all this. What does react/dom/css really offer that cannot be done with just threejs. I have ended up preferring react-fiber & drei as a platform instead of plain threejs. Partly this is due to the fact that I find declarative easier to reason about and more expressive. I did an experiment of creating a jsxToJson.js thing. I used lots of JSON in the kzoom project to describe the âroomsâ and âpanelsâ and straight JSON is hard to maintain. I can write the same thing in JSX and just generate JSON from it. So declarative.
I do not however think declarative is the only reason I am more productive in {fiber/drei} than {three}. My guess is another fuzzy thought about useHooks giving us hooks into rendering?
Very interesting and good to know about. And helpful. After reading âspeedier domâ I wonder if my fuzzy thinking is about understanding why web things are DOM centric. It seems to me that CANVAS should/could be at least equal? Why is a page, this page for example, more effective for users, than the same content presented in a {3js,drei,fiber} canvas?
It would be nice if blink was very modular and also, it would be nice to have it work well as a base for electron.
In order to decide write vs remove, I need to understand what would need to recreated. Like webrtc for example - a must have in my mind. There is a project for a rust webrtc here:
I was also in search for such software that could provide just the canvas element with no DOM/CSS stuff. In my mind it would be much lighter and maybe even faster if we could rely only on JavaScript and the canvas but with all available contexts to create and distribute browser games on desktops and mobiles. I donât like R3F and similar, so not having a DOM would not be a problem for me, but a benefit if that could optimize the performance of the application.
I havenât found it yet, but the next best thing I checked and liked was Tauri. The major benefit is that it does not ship Chromium under the hood like Electron does, but relies on a WebView preinstalled on a specific platform (so it would roughly be Edge on Windows, Safari on Mac and iOS, Chrome on Android and Webkit2GTK on Linux). Iâve tried it on Windows with 3 different canvas contexts simultaneously and it works flawlessly. None of those uses three.js, but I assume that wouldnât be a problem. What would be a problem is using it with WebGPU today on Linux and Mac/iOS which are not there yet. I guess we just need to wait for that.
Because of history! It was introduced in the middle of the lifecycle of HTML4. Before it, Flash was perceived like a toy. Serious s**t was done in documents (the âDâ in âDOMâ). Hell, even the <img> tag was included only in the HTML 2.0. And we all waited 'till 2011 for the first version on WebGL and thus being able to see some real 3D on the web. Iâm pretty sure no one expected for the web to become this popular, so the basic stuff (sharing documents) was implemented in the most strait forward way without relying on GPUs. LOL, they were not even that popular back then even for videogames, in fact, DOOM ran on DOS.
It was introduced in the middle of the lifecycle of HTML4. Before it, Flash was perceived like a toy. Serious s**t was done in documents (the âDâ in âDOMâ). Hell, even the