For me, just the fact that I don't have to deal with JS bullshit and ecosystem including node/npm hellhole is a win for me. Before these shiny JS frameworks came along, .NET already had great UI component libraries as well including syncfusion (my favorite) and many others.

I only do VueJS when I do use JS but man I can't wait to not write any code in JS.

Yea, I've been using Blazor in .NET 8 through the previews and it's really nice.

The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the background.

With .NET 8, Blazor is really ready. It isn't perfect, but it's so productive for me and the downsides are really minimal. Plus, it'll likely get a lot better with .NET 9 in a year because of WASM-GC (and post-MVP improvements to WASM-GC). With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations.

Since people might want the "minimal" downsides, I'll put them here. If you're using Blazor SSR with WASM, after the first interactive page renders for the first time, there's a second or two before the interactivity is actually available while it downloads the WASM (on interactive components, not links or anything). If you were making a Facebook clone, it'd mean that the "like" button on posts wouldn't work for a second or two. This is pretty minimal for two reasons. First, it's just the first page load of the first interactive page. After that, the WASM is cached in the browser. Second, most of the time people need a few seconds to read the content before using an interactive bit. All of the navigation and such works instantly, but an interactive bit like a "like" button takes a second or two.

If you want to get rid of that, you can use interactive-auto. This means that the first interactive page load will use a web socket and the interactive bits will be done with Blazor Server. It'll download the WASM in the background and switch to WASM for future page loads so you don't need the web socket for the vast majority of your stuff. However, web sockets do create a certain amount of hassle since you need to make sure that any proxies in-between handle web sockets and that you consistently route the user to the correct backend if you're load balancing.

To me, those downsides are minimal and don't have a lot of user impact for me. This is in contrast with Blazor in .NET 7 where I'd have to choose using a web socket all the time or having a big WASM payload that meant the page didn't render for a few seconds and gave users a crappy experience.

If you're primarily creating something that would be server-rendered (like Rails or Django), Blazor offers that with the additional nicety that you can add interactive elements without needing to deal with JS. That isn't meant as a "JS is crappy" comment, but to note that having to deal with another ecosystem where you need to duplicate your models and keep them in sync, having to deal with another build system or glue things together yourself, etc. is a pain when it isn't your main focus. So many sites end up with a full front-end stack and all the hassle involved because they need a couple pages or want to keep a consistent component system. Blazor means that you don't have to go that route.

> With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations.

Does this mean the JS-interop performance penalty goes away?

It would both improve the performance of c# performance, reduce alloc overhead for javascript interop and reduce download size. It's an absolute win.

Wasm-GC isn’t compatible with .NET allowing references to fields among other issues. So I doubt that we will see integration soon

https://github.com/WebAssembly/gc/issues/77

I have faith that it'll happen eventually, in some form

I use swashbuckle and swagger-typescript-api to automatically scrape my controllers and generate API calls and TS types every time I rebuild. No hassle or overhead at all. No need for converters or anything.

I've been using this now for several projects, it's a great way to have all the power of TS for client side and C# for server side.

https://www.npmjs.com/package/swagger-typescript-api

https://www.nuget.org/packages/Swashbuckle

I do the same.

I have a small write-up here: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

You get end-to-end type safety (even better once you connect it to EF Core since you get it all ways to your DB).

With this setup with hot-reload (currently broken in .NET 8 [0]), productivity is really, really good. Like tRPC but with one of the most powerful ORMs out there right now.

[0] https://github.com/dotnet/sdk/issues/36918

I do the same in Django with drf-spectacular. I have a precommit hook that autogenerates (fairly thin) TypeScript schemas and routes on commit. This is not take merit from LOB devs who want to use C# back-to-front. I will use it as an argument to those who say that this is why you should go full TypeScript on any new web project though.

N.B. the last commit/release for Swashbuckle was Jan this year.

https://github.com/RicoSuter/NSwag might be a better choice for a new project. It look much more maintained and active than Swashbuckle

yeah nswag has been pretty consistent i can recommend aswell.

> I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.

I’m more happy about not having to maintain working knowledge of two sets of IDEs, build tools, CI/CD pipelines, hosting models and testing framework and conventions.

The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?

You get a little closer with Fable to compile F# to JavaScript. It lets you model your domain using F# types (which are just as good as – if not better than – C# types) and then you can use them both from your C# backend and F# or JavaScript frontend (whichever you prefer.)

