> I have been able to implement things in 4 hours that would easily have taken 4 weeks if I had to argue with other developers about the shape of a JSON blob on the wire.

I can’t comment on your specific circumstances because I don’t know the details, but this reads like someone who is drinking the blazer coolaid.

It’s a technology like any other, with specific trade offs.

If you have a front end team who lacks the basic competence to do something that takes four hours in blazor in less than 4 weeks, then maybe it’s a good trade off.

...but in most cases, for most people, that won’t be the case.

It’s also quite slow, hard to integrate with existing js technology (ie bridge) and very difficult to debug production issues with in my experience.

The entire point is to avoid javascript as much as possible and to force the few edge cases into an interop shim.

We have a very complex Blazor webapp and the JS interop shim is fewer than 200 lines of code. This is 100% of the custom javascript for the entire application. Front and back. We do things like GetClientRect, Get/Set/Delete cookies, keyboard/mouse event subscription, etc.

There is little-to-no context switching when operating with one of these codebases. The notion of "front-end" and "back-end" is completely meaningless here. The "back-end" is literally an F12 keystroke away from the "front-end".

> and very difficult to debug production issues with in my experience

What sort of production issues have you been encountering that were difficult to track down? I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.

> The notion of "front-end" and "back-end" is completely meaningless here.

So to start with, a disclaimer: I carry some baggage here, from working occasionally on 10+ year old GWT app that's developed into quite a tangled mess.

Having said that -- this sort of thing doesn't seem like an obvious win to me. The notion of "front end" and "back end" represents a real-world distinction that you want to pay attention to. Making it too hard to see, or too easy to communicate across, brings some risk of losing track of which is which, and putting logic that belongs on the server into the client or vice versa. Or having the two communicate with each other much too often, which may not cause any noticeable problems during development, but, in production, can cripple the site for users with higher-latency Internet connections.

Blazor has two modes: Blazor client-side is C# code running on a WASM dotnet runtime. It does have the frontend/backend split. Data still has to be serialized (as HTTP calls since that's all a browser can do) but it's done using the same classes & libraries as on the backend.

Blazor server-side has no distinction though because everything is running on the server, and the UI is just a thin stream of HTML updates.

The model you choose is up to you based on resources, latency requirements, payload size, etc. Blazor just gives you more ways to get things done.

Ditto, I've no desire at all for web applications--or heaven forbid clients--to poke directly at a database or cache, or otherwise obviate the need for APIs. One will need to deploy, scale, monitor, and secure those things very differently from one another.

We use SQLite for storage of all things. The entire application lives on a single machine.

   OurApp.exe: 
   SQLite <-> C# Services <-> Razor Components

When you have a stack like this, Blazor goes into additional dimensions of productive. Every F5 of the app is a complete stack running without any frustration in setting up databases, containers, message buses, etc. None of the concerns regarding scalability apply when you plan to go vertical.

I would not currently argue for developing blazor server apps as a replacement for 100% of web applications. But, there are situations where you have a constrained user base and predictable performance characteristics which provides enough confidence to go all-in on a single fast box.

Not familiar with .NET, but am intrigued by the Sqlite all-the-things bit -- can you run your LINQ queries client-side? (e.g. for offline capable apps)

We use the Blazor Server hosting model, which is inherently incapable of running offline. For our specific use case, this is actually more ideal than any notion of offline capability. In this model, any LINQ would be running on the server.

Now, you certainly can run LINQ client-side if you were on a Blazor WASM (or hypothetically, Desktop) application. This is kind of the entire point of the stack.

