I recall reading that Thrust II (running at 1000mph but somewhat closer to the ground) used analog meters so that a glance could get an approximate value and rate of change quickly and in a situation of heavy pilot vibration. I couldn't find the original article, but I found this breathless page from the manufacturer which alludes to this.
https://masterhorologer.com/2014/05/03/rolex-unveils-two-bes...
The mixture of client-side and server-side code that Blazor can allow in the same files gives me a very gut instinct feeling that "those who have forgotten the WebForms history, or worse the ASP Classic history, are doomed to repeat it". It's obviously different from both WebForms and ASP Classic and its use of Wasm is certainly a brand new idea that WebForms only wishes it had access to. It seems like a brand new mistake to me, because I still remember debugging ASP Classic and WebForms and Silverlight and "now even the client side JS of ~~WebForms~~ Blazor is no longer JS but a mini-.NET runtime in a Wasm box" doesn't sound like a good time in the long term maintenance future to me when Blazor apps become legacy apps. But some of that gut instinct may just be cynicism at this point.
.NET Framework is part of Windows. That means it is very stable and supported for a very long time. But it is also not possible to evolve it further. That is why the .NET team forked it to make .NET Core, which is cross platform and installs versions side by side. This is what evolved into .NET, most recently .NET 8.
That means "stable" as in "it is not going to change".
But from a developer perspective, binding redirects, brrrrrr.... Also, source-level framework debugging tends to break every so often. It is obvious their focus is on the new .NET.
Capture pattern [edit: I meant capture brackets] extraction. Could get one of them (?!) or nothing at all, but... never again. MS doc examples = no success, not SO, not various blogs.