It does require you to faff about with toolchains for building frontend code though (WebPack and the like), and it's not always completely seamless, but if you want to invest in a shared domain model it's the most compatible I've been able to go at least.

Or similar for c# with https://h5.rocks (disclaimer: author here)

Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.

Oh, that's handy, I thought MS had stopped supporting it. Good to know that it's still going. I thought they had dropped support in one of the .NET Core versions, before .NET 5+.

Presentation from .NET Conf 2023 last week with some of the new stuff: https://www.youtube.com/watch?v=N1weyWS_pL0

Thanks for linking that. The video description mentions they added WinForms to .NET Core in 3.0; maybe I was remembering the .NET Core 2.1/2.2 timeframe, when it wasn't supported in Core?

I believe prior to .NET Core 3.0, you could have a WinForms application in .NET Core, but the WinForms designer was not available in Visual Studio. While it was possible, having to build a GUI in WinForms without the designer is utter hell.

They don't kill it, they just tie it up in the basement and pretend it never existed.

RIP Silverlight

Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.

Ok first thing first - allow me to vent my existential frustration with few off the cuff (mostly rhetorical) questions ...

You call decade a substantial longevity?

Is this some kind of a joke?

Is your ability to assess being held hostage by js ecosystem expererience?

But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF) code that I have written for clients 15 years ago (don't you just love that sweet support fees that you get mostly for being alive and breathing ?). Meanwhile my friend that build whole company around product written in silverlight almost went bankrupt. Now after few years working in AI (going into it a bit too soon) he is trying to create same product in ... yes you guessed it, Blazor.

Maybe some people do not learn from their mistakes :)?

Yes, I would call that fairly substantial considering its underlying architecture is no longer viable -- not because of Microsoft's fault, but as the industry as whole moved away from the plugin-based AIR.

Silverlight was somewhat of a unique situation, as it was a platform where it heavily relied on the platform that was phasing out. (And to clarify, that "decade" is the period that Microsoft was committed to support for latest Silverlight 5. Their first version was released in 2007, so it had about 14 years of history.)

As with Java or any other languages, you can still run it if the environment it runs can be resurrected. (I would not connect that to the internet, though) And many parts of what actually powered Silverlight still thrive in a form of .Net.

I mean where they can support, Microsoft tends to keep its compatibility fairly intact, for instance modern Windows still can run many of the 32-bit binaries from early days. (And you even could do the same for 16-bit apps on a 32-bit platform, not sure if that's still possible, though.)

> Maybe some people do not learn from their mistakes :)?

Maybe some people do learn, and in this case it's Microsoft, who are not repeating the same thing with Blazor as they did with Silverlight.

The difference is that Blazor is built on web standards (WebAssembly), not a proprietary technology. Sure, Microsoft could discontinue support for Blazor, but WebAssembly will keep running. C#/Blazor are not the only technologies using WebAssembly. I personally wouldn't use Blazor for a public facing website, and would only use it for an internal LOB app where I know I can dictate what browser technologies can be used, as well as knowing the binary blob for the runtime will be cached in most users' browsers. I still use traditional MVC structure with C# for applications that will have a variety of users over different connection types, and use progressive enhancement with JavaScript for things that enhance the user experience (for example, creating multiple items of some type on screen, instead of only being able to create one at a time like with a standard form). The thing is, I've already separated out my application logic so that I can change the front-end technology at any time. That really shouldn't have anything to do with Blazor, and is just a way to make sure your application can adapt to future front-end technologies.

Correct.

Silverlight came when flash was being dismantled shortly after.

Different days back then.

No knock on C# or Java developers meant here, however I find that C# and Java Developers find 10 years of support not long enough, nearly every other ecosystem you're lucky if you get 3 year time horizons of backward compatibility and/or support.

10 years is pretty amazing, all told, IMO.

Blazor is just a new iteration on Volta (2007) https://en.m.wikipedia.org/wiki/Microsoft_Live_Labs_Volta

That's because WinForms are in active development. But yes, for a while, it was baked.

You can still develop Win32 and MFC apps today - those are more then 30 years old.

Win32 is the main Windows API, and MFC, besides fixing HDPI issues, the hard reality is that after crashing the whole WinRT/UWP story for C++ developers, there is nothing left on the Microsoft ecosystem for doing GUI in C++.

