Hacker News new | ask | show | jobs
by sktrdie 2243 days ago
I'm a total newb with GPU stuff on the web. But am curious why aren't these GPU frameworks used to render most website? Things such as facebook for instance I imagine would be a lot snappier. Am I missing something?
5 comments

Lots of reasons.

Font rendering for all of unicode is extremely hard.

https://gankra.github.io/blah/text-hates-you/

Multi-language input is extremely hard

https://lord.io/blog/2019/text-editing-hates-you-too/

Having to download an extra meg or 10 of code does not make your website responsive to start, worse if you're updating it constantly so you're users have to re-download that code every few days, hours.

Support for assistive technologies disappears. A page of HTML is relatively easy to scan for text to read or turn to brail or translate to another language. A screen (not a page) of pixels is not.

Similarly extensions all break. Extensions work because there is a known structure to the page (HTML)

UI consistency disappears. Of course pages already have this issue but it will be much much worse if every site rolls it's own pixel rendering GUI because none of the standard keys will work. Ctrl/Cmd-Z for undo Ctrl/Cmd-A for select all? Similarly maybe the user has changed those keys or is using some other assistive device which all works because things are standardized.

Letting the browser handle what's best for the device probably disappears. Cleartype for fonts? Rendering Text or SVG at the user's resolution (yes that can be handled by the page but will it? up to the site)

Password managers break including the browser's built in one. There's no text field to find so no way to know if this is the place to fill them in.

Spell checking breaks. Same as above.

Basically your site will suck for users if you do this. Some will say some frameworks will come up that try to solve all of these issues but that will just mean every pages is on a different version of the framework with different bugs not yet resolved. Sounds like hell.

Very good roundup! Thanks!

But don't you think there's a whole lot of apps that could benefit from being on a canvas rather than being slowed down by browser-stuff? Editors come to mind: CodeSandbox and VScode

Editors in particular, are worse for some people if they can't render Unicode text properly, have poorer rendering of fonts, can't be analysed by assistive tools such as screen readers and braille displays, and don't interact with OS and tools outside the browser the same way as HTML and native elements.

Sometimes a good compromise is to use canvas for rendering some things things on a page (the way Google Sheets does), but create HTML elements on top as needed for particular behaviour.

Because of browser support honestly.

Outside of grid-layout, there is nothing salvageable from the CSS layout engine that cannot be done better inside a programmable view such a canvas.

Give it 5 years or so for WebGL/WebGPU to standardize, and new UI libraries with a better layout engine and UI constructs far better than what can be built on top of HTML/CSS will show up.

Nobody thought we would take HTML/CSS as far as we have, but it has already served its purpose.

Your comment reminds me of this article back then: https://engineering.flipboard.com/2015/02/mobile-web

I think what we'll see in 5 years will be browsers using even more hardware acceleration/GPU acceleration for its rendering -- so it'll be entirely abstracted away from us. Obviously, direct canvas rendering will still be more performant.
I don't think anything will stop browser vendors from advancing the HTML/CSS standards, but I also believe that we will see the emergence of libraries that have a different opinion around layout declarations and core components. These libraries will benefit from browser vendors opening up the GPU with each new iteration.
I recently found out that Google Sheets uses Canvas for its spreadsheets. That's probably a part of why it's so performant.
Well, the browser already uses the GPU to render. The difference is how you manage state. A lot of web applications do that in a slow way by storing data in the DOM for example, or do things that require the browser to re-render the whole scene.

You could port FB to Canvas and it'd probably be faster until you add a ton of abstraction to give you what HTML does.

A few screws if you think websites need to be even more bloated ;)