[turnipla]

Hey that Makepad looks great. Too bad it doesn’t make my phone keyboard appear. You know… the same thing you get by adding a plain `contentEditable` DOM attribute.

Maybe reinventing the whole damn car on canvas isn’t a great idea either. I bet that the keyboard isn’t the only part that doesn’t work.

Flash was hated for this reason too: Breaking affordances. Imagine everyone reinventing their own UI framework on each app.

[echelon]

> Too bad it doesn’t make my phone keyboard appear.

I don't like this argument. It's like saying that because C++ can do everything, we don't need to build a new language to fix problems inherent with the existing paradigm.

Rust is just getting started, so give it time.

DOM is overloaded, messy, and slow. We need an application UI toolkit similar to what Android and iOS provide.

[danShumway]

I don't think the argument is that you could never make a keyboard appear with WebGL. It's that the speed increases and improvements you're seeing are due to the fact that there are about a thousand edge cases and alternative environments that these WebGL-based replacements have never considered. Anybody can make a demo that's faster than the DOM. I can make a native framework that's faster than GTK if you let my demo ignore all the things that GTK has to care about.

The problem is that by the time you've finished building a WebGL layer that has the same accessibility features and component-level controls and custom shortcut support and extension APIs as the DOM, it will no longer be a snappy, fun, fast experience. What you'll end up with is a second implementation of a web browser that runs on top of a web browser, and that has to be downloaded fresh every time you visit a new website.

WebGL and Canvas frameworks are fast because they allow you to build an interface that does fewer things -- that only worries about pushing pixels to the screen. They allow you to avoid adding the overhead of app-agnostic universal UI components with predictable behaviors, or accessibility layers, or custom font support, or universal shortcuts for scaling, or responsive layout support.

And sometimes you don't need that stuff. Sometimes you do only care about pushing pixels to the screen, or you're doing something very specific that allows you to avoid thinking about edge cases. But if you're going to universally replace the DOM, then you do need to care about edge cases.

Keep in mind, Firefox is also running in C/Rust and rendering webpages using OpenGL. It's operating on the same bare-metal layer. The DOM is already written in low-level languages and rendered out with OpenGL. It's not slower than Canvas because they used the wrong tech stack, it's slower than Canvas because it does more stuff.

I'm very excited about WASM as a replacement for Javascript. And to their credit, that's what the Rust team is doing. For the most part, the direction that Rust is actually going isn't towards WebGL, it's towards getting good DOM access in WASM.

The future of Rust/WASM mostly looks like people writing code in the language of their choice, with speed improvements based on the fact that the language isn't high-level or garbage collected, and then using that faster, more comfortable language to manipulate the DOM, just like we always have.