Yeah unless you go non-MS frameworks like Qt.

And yes, the current state of affairs is kinda sad.

Thats not always true, they keep some stuff that is a success for a long time, but they are also not afraid to drop there failures like ActiveX, SilverLight, VBScript, ...

And i am afraid blazer may be next.

Vbscript - deprecated, started 28!! Years ago

ActiveX - same, but 27! Years ago

Those were not failures. But have replacements.

Those are terrible examples tbh. A lot of businesses would sign immediately if they knew something was going to be supported for > 20 years. Additionally, vbscript owners should have long migrated to eg. Powershell

RIP FoxPro.

Silverlight, WPF, OData (was amazing for hooking your backend up to client-side tables, rubbish at everything else), WWF (Windows Workflow Foundation), WCF (thank god).

All dead.

And those are just the ones I can think of from the top of my head.

Plus the terrible excel VBA replacement they made, then abandoned, and now it's some fiddly javascript mess.

I'm sure there's a ton more people can add. Those are just the ones I personally wasted time on.

And let's not forget Window Mobile!

Edit: They've also gone through a stupid amount of changes in the asp.net MVC model in quite a short time. Plus constantly seem to overhaul their consistently overcomplicated authentication/authorization system. The state it's in at the moment is shockingly bad.

Try Silverlight, XNA, C++/CX, .NET Native, UAP,....

The difference is that they stop talking about it, their presence fades away in conference and developer blogs, and eventually from Visual Studio installation workloads.

WinForms can still be used with all of the stagnant issues. Had a faulty touchscreen driver on Windows 10 that only affected the touchscreen event messaging in a WinForms application. Had to wire directly into the messaging pump, construct a custom event system, and override the WinForms event system for everything to work properly.

Also had to wire a custom touchscreen event system for WPF because the Microsoft method would latch on to UI components with quick taps and press with sliding. This caused buttons to stay pressed while no fingers where on the screen.

I cannot recommend WinForms or WPF or UWP. Microsoft is bad at GUI application frameworks. It was recently that they finally shipped VS2022 with proper WinForms designer support and the ability to move away from VS2019. I still need to close and reopen VS2022 daily for WinForms and WPF development.

QT, GTK or some other framework gives the ability for cross platform solutions without being anchored to Window OS. Non Microsoft GUI frameworks are also faster and better when deterministic response time is needed and ability to run on low powered computers.

Web Forms ("I'm not dead"), Silverlight, etc.

.NET Framework has not been EOL'd, so you can still build applications in WebForms. Silverlight was killed off by browsers no longer supporting plugins, that really wasn't a Microsoft decision. Flash is no longer available either, and had nothing to do with Microsoft.

You can't be blamed for having that opinion given history. But Blazor is I think standing on the graves of those previous attempts and is looking extremely strong - it is as of even a year ago mature, well supported, and a deep ecosystem.

I think it's pretty safe to be optimistic at this point.

React will die too, eventually. Or at least stop becoming the default.

Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol.

What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly.

Friends don't let friends buy into proprietary backends that muddy the water between UI/API layers. Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations).

PS - This has nothing to do with "Microsoft bad." This has to do with standard protocols between front/back Vs bespoke stuff. I'd also criticize the short-sightedness if another company offered the same thing.

Best practices would dictate that you still build WebAPIs for your Blazor apps, to avoid that potentially happening. It will also give you a clean separation of concerns in your application. Even when I build a traditional MVC application, I still built out my API as a separate layer so I can change out the front-end in the future.

So, in order to use Blazor safely, I need to develop and test everything twice. That's a death knell within itself. You just made my argument for me.

> I need to develop and test everything twice.

That’s…literally the downside of frontend/backend separation of concerns…

Do you not bother testing your JavaScript?

We're discussing which abstraction is between the backend/front end. You said, to use Blazor safely, I also need to deploy WebAPI. I said you therefore need to test and develop it all twice: Blazor and WebAPI.

Your "question" is non-sequitur.

So you would build a solution that combined both using Blazor? I still don't understand, this is just like if you were to build a WebAPI and a front-end JavaScript SPA, except Blazor is your JavaScript SPA. You have your unit tests for your WebAPI, and you have your tests for your JavaScript SPA (in this case Blazor, but fill in Vue or React, etc.). You could then write integration tests if you wished, but there isn't any more testing or development process than if you were building a WebAPI with a traditional JavaScript SPA. Blazor is just affording you the ability to use C# rather than JavaScript.

