The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible. A more recent development that has me very excited is Blazor Desktop:
> This leads to the second difference — in a Blazor Desktop app hosted in WebWindow, there’s no built-in web server. Instead, it’s pure .NET all the way down. And while we haven’t seen exactly how this will be implemented, it offers the chance to simplify the hosting model quite a bit. If everything comes together just right, it will be like using Electron without needing to learn Node.
I honestly believe this model is going to revolutionize front-end development. The productivity uplift of not having to fuck around with JSON APIs alone is worth the price of admission. We already use Blazor (server-side) for several of our webapps. 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. Need a projection involving 3 collections to produce a table? No problem. It's literally 3-5 lines of LINQ in your razor file. With a "proper" JSON API, you would probably have to fetch 3 different resources to the client or develop a special unicorn method for each unique projection.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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
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?
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.
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 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.
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.
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.
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 ;)).
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.
https://medium.com/young-coder/blazor-desktop-the-electron-f...
> This leads to the second difference — in a Blazor Desktop app hosted in WebWindow, there’s no built-in web server. Instead, it’s pure .NET all the way down. And while we haven’t seen exactly how this will be implemented, it offers the chance to simplify the hosting model quite a bit. If everything comes together just right, it will be like using Electron without needing to learn Node.
I honestly believe this model is going to revolutionize front-end development. The productivity uplift of not having to fuck around with JSON APIs alone is worth the price of admission. We already use Blazor (server-side) for several of our webapps. 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. Need a projection involving 3 collections to produce a table? No problem. It's literally 3-5 lines of LINQ in your razor file. With a "proper" JSON API, you would probably have to fetch 3 different resources to the client or develop a special unicorn method for each unique projection.