LINQ is built into the core .NET runtime (and the syntax into C#) and available everywhere (I think LINQ was introduced with .NET 4 and C# 3.0 some >10 years ago). So doesn't matter if client/server or blazor. But you need some kind of LINQ-to-your-datasource adapter (i.e. to Sqlite, MongoDB etc.) which might have different availability depending on your environment (i.e. a Sqlite adapter would clearly somehow depend on a native sqlite client - but AFAIK is available in Blazor through WebAssembly).

> I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.

That’s a local development environment.

Have you had similar experiences when dealing with deployed applications? How did you do it? It’s rather more difficult when, eg. You can’t have a copy of visual studio there to use on your production deployments.

The fact that you have to interface between different teams/languages is often a big part of the slowdown.

The productivity improvements are real. Not having to design and expose an API for the frontend and instead just reuse the same classes and services is a massive shortcut. Running Blazor on the server is even easier because there's no serialization at all and you can directly call database queries in response to UI events.

I suggest watching some of the Blazor presentations to see just how much complexity can be built in minutes compared to more traditional frontend frameworks: https://www.youtube.com/watch?v=CEjqhTGrqDY

> The fact that you have to interface between different teams/languages is often a big part of the slowdown

Different teams is a business organization problem, and if you have that problem, you just aren’t going to choose the kind of server-side-code-with-generated-frontend framework that Blazor is (and of which there are several besides Blazor), so it doesn’t solve any problem there.

Different languages without different teams is a much smaller problem.

Then why didn't Meteor take off fully? Because that was the promise of universal JS, about 10 years ago...

Javascript is still struggling to be fully capable server-side today, let alone 10 years ago. Going in reverse is much more functional.

Meteor's problems were around performance and features (or the lack of them) IMO, which are not in principle ones that will crop up if you try to unite a stack around a single language.

Isn't load balancing still an issue with server side blazor? Because of SignalR for the delta between server and client?

Yes. A single-server can scale to thousands of concurrent users however it's not recommend for massive public sites. Works great for admin backends though where the usage is known.

I haven't use Blazor but they mentioning about avoiding the json API with all the encoding/deconding that entails sounds nice, plus only doing routing in the backend. These frameworks (liveview, blazor, hotwire, etc...) seem like a nice compromise that can serve well most webapps out there.

Agreed, I really think Blazor is the way forward for .NET UI. It's bittersweet, but: the Windows and .NET teams have failed to deliver a compelling alternative to web UI, and I'm impressed with how well Blazor integrates web UI with .NET.

I think the killer feature is that it will work on any platform with a decent webview control (Windows will finally be joining that club soon when WebView2 ships in-box), including MAUI; so you can use the native hosting bits of MAUI and the web UI bits of Blazor, no XAML required. And then you can reuse that same UI on another platform or a web browser, trivially.

Hot reload for Blazor dropped in the recent .NET 6 preview 3 so this is a really good time to get started with it. It blows XAML Hot Reload out of the water because it can reload many C# changes in addition to HTML/CSS changes; XAML Hot Reload breaks down as soon as you need to change any C# code that touches your UI.

Xaml hot reload only works on about half of our views at work, and even then it tends to break itself. I've tried net framework, net core, and net 5. The newer targets break less often but we still can't ship net 5 thanks to Windows 7 extended support contracts from Microsoft. It doesn't even compare to blazors implementation. And c# hot reload breaks frequently around asyncs and lambdas.

> The newer targets break less often but we still can't ship net 5 thanks to Windows 7 extended support contracts from Microsoft

You make it sound like it's Microsoft's fault your customers won't move off of Windows 7.

He has a point, for example now they've finally stopped supporting IE11 you can legitimately say to customers that supporting IE11 is no longer possible because it's a security hole.

Extended support by MS for Windows 7 means the only reason you're not supporting it yourself is your lack of motivation, and so to your customers (and your own upper management), for a big contract that's not going to wash.

You might even find that their contract even says something to that effect.

I may be misreading your comment, but in case you're not aware .NET 5 supports Windows 7 as a deployment platform: https://github.com/dotnet/core/blob/main/release-notes/5.0/5...

And it does not specifically require any paid extended support contract from Microsoft to actually install and run.

> The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible.

After winforms, silverlight, wpf, webforms and WinUI I don't want energy, I want to see them focus for more than 5 minutes. The only stable UI tech from MS with any long term support has been Win32 that came out 25 years ago.

I predict blazor will be quietly dropped (they won't actually admit it for 5 years), just like the others and you'll be forced to rewrite your software in a few years.

These blog posts are as relevant as ever.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

Other than Silverlight, the rest are still available today. Microsoft is unmatched in backwards compatibility. How are you being forced to rewrite your software?

.net core broke compatibility with many more, c#/.net is now decoupled from MS legendary backwards compatibility.

Then you've got things like hiring concerns, $nextJob will want people with $nextTech on their resume, it doesn't matter if something is still technically supported because hiring people willing to work on dead platforms is a tough ask, moreso when the tech is a couple of generations old. This churn isn't happening in a vacuum.

Again, you do not need to rewrite anything if you don't want to upgrade to .netcore/5.0 because .NET Framework is still supported and has a long lifecycle tied to Windows itself. You can even write C# 1.0 code and it will still compile and run today without any issue.

Do you expect software to stand still for decades? Please show which other language stack comes anywhere close to this kind of stability because several of them (go, nodejs, rust) didn't even exist when .NET was first released and running critical systems in major companies.

You can still find COBOL and Fortran jobs if you want to avoid anything new, no need to complain about the industry moving on.

yup, thats why if I need to do a small desktop app I still use WinForms. Its easy to use, mature and performant. Good enough.

What is a good way to learn the .NET framework or a guided path to understand the development hierarchy in .NET. It seems expansive with tools for everything from web, app and desktop development. Microsoft provides tutorials but it feels like they are all over the place and not really directed.

Well this is a very loaded question. I’d tackle it by basic aspects of base development.

- File Handling, IO, Streams - Data Storage, ADO.NET - Generics, Collections - Linq, Lambdas - Threading, Tasks - Cryptography

I’d just build console apps, which you can do on Windows, Linux, or MacOS.

Just install dotnet-core.

I'd recommend skipping ADO and learn Dapper/EF Core (this is harder to learn because its huge)

I'd consider going straight into Dapper. It's where you'll end up anyways if you start worrying about performance. Direct SQL queries and matching projection models allow for much more flexibility in all areas. If you are bad at SQL, EF Core won't save you for very long. Might as well learn it the hard way.

Learn C# in vscode and console applications. After that, search the app model (they have like 20 of them).

And you want to .NET and not the .NET Framework :).

What tutorial is best, depends a lot on your experience and target.

i can recommend the .NET 101 series on YouTube. If you want to quickly write .NET code you should try the .NET Interactive extension for VSCode

The concept is revolutionary, for sure.

But for now it doesn't work as well as a classic SPA architecture. The server-side mode works not very well on poor connections (mobile), and the client-side WASM builds are extremely slow. Especially on first load, this takes seconds.

Blazor may be well suited for Intranet apps already, where quick&cheap development is very important, and connections are fast and stable. Blazor Desktop is an example for that use case (no latency between frontend and backend).

For internet apps, something like Gmail or Instagram, it seems to be not very well suited. Especially not for websites with interactive content, for example a comment-box inside a blog. Nobody wants to wait multiple seconds until the content is responsive, or the "reconnecting to server" overlay disappears

Pages can be server-side rendered and then hydrated after load, in either mode. This makes a dramatic difference in usable latency.

Sure. But it still takes some time until the interactive part works. And it doesn't solve connectivity issues a SPA can easily handle.

SPA = single page application. You can make one entirely in Blazor and can host it on any static file host. Are you talking about Javascript specifically?

The difference of Blazor compared to a "classic" SPA (for example React + JSON API) is:

Blazor Server: On a broken/poor connection there is no interactivity anymore

Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow

classic SPA: Keeps working with lost connection and is fast.

Last year I created a Blazor WASM app[1] to get familiar with the tech. It was a game based on the board-game from the 60's called "Acquire". Although it's using the WASM hosting model, I did use SignalR to facilitate the real-time game play between players. The "practice" mode against the crude AI is entirely WASM and can be "played" as a PWA completely offline. I had intentions of finishing this out, but I got far enough that I learned what I needed to for now. I felt like it was pretty good considering it's probably less than 40 hours of work and I'm a mobile/desktop dev not a Web dev.

[1] https://acquiregame.azurewebsites.net/

> Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow

Why should it be slow? Once Blazor WASM is loaded, it doesn't need a connection to the server anymore.

.NET runs in WASM around 20 times slower than in the server runtime. The application is just slow, not the network.

While I agree Blazor is great, everytime I use it it feels unfinished.

For example binding select inputs to object is not possible while it has been working in other Javascript frameworks for years. Ofcourse you can use workarounds but it always feels like a step back.

And for some project that use custom auth it can be difficult to auth both Blazor and Controllers if you need some.

But overall it is a great experience. And I think frameworks like Blazor and Liveview are the future.

That's what I always think about MS GUI frameworks.

My rant towards Microsoft:

Get some average students and let them build a real world demo application. Write down all the stupid questions they have and all the problems they struggle with. Consider them as bugs or bad design choices and solve them. Do that before you release stuff.

Microsoft delivers amazing quality in some fields, language design (c# and f#), ASP.NET Core and everything in Micrsoft.Extsions.* is amazing. Also .NET Core was a very successful project (after the hell of PCL and .NET Standard).

But WHY can't you build a proper and usable UI framework?!?!?!!!

I really, really want to like Blazor.

I like the shared code. I like that it borrows ideas from VueJS. I like that the recent hot reload efforts have put plugins on the table. I like the VSCode support and debugging experience once I got it working.

I don't like the thought of all the js interopt I will need to do. I don't like thinking about how shimming jointjs is going to go. I don't like the lack of pipeline for working alongside an npm/typescript project for the inevitable js bits that need to be written. I don't like the lack of a preprocessor, bundling, and asset pipeline..

P.S. I hope the culmination of the hot reload work in asp.net will result in official guidance for creating proper plugins (controllers, services, models, assets, Blazor, etc) ala Grails. It feels close with the low level infra gaps being closed.

> fuck around with JSON APIs alone is worth the price of admission

This is true for Blazor Server as well. I just love the fact that you can generate HTML on the server and have the productivity boost of having to work with a React like component system.

Have you tried Flutter Web instead?

https://devblogs.microsoft.com/surface-duo/flutter-dual-scre...

Maui is targeting React Native and Flutter. Same for Blazer with Electron. They make this attempts to bring C# everywhere. Using Flutter, Angular or setting else is the context switch they try to avoid.

For me, as a .NET fanboy, they are a year or two late.

Why not just go all in and back react native? looks like they use it extensively already https://appfigures.com/resources/insights/microsoft-goes-all...

As a developer who is also a Xamarin Forms user I can say - I get really nice performance out of Xamarin Forms these days. I'm not interested in React Native because it doesn't give me anything I can't do pretty quickly. This is also why I'm not interested in Kotlin and the Android SDK. I've been more or less exclusively developing Android Apps using Xamarin Forms for the last 18 months and Maui is way more exciting than anything else I see from other frameworks.

this is very interesting. Are you saying that Maui will generate Flutter code using c# ?

BTW, there's a very interesting (and amusing) bug that advocated "dumping Maui for Flutter"

https://github.com/dotnet/maui/issues/160

Haha ... no. Sorry for writing the sentence like that. My fault. It is not a compiler target but from a business perspective the target audience they address.

Flutter with its Dart language and an own VM is not a goal for .NET. This is the .NET team building a UI framework for C#/CLR/.NET developers. Flutter is different from WebAssembly (which is more a CPU architecture) in that regards. From a .NET team perspective, they see themselves (most likely rightfully) as a full stack competitor to JavaScript and Java and that requires Browser, Apps/Desktop, Server, Web Pages and native Cloud in the portfolio. Dart, Go and even mighty Python are not in the place were .NET, Java and JavaScript is in this regards (yet and from a non-hacky perspective ;)).

Isn't asp.net the equivalent of javaee in the microsoft world?

ASP.NET is the name for a wide variety of technologies Microsoft has developed over the years. If we’re talking the current/modern version, the answer’s no.

No it isn't. Low effort question, low effort answer.

I really changed my mind about Microsoft over the years in a positive way since they changed their attitude over everything that's not Windows based.

That's like saying someone would not like Apple because the support only iOS and macOS. Championing Windows really has never been the problem with MS.

It's the business practices why people generally have bad memories of them.