> The best way to be kind to the battery is to stay off the CPU when you have no useful work to do. If you are saving and restoring state at every loss and gain of focus because you might be killed by an overzealous app platform in between, you are burning more resources for nothing.
The original WinRT lifecycle never save/restored at every loss/gain of focus. It did exactly what you suggested and zeroed CPU usage at loss of focus. Best practices encouraged "save as you go", which most applications have moved to naturally as disk and network I/O got "cheaper". (Look at the history of auto-save across the decades in Office, for instance.) It forced applications to save additional restore state only at intervals after usage stopped (X minutes after loss of focus with no return to focus; -Y in the "alt+tab stack" MRU list of recently accessed apps), and it tried its best to merge restore state and deep linking as concepts (the only thing that "should have been needed" when forced to save/restore while doing "save-as-you-go" was deep link state). Post-web, deep linking is a critical tool and should be a default, if you are "burning more resources" to deep link you are probably doing something wrong, and that is what the platform tried to build on. At least in terms of the strictest best practices around the Windows 8 app lifecycle model, it seemed quite clear that it was very battery focused first and foremost (and yes, very tough). Windows 8 even had (and Windows 10 relaxed) very strict quotas on how much CPU, storage access, and other parts of what you could do to save/restore state towards the goal of enforcing the best practices that save/restore should be mostly deep links and other content saves done elsewhere in the application (presumably "save-as-you-go").
> So you cite what is pretty commonly regarded as a "loser" browser engine -- so much so even Microsoft abandoned it.
Just because it "lost" doesn't mean that it didn't exist like you strongly asserted, nor does it even mean that it was technically inferior. "Worse is better" is a Unix mantra for a number of reasons, but seems to apply here quite appropriately. Microsoft didn't abandon EdgeHTML because it was technically bad, they abandoned it because it was some version of marketingly bad and/or politically bad and no one was using it.
> I thought it was neither WinRT nor GDI. AFAIK a COM API in the style of DirectX.
This gets back to the "WinRT is just a subtly better COM" discussion and the ever so intentionally blurry space between DirectX COM and WinRT and the semantic games of who owns what. I think it's silly that more of DirectX COM doesn't have better native WinRT bindings because it's mostly just a difference of metadata at this point, but besides that DirectWrite is direct dependency in the WinRT stack, doesn't exist in non-WinRT versions of Windows, and is often considered to be a (low level) WinRT library more than a DirectX library.
Again, I think that only further serves my point that ignoring the app lifecycle and sandboxing, WinRT is a blurrier thing than the rigid box people think it is with more backward/forward compatibility with the Win32 world than both was apparent at first (especially in the Windows 8 era) and had there earlier been a more graceful path to opt in to the harder pills to swallow like the sandboxing and the app lifecycle then we'd probably have a lot fewer conversation today about whether or not WinRT was "capable" or was "missing features" from Win32.
(Yes, that also means that WinRT isn't also the extreme "clean" break from Windows Win32 legacy that people always assume it is. The walls are a lot blurrier today with more WinRT libraries than before providing direct Win32 COM access and XAML Islands, but removing app sandboxing the walls would have been a lot blurrier even in Windows 8's yesterday too.)
>> WinForms is a simple .NET wrapper around Win32. It's practically the same thing.
> Yes, I know, and this is why it's often more popular than WPF and its descendants. As I said, many later attempts end up with worse quality and shorter lifetimes than the earlier ones.
I feel like my point escaped you on this one. WinForms was never sold as a replacement for Win32, it was always just Win32. If it was marketed as a replacement for anything it was a replacement for previous Win32 RAD tools like VB6.
Silverlight was never marketed as a replacement for Win32. It was marketed as a replacement for Flash and Java applets (and HTML in some cases).
Two of your three examples were never meant to be Win32 replacements, so their "worse quality" (ymmv) and "shorter lifetimes" are irrelevant with respect to WinRT.
(Sure, you can bring up Windows Phone 7 where Silverlight was used as an application API stop gap in the brief period where WinRT wasn't finished but was the writing on the wall, but Silverlight was sold as a stop gap at the time and the expectation and admission was always that a "Silverlight-like" system would replace it in the next version, as it did, migration headaches aside for developing for a stop gap on the road to the next application framework.)
Also, "shorter lifetimes" is an interesting statement given that both WinForms and WPF are still supported in Windows, expected to be supported nearly perpetually, were just ported to .NET Core for many benefits and gains, and have a much increased access to WinRT libraries and XAML Islands. The future is bright for brownfield developers of WinForms and WPF. Sure, the general recommendation is still not to use either tech for greenfield work, but most companies go for "security and support" when discussing lifetimes and those horizons are still fine, there's nothing stopping greenfield work from happening in WinForms/WPF beyond "general recommendation".
Now, WPF was sold as a DirectX-based replacement for WinForms certainly. It's possible to see that as an implicit argument that it was meant to be a replacement for all of Win32, but of course WPF never entirely escaped the Win32 legacy as had been it's original predecessor's vision. I still often assert that WinRT is the fulfilling of a lot of the original WPF vision, and in that way that they are more alike than different, WinRT is a "final" version of WPF and the evolutionary tree of WPF, Silverlight (WPF/E), and WinRT a lot less choppy and/or internally discordant than a lot of people want to think. That comes down to aesthetic judgments like "worse quality"; I don't think that statement applies to the evolutionary tree like you think it does. WPF, Silverlight, and WinRT all have different niches/fitnesses in the evolutionary tree. But I also don't see Silverlight nor WinRT as "descendants" of WPF but that all three are descendants of the proto-WinRT (sometimes code-named Avalon), which was more WinRT like than not and it took a lot of evolutionary pressure to "finish".