Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?
All development is 'just' re-solving an existing problem with better performance, or 'just' extending an existing algorithm to be more resilient, or 'just' implementing a legacy interface on a new platform.
There are lots of very obvious reasons that the web has the constraints that it does and describing them as 'unnecessary' adds literally nothing useful to that conversation.
Only this is "re-solving an existing problem with worse performance that we had decades ago (on native), but slightly faster than the previous speeds we achieved having it run with its feet tied".
(Where by "feet tied" we refer to the performance penalty imposed by having everything run on the web stack).
Clearly for some subset of people, "something" is missing for those native solutions (I can guess - portability, convenient 'moddability', etc) which they believe the standardization-reliant web can better address for them.
Decades ago, we had the Win32 API, which didn't even try to solve this—apps had to roll their own.
It was native on the Alto, as the primitives were implemented in microcode, which could be a FPGA nowadays.
Also Squeak and Pharo are implemented in Smalltalk.
That's not an actual problem people have. Nobody says "what I want is minimal MVC-style updates to a UI". What they want is a fast UI.
So an actual problem is e.g. "having a slow UI" -- and native GUIs solved it "decades ago" by being able to do stuff faster and with less memory and power compared to the web stack.
That said, there were several frameworks that allowed that, especially since MVC didn't magically appear with the web -- the concept originated with Smalltalk. And even "dumb" native GUI frameworks were much closer to the metal than the DOM, and knew how to repaint e.g. only the area of a widget that changed.
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.)
I think it's wise to keep ourselves humble -- few of us are blazing new trails, in anything that we do. And I agree that many so-called innovations are nothing of the sort. But if we reduce everything that we do to revision and extension, then the word "innovation" entirely loses meaning. Why would we want to do that?
As said above, it's not a distinction, thus it's meaningless.
Let me know when Windows gets 100ms install+load and I'll be interested in the rendering model. Until then... measuring install time in seconds, or minutes? You can hardly claim to be performance oriented.
The web is for disposable toys, uninteresting ones at that. All of Windows 3.1 could fit in less space than the Apple website. You're telling me a silent install of Windows 3.1 would take more time to install than...Some app to find local hookups by GPS?
Java was a pioneer with shipping untrusted code to users in a sandbox, but it turns out its sandbox wasn't secure, and there were other UI issues as well. (Similarly with Flash, though that was more of a mobile performance issue.)
To be fair, the early web had a lot of security problems. What we have now is what's left after a lot of hardening. And we still have a lot of security issues.
But anyway, if you use JavaScript this isn't really your problem. Browsers take care of sandboxing and deployment for you. Nothing wrong with building on the hard work of others.
I don't think "it's been done before" has ever in the history of progress been a good reason for something to not be reexamined and made better or easier to use.