.NET 8's Best Blazor is not Blazor as we know it | Hacker News Reader

.NET 8's Best Blazor is not Blazor as we know it

servicestack.net

48 pointsmythz64 comments

Maybe I'll use it one day, but I'm extremely skeptical of anything WASM-related.

Anyone actually using Blazor in production? How's the effective performance/responsiveness? Are the loading times reasonable? Is this usable on low end and mobile?

There are new operating modes for Blazor in .Net 8 that don't require Web Assembly. There's the new "Static server" and "interactive server" that don't require WASM.

I think the article is making the case you probably want to hear :)

I wrote about Blazor server-side mode yesterday:

https://news.ycombinator.com/item?id=38363704

I wouldn't touch the WASM mode with a 50 foot fiberglass pole.

For me, Blazor was a great entry point. I still use .NET for everything, but now we mostly use simple form posting with string interpolated vanilla HTML responses directly to HttpContext.

There are no more frameworks in our shop, but I don't think we could have arrived at this point without things like Blazor, Angular, RiotJs, et. al. temporarily bearing the load of our ignorance until we (or the technology standards themselves) could finally pass through.

The web in 2023 isn't like the web in 2017. I think you could start completely blank on vanilla MDN and PHP-style web dev and arrive at an extremely happy outcome. No blazor, no react, node, nothing. Confidence that the javascript or CSS will "just work" 99.99% of the time is there for me now. Avoiding premature optimization regarding UX edges (i.e. justification for SPA) and backend technologies are the major remaining challenges. Chasing a pixel-perfect, cross-platform UX is how you wind up with absolutely nothing to show for it at the end of the day. I blew about a year of my life on that one.

All true, dear sir.

"I think you could start completely blank on vanilla MDN and PHP-style web dev and arrive at an extremely happy outcome."

Yep

I'm genuinely wondering: what's the benefit of using Blazor/ASP to build a web app as opposed to Vue (or React/Svelte, etc)

I’ve found C# pleasant to write in, and I get a bad feeling every time I deal with npm. On the other hand the library support for React is just so much better so I put up with it.

EDIT: I’m not a web dev, the web is just the most consistent UI platform for supporting mobile and some desktop we have now so that definitely influences my opinion.

If you are primarily a C# shop then being able to stay in that ecosystem is quite valuable.

It is mostly for .NET shops, and also the upgrade path for folks still stuck with WebForms.

There's an upgrade path from WebForms to Blazor?

Edit: I guess there is supposed to be [0] I can't imagine it that would actually be any easier than moving to any other technology.

[0] https://learn.microsoft.com/en-us/dotnet/architecture/blazor...

It isn't zero effort, however Blazor is the closest in modern .NET to how Web Forms used to work.

There is even a .NET Conf 2023 session regarding it,

"Bye ASP.NET WebForm, Welcome Blazor"

https://www.youtube.com/watch?v=yhwunQ6XQCg

The main benefit that I keep hearing is that you don't need to split your attention between different languages.

JS does have its own gotchas, so I guess there's something to that... But I can't imagine building things for the web without a solid foundation in html, css, and js.

That's the main idea of Blazor really - to start imagining what building the web without javascript really means.

Hard to imagine web development without Javascript now, but with work of projects like this, maybe it will be easy to imagine web development without Javascript in 10 years time.

> That's the main idea of Blazor really - to start imagining what building the web without javascript really means.

To start? This is not new. We've been down this road a dozen times.

One fundamental difference is that if you are building a React or Vue static app, you're going to need a backend anyways. If you're building a React or Vue SSR app (Next.js, Nuxt.js), you'll probably want a separate backend anyways.

If you're going to have a separate backend, .NET has some advantages compared to Node that's worth considering. It's higher throughput than Node for the same compute resources, it's multi-threaded and you can run background workers in-process, it has some nice built-ins for concurrent processing (Task Parallel Library, System.Threading.Channels), the nuget ecosystem is less prone to security risks compared to NPM [0], EF Core is a really mature ORM and possibly one of the best ones out there for productivity, it has serviceable hot reload for productivity, and modern C# is really, really close to JS and TS in syntax [1].

One often overlooked advantage for high security contexts is that .NET has a large standard library that's maintained by Microsoft for really core things like encryption, hashing, database drivers, network code, etc. You get the benefit of having an army of professional engineers maintaining that core code and patching it when security issues arise versus the Node/NPM ecosystem's strong dependency on the community.

C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now.

And if you're going to use .NET on the backend, then why not consider Blazor for SSR and static HTML?

