Remix.run Logo
▲ ivanjermakov 3 hours ago

First load took like 15s on iPhone 12 mini.

▲Benjamin_Dobell 3 hours ago | parent [-]

Definitely slower than I'd like, but it's probably worth noting there's a few things that make this demo much slower than it needs to be:

1. There's some stuff simply not well optimized internally. Working on these now e.g. there's unnecessary internal hierarchy on all nodes that only needs to exist on a small subset (related to border boxes, overflow etc.)

2. Eager shader compilation. There's some glass and blur shaders that are compiled on load. These really shouldn't be.

3. Godot 4.x on the web is always pretty slow to load. Time of first contentful paint (if you ignore loading screens) is nasty across the board. Godot 4.8 upgraded Emscripten, so there's actually potential to improve this quite a bit since it's now easier to dynamically load WASM (which is what we're doing extensively here). I'm unaware of any work on this upstream though.

4. THE BIG ONE. This demo is a bit of a monolithic beast. It doesn't just include Godot's implementation of React. You can reveal the code for any page in the demo, and edit the code live with an inline text editor. Genuinely bundled in this demo is a full TypeScript 7 implementation (based on Bun's Rust implementation) that type checks and compiles code to JS on the fly, and hot swaps components on the page live.

For the most part, this isn't designed as a performance demonstration, although there is a small section on repaints/relayouts. It's mostly just a demonstration of what's possible with the library.

Realistically, there's also the fact this is React. Its architecture is based on React Fabric (like React Native), so runtime performance should be pretty decent. But frankly, it's never going to be as performant as some alternatives — it's not really the primary goal of the project. I'm considering an alternate SolidJS front-end for improved runtime performance, but that'll do nothing for first load time, unfortunately.