4 ms·

Our rendering engine basically serves too many masters. It wasn't designed for what we're doing with it now, but it still has to support all the things people h

by _bxg1 6y ago

Our rendering engine basically serves too many masters. It wasn't designed for what we're doing with it now, but it still has to support all the things people have done with it in the past. This is why systems like Flutter, despite all their downsides, can be really snappy. They skip the DOM and all its baggage and just use their own "app-first" layout system.

ThrowawayR2 6y ago
Or we could go back to resource-efficient and lightning-quick native apps, like the good old days.
runawaybottle 6y ago
Is it entirely out of the question for browser makers to maintain the DOM abstraction and upgrade the underlying engine to operate like an “app-first” layout system? Take css translate3d, it forces the browser to use gpu to handle those transitions. At the risk of sounding even more ignorant, but could the DOM be pushed onto the gpu layer, where things happen so fast it doesn’t matter at all how often relayouts/reflows happen? Obviously it’s using the gpu to render, no doubt, but what is about website rendering that’s just that much slower than a 2d video game? I guess I’m describing React’s circumvention of the browser to some degree. Ideally, we want something like React gone, and implemented at the browser level.
- _bxg1 6y ago
  > could the DOM be pushed onto the gpu layer Some of it already is. The actual drawing-to-an-image happens on the GPU, so maybe that was a bit of a misnomer for me to point out in my last comment, but that's not the expensive part. Reflow is the browser deciding "here's everything on the page, here's all their CSS styles, and this one CSS style changed, or this new element got added, how does that affect everything else?" Thing is, you're welcome to pull everything out of that reflow process! Through transforms and absolute-positioning, or the canvas, or WebGL, or whatever. And things will be a lot faster! But now you're taking on responsibility for a lot of stuff. Many of the benefits, in fact, that cause so many people to build on the web in the first place. The web has the most powerful and flexible and expansive UI layout system in the world. It's just that that comes with a cost. The ideal scenario would be to have a "slimmed down" reflow mode that only does "app things" and doesn't get tripped up on "document things". However, that would be fundamentally incompatible with some parts of the web as we know it, and would fragment the platform. Here's an example of one of those weird pieces of baggage: https://wilsonpage.co.uk/preventing-layout-thrashing/ https://wilsonpage.co.uk/preventing-layout-thrashing/. The browser doesn't know what you're going to do immediately after mutating the DOM, so it has to assume the worst in some cases.
enhray 6y ago
An example to prove your point: Flipboard determined that our current rendering engine was too slow for their needs and implemented their own rendering engine on top of ours while retaining the rest of the browser infrastructure. [0] https://engineering.flipboard.com/2015/02/mobile-web https://engineering.flipboard.com/2015/02/mobile-web
- _bxg1 6y ago
  Yep. And as mentioned in the write-up, it brings lots of complications when it comes to accessibility. The same goes for SEO. It sounds like it was the right solution for them, but it isn't for everybody.

by _bxg1 6y ago

ThrowawayR2 6y ago

Or we could go back to resource-efficient and lightning-quick native apps, like the good old days.

runawaybottle 6y ago

Is it entirely out of the question for browser makers to maintain the DOM abstraction and upgrade the underlying engine to operate like an “app-first” layout system? Take css translate3d, it forces the browser to use gpu to handle those transitions. At the risk of sounding even more ignorant, but could the DOM be pushed onto the gpu layer, where things happen so fast it doesn’t matter at all how often relayouts/reflows happen? Obviously it’s using the gpu to render, no doubt, but what is about website rendering that’s just that much slower than a 2d video game? I guess I’m describing React’s circumvention of the browser to some degree. Ideally, we want something like React gone, and implemented at the browser level.

_bxg1 6y ago
> could the DOM be pushed onto the gpu layer Some of it already is. The actual drawing-to-an-image happens on the GPU, so maybe that was a bit of a misnomer for me to point out in my last comment, but that's not the expensive part. Reflow is the browser deciding "here's everything on the page, here's all their CSS styles, and this one CSS style changed, or this new element got added, how does that affect everything else?" Thing is, you're welcome to pull everything out of that reflow process! Through transforms and absolute-positioning, or the canvas, or WebGL, or whatever. And things will be a lot faster! But now you're taking on responsibility for a lot of stuff. Many of the benefits, in fact, that cause so many people to build on the web in the first place. The web has the most powerful and flexible and expansive UI layout system in the world. It's just that that comes with a cost. The ideal scenario would be to have a "slimmed down" reflow mode that only does "app things" and doesn't get tripped up on "document things". However, that would be fundamentally incompatible with some parts of the web as we know it, and would fragment the platform. Here's an example of one of those weird pieces of baggage: https://wilsonpage.co.uk/preventing-layout-thrashing/ https://wilsonpage.co.uk/preventing-layout-thrashing/. The browser doesn't know what you're going to do immediately after mutating the DOM, so it has to assume the worst in some cases.

enhray 6y ago

An example to prove your point: Flipboard determined that our current rendering engine was too slow for their needs and implemented their own rendering engine on top of ours while retaining the rest of the browser infrastructure. [0] https://engineering.flipboard.com/2015/02/mobile-web https://engineering.flipboard.com/2015/02/mobile-web

_bxg1 6y ago
Yep. And as mentioned in the write-up, it brings lots of complications when it comes to accessibility. The same goes for SEO. It sounds like it was the right solution for them, but it isn't for everybody.