Hacker News Reader

Comment by spankalee | Hacker News Reader

The browser is a GPU-backed renderer.

At some point with your own renderer you have to implement a large part of the DOM, styling and rendering layers. And why should a text editor team have to do that?

I think a lot of teams would be better off by learning how to make faster web apps, where there's a subset of HTML/CSS that approaches a tree of GPU textures with layout and style on top. Do things like: use fewer elements, very simple CSS selectors, `contain: content`, `contain: strict`, or `content-visibility: auto` everywhere possible, use shadow roots, use a fast vdom-less template system, and a framework where each component is its own render root, use virtualization for large lists...

If you do that you can also ship a fast web app. And as VS Code shows by popping up in more and more sites, being an actual web app has some very nice distribution and reuse advantages.

View on HN

> The browser is a GPU-backed renderer.

That matters very little. By that logic, everything is GPU backed these days and rendered by a compositor, on all platforms.

> At some point with your own renderer you have to implement a large part of the DOM

No, not really. Unless you are saying "DOM" to mean any tree structure. And you might not even need that for your app, depending on its layout.

When people say "GPU rendering" in this context, think user interfaces found in games. They are directly rendered by the game code without any intermediate layers. And very often, without anything that one would even remotely recognize as a DOM (3D games have a scene graph, but that's still different).

> And why should a text editor team have to do that?

Ask Sublime Text and iTerm. They already do that to render their content (and implement native OS dialog controls for the rest).

> I think a lot of teams would be better off by learning how to make faster web apps

True, just because of the amount of effort. _Users_, on the other hand...

Being a webapp and adding GPU rendering are not orthogonal. Figma for instance famously renders it's UI in WebGL.

While I mostly agree that creators of today's web forget that there are a number of simple techniques to render fast pages, there are also a bunch of places where the HTML+CSS+JS web technologies serve us poorly.

* Content Editable is a terrible editing canvas

* Dom and CSS are pretty terrible core animation primitives

* DOM and CSS make for pretty poor interactive graphics capabilities

And in these cases WebGL offers some interesting alternatives to explore.

Figma renders its documents with WASM/WebGL, but the UI of the app is just HTML.

A fully GPU rendered web app is almost the worst of both worlds. You'll generally have massive code bundles and terrible a11y.

I remember when I first tried Flutter+Dart and was really put-off by how it rendered to <canvas>, then later versions did use the DOM but looked like the worst case of divitis I’ve ever seen, it even made React.js’s output look handwritten.

But why do people do this? I note that a big problem with the web, as-is today, is how anemic and inflexible HTML’s standard <input> elements are, which forces devs to build their own widgets (often poorly), maybe use a framework like Angular, and then eventually go all-in on web abstractions like Flutter/Blazor/etc. If HTML were better then many (but far from all) of these cases could be avoided - for instance, I don’t understand why HTML still doesn’t have absolutely basic widgets like a combobox, a single-line textbox that wraps, a date-range input, hierarchical drop-downs (optgroup is single-level), defined styling and non-text content of <select>, and so on… (though we did recently get color and range/sliders - though there’s still cross-browser quirks which hamper adoption).

I hated the days of ActiveX like everyone, but when you’re building an internal-only (I.e. IE-only) webpage it was neat that we could pull-in any of the standard Windows controls - and plenty others - into a page and it would just-work. And you got accessibility for free too, which is more than what you get with <canvas>-based frameworks still - or a multi-megabyte JS/WASM bundle download either (or an npm-based build system that breaks every time you update your dependencies…) ]. Okay yes I’m jaded.

Content Editable seems to be quite good these days, if you don't use it as is, but are willing to layer a framework on top of it. I tried Lexical, but am now going to roll my own, but still entirely based on HTML/CSS and ContentEditable. No WebGL required, although I might very well use it for a particular editing component.

> And as VS Code by popping up in more and more sites,

On Linux, VS Code can't even resize without glitching and showing unrendered portions of the window like it's 1999. Nor can it kinetic scroll. Those are two expected highlights of quality GPU-backed software.

Hopefully running in an actual browser would make this better simply because you can choose a browser that isn't Electron.

afaict, VS Code doesn't employ most of these modern techniques for faster layout and rendering. Last I checked they didn't have CSS containment or shadow roots anywhere, and they have very, very large DOM trees.

They're the classic example of jumping from unoptimized HTML/CSS to GPU to try to fix performance as they moved the terminal to be GPU-based, and it doesn't seemed to have helped because that introduced rendering bugs that would have been impossible with HTML.

I only use VS Code as an example of how many places you app can be used if it's web-based.

Reply on news.ycombinator.com