> 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.
This whole statement results from shoehorning the web inappropriately into an app model and only makes sense if you have done that mental gymnastics in precisely the same way. Nobody else did so nobody built WinRT apps.
The model works best for toy apps. This fits with other aspects to conclude they shipped something which was appropriate for demos written by interns but not battle tested like decades of win32 was.
> 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").
Yes, I remember some discussion of this in Redmond. It seemed very misguided. We are not talking about a real-time OS here where you can feel good about hard deadlines. And it's quite difficult to intelligently enforce those limits without knowing what useful work the application might do legitimately for the user. It is an arrogance and a denial of realities of things like the halting problem. And, it's been a while since I looked into it, but it seemed at one point like Apple and Google did a better job letting you react to being killed through similar mechanisms.
> This whole statement results from shoehorning the web inappropriately into an app model and only makes sense if you have done that mental gymnastics in precisely the same way.
Where have you been? The web has been the application platform of choice for a number of users and developers for nearly a decade now. Sure, HN is full of complaints about every Electron app under the sun, but the web "won". Most user expectations on how apps function come from the web these days. Mobile app platforms are full of deep linking and other web (and post-web) concepts.
> The model works best for toy apps. This fits with other aspects to conclude they shipped something which was appropriate for demos written by interns but not battle tested like decades of win32 was.
This is blaming the egg for the chicken. WinRT hasn't been battle tested for decades because it hasn't yet had decades. It's arrogant in its impossibility.
I have used some great WinRT apps that weren't "toys", "demos", nor "written by interns". At this point you just seem to be name calling for no benefit. I get it, you haven't liked what you have seen for WinRT. You haven't given many technical reasons, and this name calling continues to not serve your argument.
> at one point like Apple [...] did a better job letting you react to being killed through similar mechanisms.
Apple has basically the exact same quotas early WinRT tried to place on apps, Apple just has a lot more clout when it tells developers "Our Way or the highway".
Which again, continues to prove my point that if Microsoft hadn't tried to "force" developers to do the right thing, and instead offer more carrots and fewer sticks people would have a better idea of what WinRT actually is rather than just name calling at it because it forced them to learn new things and then was "mean" by requiring sandboxes and app lifecycles that actually tried to be user friendly, you know just like Apple was already doing with iOS years before WinRT released.
This whole statement results from shoehorning the web inappropriately into an app model and only makes sense if you have done that mental gymnastics in precisely the same way. Nobody else did so nobody built WinRT apps.
The model works best for toy apps. This fits with other aspects to conclude they shipped something which was appropriate for demos written by interns but not battle tested like decades of win32 was.
> 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").
Yes, I remember some discussion of this in Redmond. It seemed very misguided. We are not talking about a real-time OS here where you can feel good about hard deadlines. And it's quite difficult to intelligently enforce those limits without knowing what useful work the application might do legitimately for the user. It is an arrogance and a denial of realities of things like the halting problem. And, it's been a while since I looked into it, but it seemed at one point like Apple and Google did a better job letting you react to being killed through similar mechanisms.