If you were to include your business logic directly into your Blazor application, then you are setting yourself up to run into the exact same issues that you faced with WebForms, if Blazor were to be discontinued. You stated, "Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations)." Blazor is what you put in front. Blazor gets discontinued, you put a standard JavaScript framework in front. The amount of code written and the amount of tests written should be the same whether you use Blazor or React/Vue/Angular/Svelte/JS Framework of the week. What you get with Blazor is the ability to do all your front-end in C#. I think you are going at it as if you build old WebForms or Silverlight, and I just don't see why you would do that knowing full well that front-end tech changes rapidly.

Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.

I used to be a frontend coder, but am no longer. In part this is because I couldn't bring myself to keep up with the constant ecosystem churn of the JS world. I recently worked at a company that was trying to migrate from Vue 2 to Vue 3. It was not going quickly. Is Vue going to even be around in a few years, or will React eat it entirely? Or will react itself be eaten by Svelte? I have no idea, I'm not involved in these things. But after watching how such things play out for a couple of decades, my conclusion is that if you are building for the web, you should use whatever you are comfortable with and what provides the features you want now, because there's no way to know what things will look like a few years down the road. Even if the framework you chose sticks around, you may end up doing a rewrite because of other concerns or throw the whole thing away altogether.

>How about, for example, making it as easy as possible to use React with a C# backend?

Aint is easy already?

This may help if you'd like to keep front and backend(s) separated: https://quicktype.io/

I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense.

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.

Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact that they "work" does not mean they stand on solid ground.

I've written apps in Blazor, yet I don't understand its existence. Most apps, even LOB as you said, Razor Pages are more than enough. Razor Pages are amazing. What seems to me to be the source of the problem is the whole mentality: > But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send... You can ship server side generated HTML with Razor and just LEARN a bit of JS. I don't understand the allergy of the so called "back end" developers with JS. Yes it's shitty. Yes it feels better writing C#. I also like my bike more than my car. Will I take my bike to drive 500km? No. There's a time and place for everything. I feel efforts like Blazor just fight against the (unfortunate yet inevitable) current that JS is the only language that can manipulate DOM. I really think all of us should be open to use whatever makes sense for the job, even if it occasionally makes us feel uncomfortable. This is the dev community I want to be a part of.

.NET 8 comes with Blazor United (renamed to simply Blazor) that combines the Blazor Server and Blazor WebAssembly frameworks.

For client side components C# code is compiled into WebAssembly that manipulates the DOM just like JS.

Today with Blazor Server, the main drawback is the slight delay you can get when you click something. .NET8 essentially blends Server and WebAssembly and solves the problem, even giving you the best of both worlds since WebAssembly has high first load times, .NET8 Blazor loads initially with Server side and provides client side after it loads all resources.

I spend most of my dev time in typed languages. Going to untyped languages feels like going from K'nex to clay.

Same here. I'm a web developer. Very few people use Javascript without types (through Typescript).

This is hilarious, because clay is just such an amazing material.

Clay is very malleable and has all sorts of wonderful properties. As a building material it has fundamental limitations as it’s less suited for tensile loads.

It’s funny, because you can continue the analogy and compare optionally typed languages (like TypeScript) to adding wood/rebar to a brick building, allowing it to go vertical.

A good example: the Chrysler building sports 3 million specially made bricks for its facade. By blending both materials, you receive the thermal and maintenance benefits of brick with structural integrity of steel.

> I don't understand the allergy of the so called "back end" developers with JS

I think what many people are complaining about is that they actually dislike UI development and all the ambiguity and complexity. "JS" just catches blame for this. Modern JS and esp. TypeScript are pretty good languages, or at least comparable.

A lot of these server side UI toolkits avoid some of the complexity by supporting basic UIs and flows, e.g. List/Show/Edit (which is fine in many cases), but to do complex UIs that many modern apps need, it's a huge pain. Worse situation to dev is forcing 80% of the functionality via server side, then the last 20% you ask "front end" to wedge in with jQuery style development.

As someone who suffers from this allergy, I'll chime in with 2 additional thoughts:

It's not just that UI development is more ambiguous, it is the fact that it is difficult to make text-based code fit it. This is doubly (or maybe logarithmicaly) so when responsive (same code fit different screens). HTML, XAML, HAML, etc all require a lot of code. Reusability mechanisms (like components, etc) help this but it is a world of difference from what BE devs are comfortable with.

