3 ms·

What is holding back a UI framework for WebGPU? It won't have HTML but couldn't you just simulate a scaffold inside the WebGPU canvas?

by uoaei 4y ago

iainmerrick 4y ago
For most applications you'll want to do things like render text nicely, select text, copy and paste text, right-click to inspect, boost font sizes and change colors for accessibility, auto-translate to other languages. A lot of it is about text, I guess! Once you've re-implemented all that in a canvas, you've more or less built another web browser, so why not just use HTML?
- uoaei 4y ago
  Presumably the argument in this thread is that lugging around an Electron app just for HTML is overkill if you could put the same functionality in a much smaller package.
  - rezmason 4y ago
    Also, we may be able to create those packages from parts of browsers, which wouldn't be a re-implementation, and would benefit from the rigor of the standards. I agree that it would be kind of silly to then put this in the browser. Instead, I think it could be used to build the native target. And just to clarify my earlier statement, I'm not a fan of phasing out the use of the DOM in the browser— it has graceful degradation and accessibility features that are really important. It's more that there are people with existing Qt or JavaFX or Cocoa dependent projects, or whatever, who are now able to deploy to the web by implementing the UI layers in WASM/WebGPU.
- deleted 4y ago
  [deleted]
- mtrower 4y ago
  Alright guys, hear me out… Let’s build a browser inside of virtual assembly code that runs in a browser that runs on an OS that runs on real assembly code (sort of). We could run that on a physical processor, or in a VM (hey, maybe we could run that VM inside a browser that runs on…)
crazygringo 4y ago
Why would you duplicate the massive amount of helpful functionality and styling HTML+CSS already provides? What's the point? It's one thing to build panels and buttons for a video game. It's a totally different beast to build a text layout and editing and selection engine, accessibility and screen reader compatibility, clipboard support, date pickers and file dialogs, and ten thousand other things.
- et1337 4y ago
  Even in the current HTML + CSS world, everyone writes their own date picker, file dialog, combo menu, etc. in React. It’s no longer acceptable to use built-in browser controls.
- nmfisher 4y ago
  Flutter would seem to be a logical replacement (though admittedly last time I checked, there are big issues with Flutter Web on some of the points you mentioned, particularly around text selection and accessibility).
- jimmySixDOF 4y ago
  In this hypothetical 3D Application, made possible by WebGPU, the UI & Text elements are a part of the "video game" and need physics, animations, and xyz spatial controls missing from HTML+CSS.

What is holding back a UI framework for WebGPU? It won't have HTML but couldn't you just simulate a scaffold inside the WebGPU canvas?

by uoaei 4y ago

What is holding back a UI framework for WebGPU? It won't have HTML but couldn't you just simulate a scaffold inside the WebGPU canvas?

iainmerrick 4y ago

For most applications you'll want to do things like render text nicely, select text, copy and paste text, right-click to inspect, boost font sizes and change colors for accessibility, auto-translate to other languages. A lot of it is about text, I guess! Once you've re-implemented all that in a canvas, you've more or less built another web browser, so why not just use HTML?

uoaei 4y ago
Presumably the argument in this thread is that lugging around an Electron app just for HTML is overkill if you could put the same functionality in a much smaller package.
- rezmason 4y ago
  Also, we may be able to create those packages from parts of browsers, which wouldn't be a re-implementation, and would benefit from the rigor of the standards. I agree that it would be kind of silly to then put this in the browser. Instead, I think it could be used to build the native target. And just to clarify my earlier statement, I'm not a fan of phasing out the use of the DOM in the browser— it has graceful degradation and accessibility features that are really important. It's more that there are people with existing Qt or JavaFX or Cocoa dependent projects, or whatever, who are now able to deploy to the web by implementing the UI layers in WASM/WebGPU.
deleted 4y ago
[deleted]
mtrower 4y ago
Alright guys, hear me out… Let’s build a browser inside of virtual assembly code that runs in a browser that runs on an OS that runs on real assembly code (sort of). We could run that on a physical processor, or in a VM (hey, maybe we could run that VM inside a browser that runs on…)

crazygringo 4y ago

Why would you duplicate the massive amount of helpful functionality and styling HTML+CSS already provides? What's the point? It's one thing to build panels and buttons for a video game. It's a totally different beast to build a text layout and editing and selection engine, accessibility and screen reader compatibility, clipboard support, date pickers and file dialogs, and ten thousand other things.

et1337 4y ago
Even in the current HTML + CSS world, everyone writes their own date picker, file dialog, combo menu, etc. in React. It’s no longer acceptable to use built-in browser controls.
nmfisher 4y ago
Flutter would seem to be a logical replacement (though admittedly last time I checked, there are big issues with Flutter Web on some of the points you mentioned, particularly around text selection and accessibility).
jimmySixDOF 4y ago
In this hypothetical 3D Application, made possible by WebGPU, the UI & Text elements are a part of the "video game" and need physics, animations, and xyz spatial controls missing from HTML+CSS.