What’s behind the hype about Blazor?
If you’ve been keeping up with the latest developments in the .NET world over the past year or two, you’ve probably heard the word Blazor mentioned once or twice. Blazor is a new client-side UI framework from the ASP.NET team. Its big selling point is the ability to write rich web UI experiences using HTML, CSS, and C# instead of JavaScript—something a lot of developers have been dreaming of.
While JavaScript has been the defacto standard for front-end web development since its inception, we’ve never really seemed to be happy with it. I mean, how many superset or transpile to JavaScript languages have sprung up over the years to help improve JavaScript and make it more maintainable? CoffeeScript, Dart, Elm and Scala—to name but a few.
Looking at the most loved languages, TypeScript, a language designed by the legendary Anders Hejlsberg, tops the list. The same man who designed C#, no less. It adds features such as interfaces, classes, compile time type-checking, even generics. However, all those features and more already exist in C#, and have done for years. C# is a powerful, flexible, feature rich language that is easy to learn.
But Blazor has already started to show it has potential as a highly efficient and productive programming model outside of its original design—as a direct competitor to JavaScript single page application (SPA) frameworks.
Microsoft already has multiple experiments going on with Blazor, trialling it with desktop applications using Electron and WebWindow (an experimental lightweight alternative to Electron). But most recently, for native mobile app development where the Blazor programming model is mixed with native Xamarin forms controls.
Could we be seeing the start of a single unified UI framework for building any type of application with .NET, be it web, desktop, or mobile? I don’t know about you, but I certainly find that an exciting prospect.
What makes Blazor so flexible?
To answer this question, we need to understand how Blazor has been architected.
Essentially, Blazor has a separation between how it calculates UI changes (app/component model) and how those changes are applied (renderer). This sets Blazor apart from other UI frameworks such as Angular or ReactJS/React Native that can only create web technology based UIs. By using different renderers Blazor is able to create not only web based UIs, but also native mobile UIs as well.
This does require components to be authored differently, so components written for web renderers can’t be used with native mobile renderers. However, the programming model is the same. Meaning once developers are familiar with it, they can create UIs using any renderer.
Render/Hosting Model
At its core, Blazor’s app/component model is responsible for calculating UI changes, but you can use different renderers to control how the UI is actually displayed and updated. These renderers are more commonly referred to as hosting models. At the time of writing, there are four hosting models for Blazor in various stages of development.
Blazor Server (Remote Renderer)
- Platform: Web
- Status – GA/Production Supported
Blazor WebAssembly (WebAssembly Renderer)
- Platform: Web
- Status: Preview (Committed Product)
Blazor Electron (Electron Renderer)
- Platform: Desktop (Windows, Mac, and Linux)
- Status: Experimental (Not Committed)
Mobile Blazor Bindings (MobileBlazorBindings Renderer)
- Platform: Mobile (iOS and Android)
- Status: Experimental (Not Committed)
Blazor Server is the only production supported model at the time of writing. Blazor WebAssembly is due for release around May 2020—I would expect this could be the big announcement at Build. Blazor Electron and Mobile Blazor Bindings are both marked as experimental and Microsoft hasn’t yet committed to shipping these.
App/Component Model
This is the engine room of the framework. Here we can find all the non-UI specific elements which make Blazor work. The programming model, routing and navigation, and the render tree, which is Blazor’s mechanism for calculating UI changes.
The part I want to focus on though is the programming model. Out of the four hosting models I talked about above, the first three have one thing in common, they all understand web standards. Components authored to target these hosting models will be using HTML and CSS. But the fourth model, Mobile Blazor bindings, doesn’t understand web standards at all. Applications built for this hosting model will need to have their components written using native mobile controls.
To give a more visual example, let’s look at the same component written for Blazor WebAssembly, which uses a web standards compliant renderer, vs Mobile Blazor Bindings, which uses the non-web standards-based renderer.
// WebAssembly Renderer <div> <p>Current count: @currentCount</p> <button class="btn btn-primary" @onclick="IncrementCount">Click me</button> </div> @code { private int currentCount = 0; private void IncrementCount() { currentCount++; } } // MobileBlazorBindings Renderer <StackLayout> <Label FontSize="30" Text="@($"Current count: {currentCount}")" /> <Button Text="Click me" OnClick="@IncrementCount" /> </StackLayout> @code { private int currentCount = 0; private void IncrementCount() { currentCount++; } }
It’s easy to see the differences between the two code samples, but what I want you to focus on the similarities.
Both samples have a markup section and a code block. In fact, the code blocks are identical between the samples. They each have an `OnClick` event with a specified handler and both use expressions to output the value of the current count field.
The point I’m making here is the programming model is the same. And this is the power of Blazor, learn the programming model and, save a few tweaks here and there, you’re going to be able to produce UI for any type of app, on any platform—that’s something we’ve not been able to do before with .NET.
Now we have a bit more of an understanding about how Blazor is put together, I want to talk a bit about the two main hosting models, Blazor Server and Blazor WebAssembly.
Blazor Server
The Blazor Server hosting model is currently the only production supported option for Blazor development right now. It was released back in September 2019 with .NET Core 3, during .NET Conf.
In this model, the Blazor application runs on the server on top of the full .NET Core runtime. When the user loads the application a small JavaScript file is downloaded which establishes a real-time, two-way SignalR connection with the server. Any interaction that the user has with the app is then transmitted back to the server over the SignalR connection for the server to process. After the server is done, any UI updates are transmitted back to the client and applied to the DOM.
Now, I know what you’re thinking. There is no way that that can be performant, all of those interactions and UI updates being constantly sent back and forth. But I think you’ll actually be surprised.
The team did some load testing on Blazor Server to establish what it could and couldn’t deal with and this is what they found.
Test 1 – Standard D1 v2 instance on Azure (1vCPU & 3.5GB memory)
The application could handle over 5000 concurrent active users without any visible degradation in performance.
Test 2 – Standard D3 v2 instance on Azure (4vCPU & 14GB memory)
The application could handle over 20,000 concurrent active users without any visible degradation in performance.
These are pretty impressive figures, I think you’ll agree. The major findings which came out of these experiments were that memory and latency are the main bottlenecks of Blazor Server applications. If latency got above 200ms then performance took a hit and scale was limited by the available memory on the box.
Benefits
- Runs on the full .NET Core runtime
- Fast development cycle
- Small download size
- Code is kept on the server and not downloaded to the client
Drawbacks
- Doesn’t work well in high latency environments
- No offline support—requires a constant connection to the server
- Heavy resource demand on the server
Ideal use case
I honestly think Blazor Server can be used for lots of scenarios, but its niche will be in intranet applications or low demand public-facing apps. The speed of development with this hosting model is obscenely quick, and I mean fast, due to everything being on the server. There is no need for separate API projects, for example, you can just consume application services directly in your components. I was sceptical of Blazor Server at first, but I have to say, I have been really surprised with what it can do.
Blazor WebAssembly
This is the big one, the hosting model that usually gets most interest, and for good reason. This model offers a direct competitor to JavaScript SPAs such as Angular, VueJS, and React.
By using WebAssembly, we are able to write our UI logic using C# and not JavaScript. It’s currently in preview and due for release around May 2020.
A version of the Mono .NET runtime, compiled to WebAssembly, is downloaded to the client’s browser along with the application DLLs and any dependencies. Once everything is in the browser, the Mono runtime is bootstrapped, and it, in turn, loads and executes the application DLLs.
I’m going to address the first question that usually arises from hearing the above explanation, what is the download size? Well, the current preview weighs in at around 2.4mb, that’s pretty impressive considering there’s a .NET runtime involved. But I appreciate that this isn’t amazing when compared to some JavaScript frameworks. By the time the WebAssembly hosting model is released in May, the team hopes to cut that size significantly. The first prototype of Blazor used a very compact .NET runtime, which compiled to just 60k of WebAssembly code. I believe major size improvements are just a matter of time.
Currently, Blazor WebAssembly uses interpreted mode to load and run your application. In this mode, the Mono IL interpreter executes your applications .NET DLLs inside the browser. The only part of the process that is compiled to WebAssembly is the Mono runtime. In the future, the team are looking to allow developers to choose if their apps, or more likely parts of their apps, will be compiled to WebAssembly as well—This is known as AOT or Ahead Of Time compilation. The benefit of this mode is performance, the trade-off is a larger download size.
Benefits
- Compiles to static files, meaning there is no need for a .NET runtime on the server
- Work is offloaded from the server to the client
- Apps can be run in an offline state
- Codesharing, C# objects can be shared between client and server easily
Drawbacks
- Payload. Right now if you create a fresh new Blazor project, it weighs in at around 2.4mb. The team hopes to cut this down significantly come May.
- Load time. Due to download size, devices on poor connections can experience longer initial load times.
- Restricted runtime. Apps have to operate in the browser’s sandbox and are subject to the same security restrictions as any JavaScript application.
Ideal use case
Blazor WebAssembly is built to be a direct competitor to modern JavaScript frameworks. Therefore, anywhere you would be looking to use one of those frameworks, you could consider Blazor. It’s also trivial to make Blazor WebAssembly apps into PWAs (Progressive Web Application). In fact, there will be an out of the box template for this coming in May.
It’s also important to point out that using Blazor WebAssembly doesn’t require you to use .NET on the server. Meaning if you have a backend written in Node, PHP, or Rails you can happily use Blazor as the frontend without any issues as Blazor WebAssembly compiles to static files.
What’s the future of Blazor?
With one hosting model in production already and another on the way shortly, let’s finish by turning our attention to the future.
Where do I see Blazor going? Coming back to my earlier thought around Blazor becoming a single UI framework for any .NET application. I think this is where Blazor is heading, in my opinion. If all of the current hosting models for Blazor move into production, and right now I can’t see why they wouldn’t, developers will have the option to learn a single programming model which they can use to create UIs anywhere. This is a big deal.
At a time where there are lots of discussions around the barrier for entry to .NET, with so many choices new developers to the platform have to face, Blazor could offer clarity when it comes to UI, a single programming model, learnt once and applied anywhere. For me, that’s the hype with Blazor.
131 Comments
I’ve been using it since September and experimenting with it more than 6 months. It is one of the easiest things I have used to develop web applications. Now we are using the server side Blazor in a few projects. There are some glitches but it is way more productive in comparison with the JavaScript frameworks. In case you’ve never heard of MatBlazor, I strongly suggest you to take a look at it.
I personally loved this concept and playing a bit with blazor server and it is awesome. Using js in client side is difficult to implement and debugging js is just horrible. But blazor is good enough to bypass those problems. It’s so good, fantastic.
“Using js in client side is difficult to implement and debugging js is just horrible. ”
Then you’re doing it wrong
Please. What a disrespectful reply. Everybody must be doing it wrong then, because this comment is near universally true. I watch seasoned front-end devs struggle to debug JS or even explain how to debug to a noobie.
@stevesitwell, your comment didn’t help @MONOJ BHUINA, did it?
Then you’re doing it wrong.
But who said, that the purpose of his comment was to help anyone?
He just shared his opinion, like Monoj did. The fact that he disagrees with original poster doesn’t make his comment any less valid.
By the way, he is right: Javascript is easy to write and easy to debug on client side. Knowing how to use dev tools in browser is giving everything you need. You can check every function call, microtask, render in “Performance” tab. You have “Performance Monitor”, “Console”, “Coverage”, and even tabs for specific API (for instance testing sensors, like gyroscope). If someone is more C# dev than JS dev, that’s obvious that he likes more project which utilizes his more liked technology/language and that he is not necessarily familiar with other language than his main.
@Matt, not everybody, but I can risk a statement, that most web devs doesn’t know about possibilities of language and tools they are using. Then, it’s not a surprise that they complain and have problems.
So imagine I have something which responds to each keypress in a text field. Maybe it’s validating. It achieves this in microseconds locally. Blazor is insisting on making a server trip? Why? Why take away the local option? Even if you can make it reasonably fast this can’t be a step forward for user experience.
@Admantish who also replied here: Your statement is only true for Blazor Server. With Blazor WASM everything that can be executed locally is executed locally, no servre roundtrip necessary.
No one is obliged to respond to slanderous opinion and ignorance with coddling attempts at “help.”
what an unhelpful reply.
debugger;
Boom!
Agreed. We’ve had a Server Side Blazor line-of-business app running in production for a client for about six months now and it’s significantly faster to develop high quality (i.e. SOLID and tested) code than it is on our MVC/JS apps. Having all the business and validation logic in a single language, rather than needing to do it once in JS and then again in C# on the server side is saving a lot of time, as are the type-safety and general benefits (for us) of working in C#.
5 yrs from now, no one will be taking about if. It is time if the year where ms likes to create hipe. Next February, no one will talk about it
you’re right, Microsoft creates hype about everything they do, but it’s not like Windows Phone every time!, many of their hypes got picked up by the community and became very successful even if MS stopped hyping it (e.g. .NET core, fluent UI, Entity Framework …) and Blazor solves many painful problems and saves money for IT companies by cutting development time/cost and learning curves.
I find that only Microsoft really wants to give great tools to developers and Blazor is no exception, and TypeScript before that. Anyone who didn’t try their tools doesn’t understand the HUGE GAP in the development experience, it seems sometimes like decades! Blazor Web
Assembly however is still not pleasent to debug and very non-Microsoft like, so I’m waiting on it…
This will get picked up by IT departments and become the new legacy. It cuts development cost at the cost of added hardware expense and poor user experience.
Haven’t we seen this before? It was called .Net Forms providing a tag based presentation connected to C#/VB.Net code via events and then rendered as plain HTML, CSS, and JavaScript.
Nope, It’s different because there is no Javascript (well, if you want you can use it) because it uses C# WebAssembly. My first thought was just like you, but searched more about it and found it’s like more Angular/React than Webforms
@Nuno – high-level and conceptually, Blazor rendered on server-side it’s using the same principle as ASP.NET WebForms+ASP.NET AJAX framework, just using modern technologies.
The similarity is using c# and tags but they basically deferent technology from architectural point of view, technologies and patterns. WebForms was completely a wrong way although it could be useful in its era.
Can we say angular and react and jquery are the same technologies thay all use javascript and html for developing web applications?
We can say it here moreover blazor use webassemply.
Even a angular or knockout developer may be more comfortable with blazor.
Blazor looks a lot like Vaadin. It is not the same but many things sound very familiar to someone who knows Vaadin.
nah… it will die just like their other web platform framework…
And this is, where I think, that you are wrong.
Earlier, MS tried to push their proprietory solutions, while now they use Web-Standards, which all modern browsers understand.
I am not a dot net nor even a web developer. How does it then feel to hear me tell you that you are totally wrong? MS is indeed using “web standards” and a bit of smoke and mirrors to roll their own proprietary solution. This is because C# does not compile to Web Assembly the way that other languages compile to WASM. It is .NET that is compile to WASM and as such, apps, module or is it components that are written in C# are not usable from other languages. This is why the whole .NET run time needs to be downloaded first and as such, Blazor is not practical for building landing pages where users are in and out and if they are not in within fraction of a second they are gone. There was some talk about compiling C# to WASM directly but am not sure where they are with that. So, Andreas, please tell me which one of us is clearly wrong. 😉
Do you think BLAZOR will be a best candidate to create an ERP?
ERPs need technologies that have been around and will be around guaranteed and supported for at least two decades. 🤣
Are you thinking of a different Scala than Scala the programming language? Because Scala has its roots in Java, not JavaScript.
They are probably referring to: https://www.scala-js.org/
How is Blazor Server any different from ordinary ASP.NET MVC server-side rendering?
Almost the same but only yields compact representation of UI diffs.
There are very significant differences between the two, they are very much not the same.
Then you have not tried Blazor or understood the technology behind. DOM manipulation at C# level, easy and re-useable component build-up and super easy state container management just to mention a few things.
You can use C# for UI logic that you would have otherwise had to use javascript for (like having a click event show new dom elements). It’s also an entire SPA framework with components and routing,
This is well-covered in the official docs: https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1#comparison-to-server-rendered-ui.
One of the key differences is that you’re working with a component model like, say, React. It’s easy to look at Blazor and conflate an MVC partial view with a Blazor component, but whereas a MVC partial is (or should be) just HTML, the Blazor component is a fully self-contained and reusable entity that has all the logic needed to make that part of the page work. That makes it much easier to break up the page into smaller reusable and testable chunks.
Higher cost, longer time to computer, greater memory usage, higher bandwidth.
Why would anyone want to write web apps in C#?
C# is an amazing language, but nowhere has the package support/community base as Javascript.
Also in 2020, I would pick a new language to write web apps, it would be Go lang. It offers, amazing speed, terse syntax and very easy to pick up.
If you are writing your back end in c# already, there is an obvious code resharability if you can also write your front end with c#.
Package support? All the things that come with .NET Core for a start, plus whatever you need from NuGet. After all it’s just executing DLLs
Because if you never reuse code you’re not vulnerable to the left-pad problem JS has. Because the schools dont teach JS. Because Visual Studio chokes to death on node modules still. Mostly because of baby duck syndrome.
Very true. Same here. Building 2 dominations at the same time with ease. Server side blazor.
I love blazor but…
The mobile blazor bindings seem to rely on xaml. That’s a bad choice. The best css/HTML specialists come from the web sites world, not the app world. In websites, blazor has few relevance. One day, a successful app will need css people, they won’t be happy with xaml. Blazor improves one factor of web app building, the process part, the c# which is superior to JavaScript and typescript. The other two factors, styling and markup, css and HTML, should continue to rely on industry standards.
Hi Paul,
I’m not sure I understand your concerns. Mobile Blazor Bindings is for building native mobile applications, not websites. Also, as far as I’m aware at least, it doesn’t use XAML. As for web-based Blazor apps, you do use HTML and CSS to build components.
Thank you for the great article, Chris. Is it possible to have an MVVM approach to writing the C#? In other words, have view models and less event handler “code behind” approach.
Yes, you can create a code behind file to store the main of the logic code. This way it keeps separated from the razor part wich is where HTML is generated.
You have two way databinding and validation included, on standard HTML forms.
Thanks, Pablo. I was thinking more in terms of this: https://blog.jeremylikness.com/blog/2019-01-04_mvvm-support-in-blazor/
Not baked in the framework, as stated there is expected to use whatever model you like. Many (and myself) are using Flux variants instead of MVVM.
There are various open source frameworks to handle this things, with different levels of maturity.
Hi Alex,
Yes, you can use the MVVM pattern with Blazor. The framework is very unopinionated about how you build your applications.
Thanks, Chris. Can’t wait for the WASM version of Blazor in May. And great job on the article! Best write-up of Blazor yet.
There’s already a language that does mobile, web, and desktop, along with games. JavaScript. And yes TypeScript was created by the same guy that ripped off Java. I mean created C#. But he says he created TypeScript as a better version and an alternative to C# but with JavaScript. I prefer TypeScript to C# and JavaScript to both of them. I don’t see .net replacing anything that JavaScript does now and has done. Maybe an alternative but replacing? Highly unlikely.
Current JS frameworks and tooling can be very complex and time consuming (for example Webpack).
Blazor will not erradicate JS, it’s an alternative.
Well, the resulting webassembly is not quite the same as a default html/JS application, it is a new way of providing browsers with their content which can be very performing, better than plain js.
There exist several transpilers to go from one language to webassembly, blazor is just one of them.
But the great part is that you now can do everything with this one technology, and won’t need 4 different technologies/languages/profiles to make 1 application.
And Btw, Java has copied more ideas from c# the last decade than the other way around…
Nobody ripped- ff Java. Nothing that Java has is in any way original, so it cannot be ripped off.
“Nothing that Java has is in any way original”. Not today, no, but when it came out it was the first language of its kind, which is why it gained so much popularity. Object oriented, garbage collected language which could be written once and run everywhere was very original in it’s time. Now I’m not sure if any of those things (garbage collection, VM) originated in Java or in other languages, but Java was the first language which implemented all of that. C# came to life cca 10 years after Java and was very similar to it. So you could call it a “rip-off of Java”, or you could call it “being inspired by Java”, or you could call it “a better Java”. It doesn’t matter in the end, but it did came after Java and it did have very similar features, so no matter how you call it, Java was original as whole language, and C# kind of copied the idea.
All those things (C-like syntax, OOP, garbage collection, Virtual Machines) had existed decades before Java. Nothing about it ever was original.
(And before .NET, which came cca 5 years after Java, MS already had different platform and different OOP language with automatic memory management).
(ed note: removed some unfriendly language. Let’s be respectful, everybody) The only thing original about Java was how incredibly badly it combined features from existing languages into something truly horrific. Guess who leaked this memo?
https://www.eweek.com/development/memo-criticizes-java-platform-solaris-os
Well Microsoft tried to adopt, embrace and extend Java with its own J++ compiler and runtime. When they got sued bu Sun or Oracle, they followed up with a very similar (but improved) .NET and C# a couple years later. So Java => J++ => C# was certainly a technology evolution stream in the late 1990s and early 2000. Since then .NET technology has advanced at pace, until the ill fated Microsoft Build 2011 dumped on all the .NET developers. Thankfully Xamarin had faith in C# and .NET so today we now have .NET Core
Nice overview.
However:
> Essentially, Blazor has a separation between how it calculates UI changes (app/component model) and how those changes are applied (renderer). This sets Blazor apart from other UI frameworks such as Angular or ReactJS/React Native that can only create web technology based UIs.
I believe React also has this separation. There in fact numerous React renderers available.
React Native is different than React for the Web. Blazor code is ALMOST the same for all the supported platforms.
You can share a lot of code, more than with React.
I believe you are right. React is the behind the scenes logic and for example ReactDOM is a renderer for the web. They also have something for React Native, there might be something for VR, Windows 10 and Dice has one for their Frostbite engine because Battlefield 1 UI was created in React.
Can’t wait for Campack!
I primarily do HTML/CSS/JS work so I don’t know C#, but my colleague is hyped because he loves C#. Tbh with any kind of emerging technology/approach like this I would personally wait a couple of years to see if it will gain any traction. Microsoft can pull the plug any time if they decide it.
And yeah, if you are doing any real world project where you need to support Internet Explorer 11 (will it just die already?) the WebAssembly hosting model is out of the question.
there is probably a polyfill for that
This sounds like what GWT was supposed to do for Java. Nobody uses GWT anymore — including the folks who contributed the ‘G’ in the name, Google — and for good reason.
Look at Vaadin.
Blazor Server is like Vaadin and Blazor WebAssembly is like GWT.
You might give credits to https://github.com/praeclarum/Ooui, which, as far as I can say, envisioned this kind of coding.
This just appears to be the latest attempt by Microsoft to do this. See WPF/Silverlight, etc. All of which died because they’re simply too inflexible and rooted in an MS stack that is too cumbersome and slow to react to changes in technology.
Silverlight is defunct, but WPF is still chugging along. Microsoft is making a major investment in open-source WPF for .Net Core 3, so there’s still life left in it.
They Got Lazer, Blazor, Taser and all kinds of ‘azer.
_I think that guy might really be dead_
you forgot Razor
I’m on the way to crate an app with asp.net core 2.2 and jquery.
For me, asp.net core is really stunning (I love it..)
I’m with you, that it would be fantastic to be able to create an app without any JS, as the interaction between the controller (c#) and the view (jquery) is horrible for me and takes the most amount of time.
But I think, it’s to early to get on the blazor train, as WebAssembly don’t allow direct DOM access yet (and – if you want to create really performant and stunning app’s — I think, you need it).
And.. as long as I need JS code in addition, I don’t will spend the time to check out blazor in detail…
In Blazor WebAssembly you still need to write interaction code between controller and client. Unlike Blazor Server
Just so you know Dotnet Core 2.2 ist already unsupported please consider updating to 3.1 or downgrade to 2.1.
Is there a way for a Blazor application to be deployed serverlessly? Like for instance with NextJS using Zeit Now as cloud service I can deploy my NextJS application and each of its endpoints runs as its own serverless function on Zeit Now.
How about Static Site Generation. This is currently an increasingly popular option when developing a website. Is this also a possibility with Blazor?
check this out https://chrissainty.com/containerising-blazor-applications-with-docker-containerising-a-blazor-server-app/
A new framework and this is the way to get a default value in ?
Text=”@($”Current count: {currentCount}”)”
Makes me cry
String interpolation makes you cry? Binding a component prop in any js framework will look very similar.
I wonder how much “heavy resource demand on the server” would affect/increase metered resource costs for Azure and other cloud services.
A 2.4mb payload??? Totally unacceptable. Where is the corona virus when you need it?
Are we forgetting that 80% of people use a CELL PHONE to surf the net. A constant server connection of any kind means people are going to need to use data in the same manner as streaming a movie just to use a website. This is a really bad idea. NO one is going to use a website that just viewing takes a constant stream of data. How many of you, like myself, open a window and just leave it up and walk away form it??? Not to mention that you are just leaving an open line for hackers to access the server. Do you really want to make your application dependent on something that can only handle a certain amount of users and is guaranteed to crash or slow with unexpected jumps in users???? It seems like Blazor is just a way to set yourself up to fail. Their is so much involved in building any ASP.NET app from razor, C#, Entity Framework, html,css, JS, forget any Typescript. As far as I am concerned it is just another thing to learn that is a HUGE security risk and a data hog which is going to piss off your users. We need to think of these frameworks and languages as tool to solve problems in the real world. Their is no magic language that is going to be the best solution for every problem, use the right tool for the job. Unfortunately as a developer that means learning as much as you can but then also knowing when the language you work in, is not going to be a good fit for a certain application. All these developers that think they are so smart always seem to overlook the biggest part of any app, THE END USER!!!!
It seems that you didn’t read the article…
He already concluded that the Server Side Blazor would be best fitted to intranet applications.
But you completely ignored the Client Side blazor, where no one of the problems you mentioned are actually a problem.
Please read before scream 😉
Why is he raging about Razor when the article is about Blazor?
He also says you need JS, which you probably need, but you can wrap it in a real language so you know where to look when errors happens.
I guess he never had to maintain a project with several hundred thousand lines of Js code. Scripting languages for the web will die, if it is by Blazor or something else I don’t know, but this is a step in the right direction.
Agree. I once had to fix a project using an older version of openlayers. It was 2000+ lines of JS madness in each file. It took a very long time to fix even simple bugs.
It’s a signal R connection, it’s not polling constantly. Not sure why you think it would use a lot of data. Also not sure how it would be any more of a security risk than any other API end point.
There is not “constant stream of data”. The SignalR sends data on change request basis only, in Blazor for DOM rendering and it only send a low byte range transfer to maintain the stability of the connection. So, if you stay on the SAME page for 24 hours you may have downloaded MORE data than a page refresh would do. But I dont think many people do that. Well written Blazor Server application should not get you drowning in data.
And you can later convert to WASM if you think data is a bottleneck.
I’m not sure that’s true about SignalR traffic being limited to change request basis only. If you shut down the web server (or the client network connection) the client-side page knows immediately. It’s definitely not a traditional form submission type interaction where a client-side page stays operational and only cares about the server when you submit data. It’s constantly talking to the server and when it loses that server the client is basically inoperable until the connection is restored. I’m not saying it’s a crippling amount of data being transmitted like OC, but it does seem like continuous background comms regardless of user action.
5G? 4G LTE? You can also use server side rendering and mix and match blazor components w/ regular web pages. Much better IMO for an app than a pure SPA.
Been running Blazor project for about 3 months now and I really like the neat features in the component buildup, things like super easy state container management and the easy C# driven DOM manipulation. I did have problems implementing the MS Identity Core functionality into Blazor components, as the Identity code uses the response stream header for token, but when you’re inside a Blazor component you dont have the response stream available, you have only SignalR. And an exception is thrown from the Identity core as it can not find the response stream it expects. This should, however, be fixed with version 5. So creating a re-useable Blazor login/logout component is not possible yet.
Solution is to scaffold into Razor pages for now and then let the main response stream handle the login/logout. After a few tweaks, I got it running and now it works smoothly. Have run into a few w3p service crashes, but only in development scenarios building to IIS.
It is no coincident that MS decided to roll Blazor into the ASP.NET team, it has great potential. Ok we miss many of the feature-rich solutions provided thru fx jQuery and vanilla, but where needed the JSInterop function really great. So there is still work to do, the framework is still young, but lets see on the next release what they can come up with 🙂
Small download size? Mono.wasm is 3mb. I don’t want to know what your usual applications look like.
Blazor is a solution looking for a problem. Rust wasm frameworks are already years ahead of where Blazor will ever get. It’s at best just another way to allow Enterprise devs to continue moving forward with marginal skills. It’s cancer tech.
Intranet Developers that are already trained in writing a lot in C#, maybe have some MVC skills and a bit knowledge of how web works, are SUPER happy imo. They can enhance their enterprise stuff from deploying WPF apps to „just go to a intranet web page and use our tools“ instead deploying wpf apps and have so different versions in the wild of the enterprise.
But: Thats it!
As many said above, any real world web developer, being in this business for 5 years +, will just laugh about that stuff. Blazor is from an enterprise focused company for enterprise focused problems. The web ticks totally another way. No real web developer, that have to handle browsers, caches, mobile devices, SPAs, webviews, and and on a day to day base, will ever become happy with Blazor and MS. NEVER EVER. Thats hillarious.
So, Blazor is nice and all that, and it will have its niche where it excels. But Blazor as a new web standard in the real web? This will not happen.
Disagree. I just switched from Angular to Blazor. Development is so much faster, and there is nothing we currently can’t do (Except run the website i IE11, lol).
We rewrote the angular app which took another team two years to develop, in two months, with a ton more features, and a login system that actually worked.
3mbs on my 100 MB download speed is negligible. I love that weak argument. The point is not to compare wasm frameworks. Wasm was created to allow web development with the language a dev is comfortable with using all while avoiding the horrid Javascript lang.
Most web-devs will continue using java-script and whatever frameworks and libraries they currently love. And that is all just fine. No problems there.
But there are thousand of other devs out there. Devs that has been working mostly with Desptop apps. Devs that has not worked much with web techs. Like me, perhaps they have worked with Basic, Delphi, Java years ago – and are now primarily using c# but have played around with Angular and VueJS without liking it much.
For them Blazor is a very welcome tech, that makes it easy to do web apps.
That is important because skills in making Desktop app is nowadays not as important as having skills in making Web apps. Web app seems to be the future. Even comparing to native mobile apps. That is just my personal point of view.
About 31% of all developers use c# (https://insights.stackoverflow.com/survey/2019#most-popular-technologies) – I guess many of them will try Blazor if their next project is a web solution and they do not like/know java-script.
I agree 100% with you… but the problem is that you will not have many jobs with it… what would you hire, a Blazor dev or a React/Vue dev ? How many would you be able to find ? How does Blazor performed compared to the other stacks mentioned ? Maintainability ?
That is why React/Vue/Angular and many other exists… Microsoft is still trying to create their own HORRIBLE thing… what company in his mind would use Blazor ? It is horrible looking, it is way 1990’s…
That is only why I don’t recommend this…
Not many jobs? I am working in a job with it now! And, there will be many jobs if you’re a C# house because all your developers only need to learn HTML (JR devs should already know HTML) and apply what they already know (C#) for the logic. It’s a no brainer.
i tried to make a page using bing maps (google wanted my credit card number for google maps) and the jsinterop made me abort and go to plain js for now but in a month or so i will try again blazor or maybe vuejs. i wish they’d allow js in a component or make c# functions easily callable from js
Yeah, that’s absolutely possible with Blazor. It’s called JSInterop. You can call C# functions from JS and also JS functions from C#
Are there any risks in releasing Blazor Sever into Production at this time? It doesn’t appear to have a testing framework yet (apparently one is being built, but isn’t yet in Alpha) and its longevity is still unknown, obviously. Are there any arguments for going with Blazor at this early point in its life? No one really knows how it will change over time, will the next version break the current version, etc.? These seem like the biggest risks at this time.
Blazor looks promising, but I worry if they will get it right this time. Microsoft really failed at AJAX in the past, starting with asp update panels through Ajax.BeginForm in MVC today. Are the same problems going to trickle into Blazor? One big speed bump I’ve run into is state management which is not built into Blazor!
very nice, type-safety and have all logic in a single language is awesome !!!
History is bound to repeat itself:
– Mid 60’s: Essential importance of maintainable software, which gave rise to the study of how to make it better, 50 years worth of research and painful lessons
see: https://en.wikipedia.org/wiki/Structured_programming
– The cost of coding is just a small fraction of the overall life cycle costs, thus maintainable software is of paramount importance
see: https://courses.cs.vt.edu/csonline/SE/Lessons/LifeCycle/index.html
C# – 2002, based on 30 years of academic research and industry experience into how to lower the software life cycle costs
JavaScript – Intended to address a different set of requirements
– https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html
Today, massive amounts of JavaScript code and an untold life cycle costs that are still be realized
Rinse &repeat
I’m primarily a desktop app developer with 20+ years of experience. I’ve dabbled with various web app tech over the past few years, but they’ve always seemed archaic compared to developing a .NET desktop app. with a similar UI experience.
I’ve recently discovered Blazor, liked the concept, spend a couple of days reading about it, and watched a couple of videos on YouTube . In just that short introduction I’ve managed to created a complete HelpDesk app. There’s no way I could have achieved the same using React/JavaScript and everything else even though I’ve been working with those technologies for the last year.
Blazor may not be a silver bullet, but it’s certainly a step in the right direction.
Excuse me, that is because you never saw VueJS, is like learning Python if you already are a programmer… That horrible HTML tag with that 1990 looking is absolutely horrendous… Vue/React/Angular, solves this problems… don’t go backward !
.Net community seems to be so disconnected from current web apps and tools out there… that is so Microsoft…
Why blazor documentation is so poor ? For example – how I can determine current version of blazor in VisualStudio project ? And migrate it to latest version.
The render performance of blazor webassembly is extremely slow when you app have many components such as dashboard component. There is no way to solve this problem. I hope microsoft know this problem and fix it asap. otherwise No one will use this.
> This sets Blazor apart from other UI frameworks such as Angular or ReactJS/React Native that can only create web technology based UIs.
This seems to be slightly incorrect.
React is the core library and there are different renderers such as react-dom and react-native similar to how Blazor has multiple hosting models.
React Native is not about web technology based UIs. It is a mobile application framework for iOS, Android and others.
If the intention is to have a general component development language it should be rewritten without the current limitations, and I hesitate Blazor team is willing to break what they have been released yet. Particularly, the invalidation system doesn’t work, there is no visual tree, which causes limitations in customizing components, and animations cannot be developed correctly.
“Blazor could offer clarity when it comes to UI, a single programming model”
I hope so too but am fearful Maui will screw things up!
In Blazor is missing five main components:
1. VB.NET support – Why Microsoft vilified Visual Basic – (http://www.vb-net.com/WhyMicrosoftVilifiedVisualBasic/Index.htm) ?. C# syntax was born in 1978 year and VB was been develop as improvement stupid C syntax, for delete most stupid C ideas, for example named full different conception like Inheritance and Implementation by the same character “:”.
2. Designer like designer in Classic ASP.NET. Designer is not browser to show Html-markup, Designer give programmer main tools for RAPID creating sites, by click on HTML-elements EventHandler was been created automatically with all closures, Designer tools and so on.
3. Blazor contains only four simplest builting components, there are nothing convenient to ASP.NET Classic components like GridView, DataList and so on.
4. jQuery support and integration. jQuery was be supported perfectly in Classic ASP.NET and then MS leave to support most of main tools for programmers, of course including jQuery.
5. In each previously ASP.NET technology we can simple changing source code (including with Debugger) then simple press refresh in Browser and code was been recompiled and changing in background. After few seconds we was have new code in Browser and library. But in Blazor this development is not work now. If we want to change something, we must stop debugger, stop IIS, stop Browser. Make change and then restart application. This permanently restarting set of application slow down development process at millions times.
As a result, this restriction of ASP.NET Core Blazor technology give programmers only tiny percents of performance ASP.NET Classic programmers, in ASP.NET Core Blazor you will create for months the same site as Classic ASP.NET programmer could created during one day, but this obscure is full fit to Microsoft point of view – price of any software in the world must be increase, so that can be induce increase cost of Microsoft stock as software leader company.
The point is not using javascript at all so some of what you’re saying isn’t the idea of Blazor. While you CAN integrate JS in, it’s not really all that pretty in my view and in most cases not needed given the components that exist for Blazor. There are a lot of 3rd party components already that do I’d say 99% of the JS components or MVC components that exist.
How about SEO on blazor server
It is easily possible and works well.
How can someone on his mind like this “. That is absolutely horrible, you have CSS to do that, if you want to do `Text=”something”` you can use Vue, React, Angular… How can you like that simple HTML tag with all these attributes ? It is the worst thing I have ever saw in 2020… that is so VB.Net… I have been working with PHP since 5.3, I used Laravel with Vue since Laravel 5.3+ until now, 7.x, I have used Angular in older projects… Now I also user React… I used XHTML + CSS since I have memory, now HTML5 and CSS3…
How is that thing a thing on 2020 ????
I really don’t understand these devs… you go backwards…
Been here before, ten years ago with Silverlight. When we were able to develop great Web clients, in C# and .NET technology.
The Microsoft dumped on us .NET developers and Silverlight fans at Build 2011. So i don’t think I will trust Microsoft for a while. Especially s they seem to announce a new UI framework every couple of years. Need to wait 5 years to see if Microsoft are serious about supporting this technology.
The difference here is that Blazor is implemented using a standard technology (Wasm) rather than a plugin. The question isn’t whether Blazor will succeed or not, it’s will Wasm succeed? I for one think that it will. Several different languages can be used to create Web Assembly apps, and that list will only get longer.
Unfortunately, C# is not one of those languages. It can not create WASM. I will let you have another go at it by telling us what I am talking about.
From my point of view and those bind syntax, it’s more like asp.net by remvoing .net, if anyone here using ASP before.
For all who argue that JavaScript has more packages: Blazor component libraries are sprouting like the mushrooms after rain. We even created a pure C# Material Design component library within a few months: https://mudblazor.com
And if the existing C# libraries are not enough, you can always easily add in JS libraries but the truly great think about Blazor is that you are not forced you to write JavaScript any more. Having written my fair share of JS-based web services I gotta say, I love that I don’t have to any more.
I decided to learn .NetCore and Blazor thinking that it is the future to create business projects, to motivate myself visit the resources for Blazor UI such as:
– https: //blazor.radzen.com/
– https: //demos.telerik.com/
– https: //www.matblazor.com/
– https://mudblazor.com
And the experience is really horrible, the delay in the response of Blazor Server and SignalR is very annoying due to each event that takes place. I guess for now it will be useful in intranet projects.
Then we will have to wait for 5G to really be useful for the internet. and Blazor WebAssembly cannot be considered to make real applications, that of downloading the dlls, assuming that all your users have the same resources is not an option for me.
I’ll have to go back to my beloved frameworks: Angular, React, and Vue, for now.
Also, Syncfusion Blazor components library has 65+ high-performance, lightweight, and responsive UI components, including file format libraries in a single package for building Blazor web apps using C#. Explore more about Syncfusion Blazor components https://www.syncfusion.com/blazor-components and demos: https://blazor.syncfusion.com/demos/
Still Blazor is a failure if this cannot do the important feature of web developent which is manipulate DOM.
Well it outputs DOM and updates it just like React etc. wich is fine. If you actually depend on direct DOM manipulation in common app scenarios, you’re doing something wrong.
I’m really confused between MAUI and Blazor, can someone explain in detail?
Clearly Anders Hejlsberg has not been involved in Blazor, it’s crap. Go ahead, try to run it on a WAMP server and see how far you get. It might do as something to replace old asp.net sites but the rest of the web development world will not adopt it. This means it will the go the way of the Windows Phone, developers will abandon it and then finally Microsoft. If I need the speed of Web assembly then I’ll probably develop it in Rust.
We’ve been using over 2 month as well. The development cost really is significantly but only this byself is enough? Especially I’ve heard lot of issues related to WASM but I’ve also still hearing issues from other libraries.
Still I’ve wonder server side because it opening active TCP connection . If we talk about the performance on the end user pretty fine but I’ve still grayed-out points.
* Is TCP connection a cost by in itself or not?
* Is Maximum TCP connection or maximum HTTP request?
* Is cost of server resources or cost of client resources?
* Is UI rendering will affected through server resources?
I wish there was benchmarking SignalR approach and HTTP approach. Because I really fall in love writing everything in c#. but that is the puzzling my mind only is; which with should I develop
Single Page Applications (SPA) are always better in terms of performance and user experience. Your front end is running in the client machine and only the API server behind. Thats a simple architecture.
Server Side is Blazor is not an SPA, Can’t compare with Angular, React. Only WebAssembly Blazor can be compared with SPA JS frameworks. When it comes to WebAssembly, we need to see the browser support, debugging support, support from Microsoft, Maturity etc., Otherwise, Just because of C#, you won’t chose Blazor. If you know C# well, Typescript would take only 3-4 hours to master. Compared to Chrome V8 JS performance, WebAssembly performance wouldn’t be noticeable. Hence Blazor is still few years away before even considering for complex production application. Lets check back in the year 2025
I’m really confused between MAUI and Blazor, can someone explain in detail?
We made the unfortunate choice to use Blazor Server in production.
Like many Microsoft products, it is easy to use and lends itself well to flat, no-architecture tutorials. But in real life, it is not suitable for a professional project that can be maintained over time.
I have done a lot of desktop app development and read a lot about Blazor.
I am interested in upgrading my WPF app to Blazor WebAssembly PWA.
Blazor Server was never an option because of this constant connection.
I don’t want a round trip to the server just because a user keydown event.
It’s unacceptable for a Desktop developper, lol.
It makes a lot of the same mistakes that were made in web forms. The control tree/rendering composition layer is something that people are fighting with over what would be trivial in a typical web application. Uno.Wasm.Bootstrap provides a standalone framework for building client-side C# WASM packages. I’m working on using that to wrap JQuery, providing an interop layer between client side C# and the HTML DOM. Personally I think that’s a more composable solution that allows this approach to be used in existing traditional web apps. I
I don’t know why Microsoft wouldn’t start with basic building blocks like this, then later build Blazor on top of that. MVC is a great building block technology because it fits nicely with how the web works. It gets you really close to the GET/REQUEST nature of HTTP while easing the tedious plumbing with things like routing and model binding. You’re still generating traditional HTML, so you can still leverage Javascript and CSS. Blazor is basically, throw away all your experience from the last 15 years and do things completely differently, build skills that won’t be transferable anywhere else, and fight our framework to do trivial things you could easily do outside of this confined box.