4 ms·
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 co
by iainmerrick 3y 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 3y agoPresumably 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 3y agoAlso, 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 3y ago[deleted]
- mtrower 3y agoAlright 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…)