On a positive note I bought my house with the money earned by their lack of attention.
On a positive note I bought my house with the money earned by their lack of attention.
E.g. React Hooks, Next.js 12 to Next.js 13, Vue 2 Options -> Vue 3 Composition, etc. NPM is a whole other issue.
The one constant in FE is JavaScript and now TypeScript. Likewise, the one constant with .NET's FE stacks is C# which has remained quite stable and in many ways influencing JS and TS. C# had had async/await and Lambda expressions before JS (not clear not me how much effect Microsoft had on ECMA working group's decisions).
Silverlight was their one big snafu, but even that was kept alive for quite some time.
Those of us that had a go at ASP, ASP.NET, ATLServer, ActiveX, Silverlight, WebForms, AJAX Control Toolkit, WebAPI, WebAPI 2, MVC, Core MVC, Razor Pages.
I'm not even sure why you're counting WebAPI in there since it's for writing REST APIs.
The graveyard of Node and JS technologies is orthogonal to the current burnout feeling in many Windows circles regarding Microsoft technologies.
To the point that, as I already mentioned a few times, I happened to do .NET Framework to something else ports, instead of the more rational migration to modern .NET.
You see the same in long time well known Microsoft partners like Sitecore, moving away from .NET.
Technologies change all the time in every stack; flavors come and go.
By the standard of the web JS ecosystem, .NET has been relatively stable.
I don't care what others do.
It is like kids on the kindergarten playground, arguing for who behaves better.
Same thing with most of Windows GUI frameworks MS built. They all use same rendering language/interface (xaml).
Doesn't matter how long they have been supported.
If by "They all use same rendering language/interface (xaml)." you mean a XML based file format to describe the GUI layout, you are right.
If on the other hand you mean a GUI description language that is compatible with zero code changes, then not really.
The Windows GUI tools definitely seem to be struggling. Developing native desktop apps is much rarer these days, so all the attempts to create a single toolkit for multiple form factors makes some sense. But that is actually really hard to do, and Microsoft is starting from behind when it comes to mobile frameworks.
FWIW, the last time I developed a native desktop app was WPF. I tried again recently, but my general takeaway was that you need full Visual Studio still to make it work.
To the point that many might still use Windows, but not necessarly Microsoft frameworks.
(1) Try how a default OK/Cancel WITH LAYOUT can be expressed in your idiom. If it looks ugly and convoluted, fix your design until you don't have that problem. (2) Try how a 'tools on the sides, resizable work area in the middle' works in your idiom. If it sucks, see (1). (3) Check how margins and borders are controlled and defined in your idiom. If it requires repeating '10px' 480 places all over your source, see (1). (4) Check if evenly spacing/sizing a bunch of similar components requires special handling for first or last element, again, see(1). WPF fails all of these, and several more.
Winforms especially is going on 20ish years?
How do you feel burned by them.
Given the mindshare iron grip Microsoft has over .NET ecosystem, it's able to dictate the Web Framework that most of .NET will use - which is now Blazor.
But now that Blazor SSR with Enhanced Navigation offers an optimal UX out-of-the-box, Blazor's going to become the only real future option for Web Development in C#/.NET. I wouldn't have considered it (for Internet App's) before .NET 8, but now its basically the only real future choice for creating any kind of new Web App in .NET (excl. CDN Hostable, SSG Websites).
Also your last point is quite frankly crack smoking. You can still dump out perfectly good dynamic content with Razor and MVC.
Silverlight's demise was inevitable along with the death of Flash and WebForms is a 20+ year old technology that was focused on retaining a Desktop App development model for the Web, an inferior abstraction which would have never lasted. Blazor is unlike either and delivers a great UX OOB.
> You can still dump out perfectly good dynamic content with Razor and MVC.
and you always will be, Blazor just has a superior component and development model, an official API for statically rendering components outside a Web Framework context and will eventually be what most of .NET will be using.
Feel free to use whatever makes you happy, we still heavily use Razor Pages + SSG for our (CDN hosted) statically generated websites + docs, but will be predominantly using Blazor for new .NET Web Apps.
On the other had MS gave Silverlight 10 years of support when they announced the death of the tech, MS couldn't do anything else about it. If they waited long enough they could have ported silverlight to wasm today. I think there was a company offering dev tools for compiling silverlight to js and wasm, not sure if they are still around.
MS has had a storied past when it comes to frontend tech, but rather than diverging and dying, what we seem to see now is convergence of a coherent technical vision (and some pruning as a result). They look the same on the surface, but the result is totally different.
The latest version achieves exactly what every strung-together implementation of a moderately complex SPA architecture has aimed for in the past decade: fast initial render, low latency interactivity, low server load.
They did it in a way that still plays moderately well with the existing JS ecosystem.
They did in in a way where everything you do can be airlifted to the desktop or mobile via MAUI Blazor Hybrid.
And some of the underlying pieces that are coming along to make this possible are incredible. (Go check out some of the stuff they're doing in the wasm/WASI space.)
That said, I personally wouldn't choose to build on MS tech.
Microsoft gave us TypeScript. I can't think of front-end tech with more care and attention given to it than TS. For over ten years!