Thought #2: I'd guess BE devs like to just code, and the FE frameworks have a reputation of getting in the way of that. This is a less certain thought, so welcome opposition, but seems at least like part of the emotional reaction a BE dev would have to FE work.

It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct.

Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult).

I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).

When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit.

Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable.

Their WebAPI in ASP.NET is very good.

Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET.

In the desktop world, MS has jumped a lot of hoops, mostly because there is no one to chide them on their own platform. But the web is different.

> When it comes to web, MS has been focused on ASP.NET since forever.

What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ...

Honestly, it's just one clusterfuck after another.

---

EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here:

* For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go.

* For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments?

* For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is.

But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least).

In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent).

Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).

A lot of these frameworks either composed together or had an upgrade path where it made sense. Plus if you're structuring your application right in .net, that web layer becomes another interface. I have taken an application across a few of those with some fuss, but you're covering 20+ years of development there.

Have you used those technologies?

Asp.netbwas great, asp.net cire was a good upgrade, and minimal apis are an optional way to get an asp project up and running with less boilerplate.

Not sure how that constitutes a cluster.

Don’t forget Web API 2! And their other API recommendations (OData anyone?)

Have you been to JavaScript land in a while?

Sure, do you have a point you'd like to make?

The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening.

And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer.

And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.

> You install a package today. In 3 months, that code won't build.

And you are even generous, if you force upgrade every package you have in a month, I'm pretty sure you will have broken stuff.

> You install a package today. In 3 months, that code won't build.

Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine.

> And I did I get to the 100s of config files that need to be set just so I can run "npm build" ?

