.NET Blazor

What a weird post. How is that not your actual attitude? All of these things are worthwhile to learn. (I'm assuming you're being sarcastic.)

The article (which basically says Blazor is a bit cumbersome and pointless) has plenty of truth (and a few half-truths) to it but it's assuming that you're using it in a context where pure js + html would just be much better for the end user (wait, isn't pure native better for the end user..).

What it doesn't really tackle is the productivity from the developer perspective, very little mental context switching, code re-use/sharing with backend models etc (api models, validation etc) and the surprisingly productive nature of the Razor templating language. It's a combination that makes sense for developers, less so for end users. Most end users for these apps will be corporate intranets (love that the article mentions SEO, yeah right). When these same corporate users were using monolithic WPF apps, did anyone care then? If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.

Consider if the same Devs opted for react or angular etc, would the end users actually care?

Ultimately it's up to the businesses to decide if this makes sense and the technology is driven mainly by developer sentiment, which circles back. If this is an easy way to make corporate apps, then why not.

I don't know why you would consider JS/TS backends to be niche - they are fairly mainstream by this time.

You also need to distinguish between larger frameworks and compile-to-js/wasm languages here.

As for the rest, I think the bigger reason they don't get traction is that one one hand they don't work well for incremental adoption and on the other they introduction friction when integrating with the wider ecosystem. This hampers adoption for both new and established codebases.

If I am starting a greenfield project from scratch, I am likely working with uncertain/changing requirements and need to move fast. If I choose something like Blazor/Vaadin etc., I am not sure how much effort will be needed if I need to integrate a third party Gantt component, or a month calendar view, or a leaflet map etc. in future. Unless I am already super-sold on said language/tech, it is likely not the best use of my time to do a comprehensive evaluation right now because I don't entirely know the scope of the project - I'd rather want to spend that time building something minimal that I can push out and get some user feedback. But when the need arises I don't want to get locked into a scenario where suddenly I need to spend a few days dedicatedly writing a custom integration or manually declare types for a complex third party library. So I end up writing a TS SPA because every notable UI library at this point is known to work well with it.

In contrast, if I am evolving a brownfield project which already has quite a bit of legacy, I am constrained by the set of choices already made in past. Eg. I am likely not going to introduce a C# layer in a large java application to take advantage of blazor. It makes sense only if I have a C# app, and the frontend developers of said app (who may or may not be same as the backend developers) are equally enthusiastic about C#.

Even if I have multiple microservices and each of them can use whatever tech the maintainers of said service want, in order to use Blazor the team still has to be enthusiastic about adopting not just Blazor and C# but also the wider C# ecosystem including ORMs, caching, logging libraries etc. and all of that ends up being a substantial learning curve for a team with deadlines. Each of these constraints funnels down the developer subset likely to adopt this tech further down and down.

So all in all, adopting a large fullstack framework is not just a matter of willingness to learn - it is also about how much work I need to do for integrating third party libraries, how much does my write-compile-preview feedback time suffers, how may I have to adjust my dependency system, what other choices the said framework imposes upon me etc.

In contrast, if I want to try out a small self-contained reusable library/component it is much easier to incrementally adopt or experiment with in a new or old project.

WebForms took off in the enterprise space, JSF as well, and now Blazor is basically the upgrade path fro WebForm folks.

Just like nowadays Spring and JakartaEE, alongside stuff like SAP Hybris and Adobe Experience Manager rule on the Java side.

Not everyone is doing conferences and putting code in github, and thankfully not everything is a SPA.

Thanks for your feedback. It sounds like you are saying that Blazor was created mainly for internal corporate apps on their intranet, but I don't think that is quite what Microsoft envisions when they market Blazor. Perhaps that is where you concluded that Blazor has its only real place, possibly for the exact reasons which I've listed in the article?

    > If you're replacing a shared spreadsheet cooked up by Tim on the data analytics team, how much does JS really matter.

I take your point, but from my experience replacing an internal spreadsheet which most non engineers know exactly how it works and does mostly everything they need/want with a custom SPA so 5 people in an organisation can do a task differently has never been a good use of developer resources or improved productivity.