(Disclaimer, I'm not a big fan of Blazor, but I can see why teams would choose it).

[0] GitHub State of the Octoverse 2020: https://octoverse.github.com/2020/static/github-octoverse-20...

[1] https://github.com/CharlieDigital/js-ts-csharp

    C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now.

Bold statement. Looking like typescript doesn't seem like it should be the most important concern in a backend lang.

I don't think it's that bold. It's like saying learning Spanish is easier than learning Japanese if you're a native English speaker. The basis in the shared Latin characterset certainly makes it easier to learn Spanish, no?

Similar syntax equates to similar constructs and concepts. The way async/await works -- from a dev perspective -- is the same. Exception handling is more or less the same with try-catch-finally. Lambda closures work largely the same (some differences due to how JS binds `this`). TypeScript object hierarchies like interfaces and abstract classes are more or less identical in function (obvious differences, though in underlying implementation and capabilities). Same null coalescing, same nullability constructs. Array methods like `map`, `filter`, and so on are subset of System.Collections.Linq operations like `Select`, `Where`.

Certainly having similar syntactic language constructs makes it easier to adopt if you are already comfortable with try-catch-finally and async/await versus entirely switching paradigms in Go or Rust, for example.

Tooling is very similar from a CLI perspective and DX isn't that different. Hot reload, .csproj = package.json, main.ts or index.ts = Program.cs

I'm questioning whether learning the syntax of a language is the main difficulty in backend development and should be the main decision point.

I can think of a few, starting with lack of fragmentation given Blazor's now the "premier" Web Application framework for .NET which has the full focus and developer resources of Microsoft, millions of .NET Developers and 3rd Party Component Developers.

Low platform churn, i.e. Blazor has essentially kept the same development model for 5 years, uses the same MS Build/.NET SDK and Framework libraries that are actively supported by Microsoft. Whilst the JS/FX landscape see's frequent fragmentation, new incompatible major versions, new module loaders, new build tools, 100's of deps which are often abandoned/incompatible after upgrades, etc.

Blazor SSR App's gives you SPA-like responsiveness to traditional SSR Apps by default, i.e. without needing to manage decoupled client routing, complex state, npm deps, build tools, large JS blobs, etc.

Blazor makes it very easy to create encapsulated reusable components, which already sees a large number of 3rd Party component vendors available for it.

The .NET Platform overall is very performant, works flawlessly cross-platform, C# is a very IDE-friendly statically typed language with great tooling e.g. JetBrains Rider is one of the best IDE's available for any language and works cross-platform.

NPM doesn't work behind my company's firewall

You can use your domain model objects to build sites and never again have to worry about conversion between json and native models.

C# is not flexible enough. Nominal typing is too rigid. You can't `return {foo:bar}` from a method and have type safety. You can't declare type inline way.

While I do miss TypeScript’s type system every now and then in C#, I wouldn't say that those are blockers in day to day usage of the language. For me at least this never really stumped me in a way that productivity was impacted by it.

I guess if you really want to, you can do a lot with tuples and if you need the equivalent of object literals and spreading, you could use records ... both options with fairly minimal additional effort over what you would have written in TypeScript.

I wouldn't build a business on that. Microsoft's track record of keeping front end tech alive and attention on it is pretty fucking low.

On a positive note I bought my house with the money earned by their lack of attention.

It's probably a bit better than React, Vue, and other FE stacks which have had large, fundamental changes as well.

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 XNA, Silverlight, WebForms, Windows Forms, WPF, WinRT, WinRT/UAP, WinRT/UWP, and now WinUI 3.0/WinAppSDK, are a bit burned out with Microsoft GUI frameworks.

I'm strictly speaking of web FE.

Sure, since my list wasn't exaustive.

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.

If you group it like that, then there is a whole graveyard of Node and JS technologies that have died along the way, too. Ember.js, AngularJS, Knockout.js, Backbone.js, etc. Waaaaay more than Microsoft's go at it.

I'm not even sure why you're counting WebAPI in there since it's for writing REST APIs.

I guess because writing Web FE with a .NET backend is something that many .NET developers happen to do, via WebAPI exactly.

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.

Feels like moving goalposts here.

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.

My goalposts are still the same, Microsoft FE frameworks since the dawn of time, Web and native, and their continuous replacements, when the team doesn't meet whatever KPIs.

I don't care what others do.

It is like kids on the kindergarten playground, arguing for who behaves better.

Porting MVC to MVC core was not very complicated. ASP.NET Core, MVC Core, Razor Pages are all relevant and in use today. And all of them are using same rendering language (Razor), same language Blazor is using. It's not like your knowledge becomes obsolete when you move from one framework to another.

Same thing with most of Windows GUI frameworks MS built. They all use same rendering language/interface (xaml).

The very fact that some code changes are required, regardless of how little, is a friction point.

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.

Web Forms and Windows Forms were both relevant for over a decade. For front end tech, that's pretty good.

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.

The worst part, is that at least in public like community channels and tickets, they don't seem to get the point that this has burned lots of bridges with the Windows developer community.

To the point that many might still use Windows, but not necessarly Microsoft frameworks.

I am forced to do WPF as part of my day job, but come from 10+ years of Qt and other UI frameworks. I loathe WPF. It feels overengineered and undercooked at the same time. It feels inelegant. It oozes that it was built by people who would never have to use it themselves, with the attitude 'yeah of course I can make one of those, how hard could it be??'. The built-in hbox/vbox are broken, which is inexcusable as those are the bread & butter of any UI. The way margins and borders is handled is horrendous. The way you set up styling/theming/defaults is horrendous. The way the docking layout is designed is ugly - why is the center widget a special case?? The way the grid layout is implemented is demented. The way the default datagrid works is demented. I have two or more tips for anyone who wants to design a UI framework:

(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.

Yeah this. It's horrible. We have one which was built ages ago. It falls to bits on high DPI displays suddenly as of Windows 11. No one knows why, even at Microsoft. It's being replaced with some pile of shit in Electron instead.

Why would you even want to write an immediate mode GUI in XNA?

The point being the developer burnout regarding GUI frameworks out of Redmond, if XNA can be used for it or not, is besides the point.

We're not burned out, we're just suspicious and conservative based on our years of experience of having the rug pulled out.

On my book that is relatively the same, as each of them comes with some learning cost, and related ramp on efforts, only to be dropped a couple of years later, without any respect for the developers, see .NET Native and C++/CX deprecation as one example.

Really, I still use winforms and WPF.

Winforms especially is going on 20ish years?

How do you feel burned by them.

Try to always move on to the newest one, every couple of projects, instead of using a 20 years old stack.

Sounds like you burned out by choice. As long as it is supported and meets your needs, keep using it even if it is 20 years old.

In consulting we don't have the privilege to use fossilised technologies, unless the customer asks for them.

There is no universal truth in consulting. Consultants still write COBOL.

You missed my unless part of the sentence.

You missed the first sentence of mine.

My second makes your first a tautology.

You're getting burned because you keep moving between technologies, and you're blaming Microsoft? Weird. Have you tried not doing that?

One of these (react) does not belong. React brought a new, better, API and kept the old one in. Migrating between react versions is actually a very simple affair, nobody was forcing React hooks.

What do you mean? My first real world project after college was based on ASP.NET MVC, that was 12 years ago. I left the company a long time ago and the project is still healthy and growing they upgraded to ASP.NET Core but they keep using MVC.

MVC is fine. The THICK stacks they build are the problem. Web Forms and Silverlight for example. This is just another one of those balls of muddy complexity which will turn into a bad idea which will require a complete front end rewrite of your several hundred endpoint enterprise shite ball in 5 years.

I would, now that Blazor is the flagship Web Framework for .NET which supports multiple render modes and hosting options, inc. in MVC and Razor Pages or as a general templating solution (e.g. for rendering Emails). It's going to be the framework with most of the focus that most .NET Developers will eventually move to.

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).

Yeah, um, I was there for Silverlight and Web Forms.

Also your last point is quite frankly crack smoking. You can still dump out perfectly good dynamic content with Razor and MVC.

> Yeah, um, I was there for Silverlight and Web Forms.

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.

I was there for silverlight and web forms as well. Web Forms had to die IMHO, it was unnecessary abstraction for those who didn't want to learn web. Silverlight on the other had was not (in my opinion) killed by MS but by browser vendors. It was the same time when flash and other plugin based tech died because browser vendors didn't want to support browser plugins.

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.

Two deprecated technologies in 21 years, are you serious? Their main templating language, Razor, has been around since 2010. Silverlight and Webforms continued to get support for many years after they were superceded.

I would.

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.)

Have you tried to drag your shit through .Net classic to .Net core via all the stack changes and direction changes? Hell no. It has been horrible.

Let's call it the "messy middle" and see if we're on the other side of it. :)

Are we talking web frontend, or can we extend this to desktop GUIs as well (that may be cheating, but bear with me). Windows Forms and WPF are both still supported. If you're a business built on Windows Forms (very productive for GUI development), you haven't had to worry. Even VB.NET is still supported, although not receiving active language additions.

That said, I personally wouldn't choose to build on MS tech.

> Microsoft's track record of keeping front end tech alive

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!

Reply on news.ycombinator.com