..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.

Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great documentation on how to upgrade. It just sounds like you are more familiar with working with front-end tech, and I would hazard a guess that you are actually much better at it than you either let on, or believe you are (Impostor syndrome, I get it all the time until it's crunch time, and then you just get things done).

I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.

> Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version.

What front-end tech, everything is typescript.

Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working.

> It just sounds like you are more familiar with working with front-end tech,

No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing.

> I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with.

Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?

" yet another new shiny web-framework"

Funny you say that. JS..cough..JS.

BBBBBBBBBBBBBBINGOOOOOOOOOOOOOOOOOO!

Yes, at the end of the day, businesses use software in LOB apps.

Period.

Get shit done.

WebForms/ASP.NET MVC/.NET Core MVC/Blazor will outlive ANY js framework.

Agreed. I mean really in the spirit of get er done the AS400 is the pinnacle of UI for these sorts of things. I've worked with other things, even WinForm apps, Access things, Excel sheets that were turned into portable apps, and of course web pages. Green screen allowed 99% of things to get done faster with 1000% less fuss.

https://en.wikipedia.org/wiki/Computer_terminal

My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users

At my old job non-technical people would navigate about as well as they would with a mouse and a graphical-based interface, because the graphical interface didn't provide any additional value. For those people it took the same time whether read instructions and press key or read instructions and click button. Trained people were definitely faster, and often the user would type ahead of the terminal (with no ill effects) because they were inputting data close to their speed of thought about the process [0].

The point is, for this situation a text-based terminal offered no downsides and many benefits compared to a graphical UI. I suspect the same is true for a lot of other business solutions.

I've heard it argued before that graphical systems are easier to use, but in my day-to-day experience in the trenches with others who actually used the systems this argument was simply not true. I've also seen it hinted that graphical systems seemed more modern, so they got less emotional disdain. That rings more true to me. And really if I were in charge of such things I would acknowledge emotional disdain - even misplaced - may well count for something in the overall business picture.

Also, and maybe most importantly, if the green screen needed a new feature or bugfix, there was one person at corporate that would do that. They had about a half dozen devs working on other things but she was the go-to for the green screen features. So I imagine it's harder to hire people for those sorts of systems nowadays. However it was also interesting for me to note that one person didn't seem stressed out or overly busy and the system never had a major crash or bugfix. So, tradeoffs.

[0] The terminal was actually hosted inside a wrapper app inside Windows 7. So I ended up using AutoHotKey to great effect to get even more efficiency gains.

* edit: added footnote explaining how AutoHotKey could be talked about in same breath as green-screen dumb terminals.

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.

The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up.

But enterprise LOB don't care.

> I don't have to maintain the cognitive overhead of translating domain models into JSON models and vice versa.

Every single time I've seen this attitude, it turned out that actually it just meant you're going to have a worse time when you inevitably had to do that translating.

Java web applets aren't new. "Using models directly from the domain" is not new. Even when the runtime is friendly, the latter is a bad idea.

Serious question - do you know this to be in fact true of Blazor specifically, with real life comparisons, or is this just conjecture based on analogous frameworks?

This is silly. I mean sure, I did try out Blazor - and ended up unimpressed despite otherwise quite liking C#/.Net - but ultimately it's Blazor making extraordinary claims.

And some of what I wrote is about the programming model itself - by now my experience is that domain models should generally stay on a whiteboard - it's quite rare that's actually what's more convenient in any specific place in the codebase. Trying to "streamline" that tends to end up just introducing even more complexity due to poor abstraction match.

> It will load slowly, work slowly

Why do you think this will be the case?

Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet.

Couple that with the fact that interoping with JS can be a lot more annoying than just using JS

> Well for Blazor Webassembly at least, you need to download the entire .NET runtime

It's a one-time download that's smaller than the initial load of the Facebook feed

plus in LOB apps very likely to be in the browsers cache already. And dont forget buisness workstations are usually connected via at least 1GBit Ethernet.

I'm not who you're replying to but designing for excess resources is the kind of thinking that leads to slow software.

> And dont forget business workstations are usually connected via at least 1GBit Ethernet.

NOPE! More likely they are WiFi connected Dell shitboxes running Windows 11 with 8GB of memory, half of which is taken up by all the browser tabs, Teams, Office, and the 30 horrible little programs that IT deploys via group policy.

Speed matters. The user is probably running your code + 30 other things. Don't assume your page is the only thing they care about.

Any data to back this up?

Any data to back _your_ claims up? Because, y'know, sure, all _we_ have is years of lived experience.

If your point is that companies run outdated, shitty computers connected over unreliable WiFi, _your_ corporate life experience has been vastly different than mine.

What about the CPU usage?

Facebook loads a lot of information. I don't think we should be comparing the download size of a hello world app with loading dozens of images on a facebook feed.

Honestly I'm afraid you don't know what you're talking about. Blazor just isn't that experience and hasn't been for awhile.

Well color me convinced!

.NET 8 is suppose to greatly improve AOT. Depending on your use case, you might be able to get around bundling the runtime entirely.

As far as I understand, .NET 8 AOT has nothing to do with the webassembly blob that gets served to the client.

They’re working on it. .NET 8 introduces the option to perform a degree of trimming on the AOT output. https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an...

Actually dotnet wasm can be further trimmed in .net 8. but for most non rtl people the biggest improvement will be to reduce the locale bundle. Sadly it’s not possible to specify which ones you want. Also it’s not possible to bundle DLLs/webcil. I.e the dotnet compiler will be shipped to the client thus you will also get shipped lots of dlls

Blazor Hybrid looks promising to completely negate the load time for Blazor WASM.

Yes that does look promising for load time, but once the Webassembly is downloaded and being used, Non high end computers can easily choke.

That's not true since .net 6

https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...

Literally a quote of one of the dismissed drawbacks. The post didn't question whether the drawbacks are real, just said they're irrelevant.

I have no experience of Blazor, but the architecture of Blazor server is exactly what Phoenix LiveView (Elixir) does, and that works extremely well.

Unless your interactivity is at the level of Gmail or Google Docs, or you really care about designing for very high latency flakey connections then LiveView is great and works very reliably with a good user experience. Even on a phone with a cellular connection going through tunnels it's actually better than a lot of JS apps because it handles the reconnection (and visualisation) much more cleanly than most JS apps.

I consider myself more of a backend person but I feel I can deal with JS much easier than CSS. I learnt both in 15 yrs ago so compatibility with IE was crucial. Slap jquery on, stick to style guidelines so that variables are named consistently, avoid dependencies and it feels okish. There isn't anything like that to help with CSS though.

As a backend dev primarily, learning CSS Grid really helped me filter out a lot of the BS.

It's a UI framework that is 20 years too late, and with "lean" JS frameworks that are emerging, a lot of this UI development legacy can die a horrible death as far as I am concerned.

So is it like ASP.NET WebForms?

More like Elixir/Phoenix's Live View I would think.