A couple of weeks ago I wrote an article about building and deploying a Blazor app without touching a Windows machine and realized maybe I should take a step back and explain what Blazor is and why anyone would use it. It's still fairly new to most in the front end development world, but it's awesome and you should check it out.
So what is it, exactly?
Blazor is a framework from Microsoft that you can use to develop interactive client-side Web UIs with C#.
In their own words:
Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries.
Pretty cool right? You can download it here and get started.
The old way
Remember the old way of developing web applications?
For the longest time, we built applications that ran solely on the server, using things like ASP.NET, PHP, etc and they generated an HTML file to be pushed to the browser.
We've always had some bit of interactivity with JavaScript and AJAX but for many years most of the business logic is handled on the server itself, spitting out HTML pages to interact. The browser for many years was just a glorified document viewer. It worked, but we knew we could do better.
There are some downsides to this pattern that we're all aware of:
- The server needs to be configured with software to run the web app. ASP.NET, PHP, etc. Backend processors or runtimes have to exist on the server.
- Most of the processing power is on the server.
- Page loads are annoying and slow.
So we found a new answer to it.
How we do it now
With the rise of the Single Page Applications we have a new pattern, with frameworks like Angular, React and Vue:
Now we're building full applications in JavaScript that run on the browser. This splits the business logic, so that some runs on the browser, and some runs on the server. JavaScript applications run client-side and use messaging to communicate with the "server". You can easily replace "server" with a service or application in the cloud, but the model is still the same.
This is an excellent improvement on what we had before, which essentially manipulating HTML and tossing it back and forth. Now we have real applications running in the browser, and page loads are mostly a thing of the past.
But Blazor improves on that pattern further. There are two main ways to develop with it.
Option 1: Web Assembly Method
When you choose to build a Blazor Web Assembly application it looks like this:
Blazor uses Web Assembly which ships in all major browsers now. Web assembly is a binary instruction format that runs a virtual environment in the browser.
So what does that really mean?
Now the browser acts as a host for your application. Files built in a Blazor Web Assembly application are compiled and sent to the browser. The browser then runs your JavaScript, HTML and C# in an execution sandbox on the browser. It even runs a version of the .NET Runtime. This means you can execute calls to .NET from within the browser, and it's a fully-fledged application in the browser. It can even be run offline.
Why this is cool:
- You can run it on any static file server (Nginx, ISS, Apache, S3, Heroku, etc)
- It runs JS as bytecode, and runs C# at near-native speeds.
- You can use C# to develop rich front-end applications.
- Web Assembly ships with all major browsers
- Reuse .NET components
- Use Microsoft tooling and debugging
This is great for low latency applications such as games. There's no need for communicating with a server if you don't need to. You can download the application and run it offline in a browser. This is great for games and other things you need to run lightning fast in a browser.
Some downsides:
- The .NET Framework and other runtime files need to be downloaded (one time)
- You're restricted to the capabilities of the browser
- All secrets (credentials, API keys, etc) downloaded locally
- Not all .NET Framework components are compatible
So this may not be ideal for all applications. The good news is, there's another Blazor pattern we can use.
Option 2: Blazor Server
If you decide to build a Blazor Server application, it looks like this:
This is closer to the model we're using today. You build an application and have a server that's powered by .NET Core, and you send HTML and JavaScript to the browser to act as a client. This is a great way to make screaming fast thin clients.
Why this is cool:
- You get the full power of the .NET Framework
- Everything rests on the server, small downloads
- Web Assembly is not required
- Your secrets are safe
Some downsides:
- No offline applications
- Requires a server running .NET Core or a service
- Can be high latency with lots of network traffic
So how do I choose which one to use?
If you want powerful client-side applications that can run offline and served from a static server, choose Blazor Web Assembly. If you want the full power of .NET and want to run a model with thin clients, choose Blazor Server.
Why is this such a big deal?
Blazor patterns open up big opportunities for development. Whether you want to build a powerful service with several thin clients, or some cool interactive game that runs in a browser, Blazor enables rich, interactive application potential.
Web Assembly is the way of the future. It enables near-native speeds in a browser, and uses a common interface. You will find Web Assembly on PCs, Phones, and tablets. If you have a bunch of C# developers on your team who don't do front end programming, they are now empowered to do it in the language they love.
It's pretty awesome, and I'm excited to see how Blazor progresses.
Where can I learn it?
You can learn more about it from Microsoft's Blazor Site.
I recently wrote a tutorial about setting up and deploying Blazor apps without touching a Windows Machine
If you want to dig deep and learn Blazor, Pluralsight has some modern courses that will get you running quickly:
- Blazor - The Big Picture
- Blazor - Getting Started
- Blazor - Authentication and Authorization
- Creating Blazor Components
So try it out! Let me know what you think of Blazor and share your experiences in the comments!
Latest comments (61)
I have my doubts and I'll definitely be sitting on the sidelines for this one, but I think the big thing going for blazor would be the apparent 'difficulty' in reverse engineering the bytecode, which I can see many a decision maker wanting to protect their Intellectual Property in this fashion. Although this has an equal and opposite reaction, which would be the difficulty of debugging, but this is based on the traditionally way of debugging using the browsers' dev tools. Perhaps this will be a total moot point in the near future.
Regarding client side speed tests, and please forgive my ignorance on this matter, but does Web Assembly have access to the clients' multicore processors, if so this would be another plus as my understanding of JS, <ignorance> is although you can thread using 'workers', they are running on one core.</ignorance>
I am very happy about all the Blazor roadmap, in fact, I am very happy about all things Microsoft has done, and are doing ... Microsoft is different of the past long time ago ... But always there will be haters based in the past. Microsoft bring .NET Core, after that improved it bringing .NET Core 3 with Windows Form and WPF to help those with solutions made in old .NET bringing all together to move on. Microsoft made ML.NET for .NET Developers be at home, and now Blazor ... I am very happy about Blazor and now I can see it right here working ... And I will try it and I'll give support ... Other thing MS made great is new Edge based in chromium, I have used since the beginning and I've given support and it is my Default Browser,and I am liking very much, I use firefox Developer to code since CSS Grid, beacuse I don't like Bootstrap, in my viewpoint CSS Grid with a little flexbox in some one direction and Vanilla JavaScript I can create what I need with less code and less bloatware (but is my way of thinking), and Fiferox is my second preferred web browser and I don't like chrome, is just about do not like ... C# is my favorite language, is beautiful, C# 8 changed switch in a very good way ... I like to code JavaScript too if is worth it is my second language, I don't like jQuery or old versions ES5 ... I enjoy JavaScript ES6+, I like Node runtime and React Library ;) I think that Blazor will give me more flexibility, but I'm sure that somethings will be smart to build in JS and other in Blazor ... But one thing I am very sure, Microsoft is making a excelent work and it deserves to be recognized for this ... And this is good for everyone ...
I think the step after that would be streaming websites. Zero code runs on the client side, everything happens on the server. All the server sends back is a visual feed / pixels. Much like the cloud gaming service Google Stadia where the game is rendered at the server and send back to the user. This might be a bit too far fetched today, but I'm sure it will happen eventually.
Pros: It will resolve many issues like compatibility and performance. Also you no longer have to wait until the browsers add new feature supports, you can make them yourself. You can use ANY language your server supports. Doesn't even have to be HTML. Websites will no longer be constrained to traditional scroll-the-text-and-pictures. The possibilities are truly endless.
Cons: It will probably use up more bandwidth (or not) and users will no longer be able to block ads (this could be a pro for the site owners though).
I think only use of
Blazoris that we can create JavaScript like client side application without usingJavaScriptbut by just using C#. Is there any better use case to use Blazor?I love C# and am gonna try that out
Thanks for the articles on Blazor. I am curious how you would describe the Uno Platform as compared to Blazor? A comparison article would be helpful. Thanks again.
This sounds very similar to GWT (though, modernized to run using webassembly and using C# instead of Java). Am I wrong about that?
Several things killed GWT:
#1 might be made irrelevant if sourcemaps are supplied. #4 is probably irrelevant since MS seems lately to be a better steward of OSS.
#2 and #3 really are big issues with this kind of tech. Though, I'm interested to see where this goes.
I worked on several projects around 8 years ago using GWT and from my experiences the biggest drawback was the lack of the open source community support and boilerplate code to make it more manageable. Like adding a new place had big overhead. Wiring places, activity mapper adding view, we had to at least touch 10 Java classes just to add a new view.
I somehow couldn't agree with some of your points:
GWT application are not hard to debug, classic / super dev mode imho doesn't make much different to me. I prefer to use the super dev mode, debug directly using chrome devtool.
Depends how you make your application. We were using activity and places that was introduced in early 2013 or something was a big help. We followed Model View Presenter pattern and used UI binder. Basically each UI Component is isolated and doesn't have any business logic, it just call the presenter on user interaction (button pressed, value changed, etc).
We had it separated between the client and server code and any of our programmer could work on one UI part and never care about the presenter / activity part. Tbh I see the similarity with dumb and smart component pattern in angular / react.
We had hot reload without restarting server. We used standalone tomcat + GWT plugins in eclipse. Once we start the tomcat the gwt dev server started on itself. Launch setup is not much different than any other spring boot based project and dominating our software landscape atm.
GWT was dead because noone liked it, it was complex and hard to use, gwt 3rd party library was near to non existence. We also used RPC which only useful for that application. We couldn't leverage it. I wish we used rest backend already.
Sometimes you will need to use native javascript, so what you do, you write javascript code wrap it to your own java class using JSNI. I tbh dislike JSNI, it shows the limitation of GWT.
Good point about the lack of community around GWT. It was never properly supported by Google and once they lost interest in it, GWT was as good as dead.
I don't know... not really convinced here. All of this sounds awfully familiar to GWT - just for .NET. And we all know the fate GWT has met. It struggled with API compatibility ("Use full Java! ... except..."), the server restarts were a pain (just to see a minor UI change you had to restart the whole thing) and HTML integration was not nearly on the same level as it is in "native" JavaScript.
I would prefer C# over JavaScript any day so it would be nice to see this succeed at large, but I wouldn't bet on it.
So basically, from what I understand, it does the same thing ActiveX and Java Applets did back in the day?
And don't we already have Unity and various other WASM frameworks for browser games?
Basically the way I see it, this is the same thing .Net does with everything. Instead of devs learning a language they incorporate it poorly into the framework (see React.NET).
Not to be the one carrying the pitchfork but I don't really see a (near) future where we start packaging JS as binary.
There's also a host of other issues ranging from browser compatibility to security settings that disable wasm features and things like chink splitting which JS already does well enough. Though that last one I presume should exist as a loader mechanics.
Paraphrased arguments against Blazor...
"JS gives us everything" -- I think the JS ecosystem is a morass of command line tools. That you need 15 different things to make a web app is just horrible. I don't dislike JS as a language, but I like even more the ability to write front-end code AND back-end code in C#. No need to recreate the same class as C# version and then JS version, etc.
"Microsoft is bad/proprietary" -- I've been a Mac zealot from the 80s but am embracing .NET Core and Blazor wholeheartedly. They're both open-source and cross-platform friendly. I write Blazor at work on a Windows machine and then come home and write Blazor apps on my Mac.
"No work for Blazor devs" -- learn Blazor and you've also learned .NET Core, (probably) Entity Framework Core, Razor, C#, etc. Lots of call for those skills. It's not like learning Silverlight in that respect.
I'm working on rewriting an existing app for our organization as a "test" for where we go from here, and while we still have maybe 30 days before we ship (it's server-side Blazor, not WASM), I imagine the next project we start will be using Blazor, too.