3 ms·

As others are pointing out, most UIs are hardware accelerated directly or indirectly. Most "native" apps, are native in the sense that they use some some UI to

As others are pointing out, most UIs are hardware accelerated directly or indirectly. Most "native" apps, are native in the sense that they use some some UI toolkit that renders using the platform specific and typically hardware accelerated ui infrastructure. With webgl and wasm, those same toolkits can now work in a browser. As for accessibility, that is indeed a challenge. You would need to use some ui toolkit that supports accessibility features. Those of course do exist, browsers don't have a monopoly on accessibility. A related challenge is the integrating that with the browser properly so that the native accessibility facilities in your OS can do whatever it needs to do (screen reading, enhancing contrast, etc.). This is not a solved problem. But it sounds like it could be a solvable problem that would require some changes to wasm and webgl.

actionfromafar 4y ago
When you have made all these changes to the browser, is it even a browser then? More like a Javascript shim on top of native controls.
- necessary 4y ago
  Maybe not compared to what browsers were a decade or two ago, but I think the definition has changed. These days browsers are just sandboxes with convenient tooling for finding, downloading, and running arbitrary code. And I don't think that's a bad thing: that's what allows Photopea and Figma to exist in the browser at a moment's notice. Once you generalize the definition of browser, both ends of the spectrum coexist: from basic HTML pages to fully WebGL rendered WebAssembly apps.
  - actionfromafar 4y ago
    It's already that, but what I got from the OP was to add native controls, like what is necessary to (re-)implement accessability. (That builtin accessability mechanism of the browser itself won't do for various reasons.)
- jillesvangurp 4y ago
  Technically, it's a bit of a bait and switch. But one that has largely already happened. It's just that web developers have yet to notice. Javascript at this point is a legacy compilation target for stuff that hasn't been ported to WASM yet. WASM is getting better with every browser release. Likewise for webgl. It was perfectly fine for doing 3d games many years ago. It's just that we are stuck doing the same react/js/whatever crap that we've been using for the last decade or so. It's just awful how low the standards are for web UI. But it was never good enough for game consoles or mobile. At this point, it's probably easier to run a browser as a wasm program inside of a modern browser just to render some legacy web app from way back than it is to get that app working with modern browsers. Why even bother? Just run IE 6 in an emulated browser on an emulated windows 95. And probably it would be fine in terms of performance too. Javascript + css has always been a bit of a cringe fest in terms of capabilities. If you develop a UI that matters for a gaming console, a desktop OS, or anything else, you wouldn't use any of that. It's why native development is a thing for IOS and Android. The phones are fast enough to do web development. It's just that the whole space is too competitive for that to be even worth considering. So, maybe it's becomes a better browser without that?
Strom 4y ago
> most UIs are hardware accelerated directly or indirectly. To widely varying degrees. Some do a lot of work on the GPU, others use only the rasterization features, some only accelerate the compositing. This unfortunately means that using simple surface level terminology like GPU accelerated doesn't sufficiently describe what is actually happening so that we could make meaningful comparisons between toolkits. Ultimately I think what's needed is proper benchmarking of performance and measuring of battery life. A toolkit that uses GPU acceleration for a simple step might actually be slower than a full CPU implementation, because there is a cost to syncing your data between CPU and GPU. Also if the whole UI is rather simple, then even a solution that is built completely on the GPU might be slower than CPU, again because of the associated costs. If it takes 2ms to get everything set up on the GPU for a frame, then it doesn't matter if the GPU renders it in only 1ms vs 2ms on the CPU, as total time is now 3ms with the GPU vs 2ms with CPU only. It's a contrived example, but one that could easily happen without a focus on measuring.

actionfromafar 4y ago

When you have made all these changes to the browser, is it even a browser then? More like a Javascript shim on top of native controls.

necessary 4y ago
Maybe not compared to what browsers were a decade or two ago, but I think the definition has changed. These days browsers are just sandboxes with convenient tooling for finding, downloading, and running arbitrary code. And I don't think that's a bad thing: that's what allows Photopea and Figma to exist in the browser at a moment's notice. Once you generalize the definition of browser, both ends of the spectrum coexist: from basic HTML pages to fully WebGL rendered WebAssembly apps.
- actionfromafar 4y ago
  It's already that, but what I got from the OP was to add native controls, like what is necessary to (re-)implement accessability. (That builtin accessability mechanism of the browser itself won't do for various reasons.)
jillesvangurp 4y ago
Technically, it's a bit of a bait and switch. But one that has largely already happened. It's just that web developers have yet to notice. Javascript at this point is a legacy compilation target for stuff that hasn't been ported to WASM yet. WASM is getting better with every browser release. Likewise for webgl. It was perfectly fine for doing 3d games many years ago. It's just that we are stuck doing the same react/js/whatever crap that we've been using for the last decade or so. It's just awful how low the standards are for web UI. But it was never good enough for game consoles or mobile. At this point, it's probably easier to run a browser as a wasm program inside of a modern browser just to render some legacy web app from way back than it is to get that app working with modern browsers. Why even bother? Just run IE 6 in an emulated browser on an emulated windows 95. And probably it would be fine in terms of performance too. Javascript + css has always been a bit of a cringe fest in terms of capabilities. If you develop a UI that matters for a gaming console, a desktop OS, or anything else, you wouldn't use any of that. It's why native development is a thing for IOS and Android. The phones are fast enough to do web development. It's just that the whole space is too competitive for that to be even worth considering. So, maybe it's becomes a better browser without that?

Strom 4y ago

> most UIs are hardware accelerated directly or indirectly. To widely varying degrees. Some do a lot of work on the GPU, others use only the rasterization features, some only accelerate the compositing. This unfortunately means that using simple surface level terminology like GPU accelerated doesn't sufficiently describe what is actually happening so that we could make meaningful comparisons between toolkits. Ultimately I think what's needed is proper benchmarking of performance and measuring of battery life. A toolkit that uses GPU acceleration for a simple step might actually be slower than a full CPU implementation, because there is a cost to syncing your data between CPU and GPU. Also if the whole UI is rather simple, then even a solution that is built completely on the GPU might be slower than CPU, again because of the associated costs. If it takes 2ms to get everything set up on the GPU for a frame, then it doesn't matter if the GPU renders it in only 1ms vs 2ms on the CPU, as total time is now 3ms with the GPU vs 2ms with CPU only. It's a contrived example, but one that could easily happen without a focus on measuring.