> And even "dumb" native GUI frameworks were much closer to the metal than the DOM
GDI wasn't "closer to the metal" than the CSS painting model was. It was reviled for not being close to the metal, in fact (which is why WinG and later DirectX were so important). On Windows NT you had to take a context switch to kernel mode to issue painting commands—how can that be "close to the metal"?
> and knew how to repaint e.g. only the area of a widget that changed
Browsers have been doing this for over a decade.
Actually, I think they should largely stop doing this, since in a double buffered scenario (which has been the norm since the Vista era) partial repaints become complicated, and GPUs are so good at blitting a window-sized area that it's really a non-issue. What are issues are state changes and overdraw, which native frameworks are exceptionally bad at minimizing (this is largely why Skia-GL is underwhelming on Android) and the declarative CSS model is good at supporting. Native frameworks such as Win32 and GTK are held back by having to support this obsolete model. None of the Win32 designers could have imagined that Z-buffers and early fragment tests would become universal.
A meta-note: Pretty much without fail whenever anybody has mentioned some specific thing that Web browsers supposedly fail to do that native can do (the incorrect idea that browsers don't do partial repaints being just the latest instance of it), browsers have been already doing that thing for years. This indicates to me that most people who complain about "native" vs. "Web" haven't really looked into how the Web works. I'm all for acknowledging the Web's shortcomings, but let's concentrate on real issues. (In my view, legacy browser design, which is largely the direct result of trying to be "native", is the biggest problem, not the Web.)
GDI wasn't "closer to the metal" than the CSS painting model was. It was reviled for not being close to the metal, in fact (which is why WinG and later DirectX were so important). On Windows NT you had to take a context switch to kernel mode to issue painting commands—how can that be "close to the metal"?
> and knew how to repaint e.g. only the area of a widget that changed
Browsers have been doing this for over a decade.
Actually, I think they should largely stop doing this, since in a double buffered scenario (which has been the norm since the Vista era) partial repaints become complicated, and GPUs are so good at blitting a window-sized area that it's really a non-issue. What are issues are state changes and overdraw, which native frameworks are exceptionally bad at minimizing (this is largely why Skia-GL is underwhelming on Android) and the declarative CSS model is good at supporting. Native frameworks such as Win32 and GTK are held back by having to support this obsolete model. None of the Win32 designers could have imagined that Z-buffers and early fragment tests would become universal.
A meta-note: Pretty much without fail whenever anybody has mentioned some specific thing that Web browsers supposedly fail to do that native can do (the incorrect idea that browsers don't do partial repaints being just the latest instance of it), browsers have been already doing that thing for years. This indicates to me that most people who complain about "native" vs. "Web" haven't really looked into how the Web works. I'm all for acknowledging the Web's shortcomings, but let's concentrate on real issues. (In my view, legacy browser design, which is largely the direct result of trying to be "native", is the biggest problem, not the Web.)