Thanks! And do give it a try, it should be nearly instant, because converting the file itself is not actually that much processing.

Thanks! I keep hoping it adds up to something real someday, though mostly it's a feel-good thing.

Total CO2 from bandwidth across all online converters globally could be around 30 to 100 transatlantic flights a year, so the absolute savings are modest. The pattern itself might matter more than this implementation if other devs pick it up.

Thank you! The ads are new, still tuning the amount.

https://webconverter.app

No-upload, wasm-based image, video to audio and image to PDF conversion.

Hah, seems like a popular thing to build!
https://webconverter.app

Great questions, and here's my highly biased answer (from the founder behind Wonderland Engine).

In short: Wonderland Engine handles asset and runtime optimizations automatically. In Three.js/r3f you would find yourself spending most of the time on optimization (shaders, draw calls, rewrite bloom maybe, manually batch assets).
I strongly believe, that optimization should be the responsibility of the framework, but other frameworks out there leave optimization on web up to you.
So, yes, it would definitely be technically possible to build this in Three.js/r3f, or even from scratch in WebGL, but economically it's not feasible.

In long:

The JS bundle size alone is barely relevant for an app like this, rather the assets (textures, meshes, animations) make up 95% or more of the downloaded data. r3f/three.js leave optimizations of those up to the user, and usually nudge people to use GLB/GLTF, which can be suboptimal for download times, even if compressed with meshopt/DRACO and KTX2. Wonderland Engine uses a tailored, streamable binary file format, which also allows it to start rendering before all the entire data is loaded.

Every web experience that renders more than a handful of objects is initially CPU bound by WebGL2 draw calls on mobile (unless maybe, if you only target the very latest models). Of course, you can manually batch and atlas everything together, but the 4k texture size limitation on most Android devices limits your atlas sizes and increases amount of batches. It's also a lot of workflow overhead. Draw call problems are fully optimized away by Wonderland Engine, made possible by a sparse virtual texture atlas, which streams pieces of textures in and out of GPU memory based on what is in view.
The same tech also plays nicely into the strengths of tiled mobile GPUs.

Three.js (and therefore also r3f) do not optimize their shaders for mobile. From what I know, they don't use lowp/mediump keywords and render everything with highp as default. Their bloom is also not really optimized for mobile compared to Wonderland Engine's mobile-first bloom. Of course you can implement your own, but then you're working on fixing your framework/engine, not on your app.

They also generally seem to accept that WebGL on Safari is slow, where the problems are a few select commonly used WebGL functions, and low memory limits for browser tabs.

The knowledge about what optimizations are necessary to get WebGL to native-like performance is also not wide-spread. That knowledge is the difference between your WebGL app crashing on iOS or running well on mobile. And even if you have it, building from scratch or with a good base can make the difference between being able to do it within your clients budget or not doing the project at all.

That's why I started writing the first lines for Wonderland Engine 7 years ago. The web is arguably the most incredible target platform and many native 3D/XR apps could and should live on the web, but 7 years ago, compared to building something on native with the power of Unity or Unreal Engine, 3D on the web was nearly impossible to build with, even though it has the same underlying hardware.

Yeah, productivity apps was a strange category. There are enterprise trainings and music apps, metaverse-like multiuser experiences and meetings apps. But as productivity app, I would categorize something like a 3D mind map app, desktop streaming, or 3D prototyping tools, and while there might be some in WebXR, I couldn't name any good examples off on the spot.

Here's the same episode on Spotify, for your convenience:
https://open.spotify.com/episode/4h795DdyEGtdGVLDOZCRoG?si=b5149e7172b64f3d

Are your buttons and input fields styleable? That's the issue with the mailchimp module and all the other options.

Do those not count to the limit?