Getting Started with Blazor: All There is to Know From the Experts

At Telerik we’ve been impressed with Blazor ever since it was first announced. This is what led us to create Telerik UI for Blazor soon after the announcement. The big promise of using C# everywhere is what got us hooked and we haven’t regretted the choice one second. With all the new enhancements Blazor has received lately, we thought it might be interesting to sit down and chat with some of the most active members of the Blazor community about where it stands today and what the future holds for the technology. We hope you enjoy reading what Daniel Roth, Chris Sainty, Egil Hansen and our very own Ed Charbeneau had to say. 

We want to thank the experts in our panel for both being the leaders in the still growing Blazor community and for taking the time to talk about it (although they clearly enjoy it so they ought to thank us too). Read the entire panel or jump to the sections you are interested in, they are all worth a read.

Introducing the Experts

We've gathered some important folks from the community from different backgrounds and perspectives in technology.

With us today are:

Daniel Roth

Daniel is a Program Manager at Microsoft and is working on the ASP.NET team. Blazor is one of the projects that Daniel is responsible for and works directly with the Blazor team.

Chris Sainty

Chris is a Software Engineer and Microsoft MVP. Chris has extensive coverage of Blazor on his personal blog dating back to the early experimental days of Blazor.

Ed Charbeneau

Ed is a Sr. Developer Advocate at Progress. Ed is currently focused on Telerik UI for Blazor, a library of user interface components built for the Blazor framework. Ed is also our moderator today.

Egil Hansen

Egil is a Managing Architect at Netcompany working with C# and web technologies. Egil is currently building component libraries for Blazor like his Blazor Component Testing Library.

Blazor WebAssembly (WASM) vs. Blazor Server

Our first topic will be Blazor WebAssembly vs. Blazor Server. Which technology interests you the most and why?

Daniel, would you mind giving us the elevator pitch of Blazor WebAssembly vs. Blazor Server?

Ed Charbeneau 

Daniel Roth

Blazor is a framework for doing client-side web UI development with .NET and C# instead of JS. Blazor is open-source and based purely on open web standards (no custom plugins or code transpilation). We currently have two different approaches (hosting models) for accomplishing this:

Blazor Server sets up a real-time connection with the browser and handles all UI interactions on the server. Blazor Server support shipped with .NET Core 3.0 and is available for production use today. With Blazor Server apps, all your code stays on the server, so the client is very thin. The download size is small and the app loads fast. Your Blazor UI code runs on .NET Core and has access to all the server resources (you can connect directly to a database, make arbitrary outbound requests, etc.). However, with Blazor Server apps you do need to worry about network latency and dealing with server scale out if you expect to have a lot of concurrent connected users.

Blazor WebAssembly runs your client-side code in the browser using a WebAssembly based .NET runtime that is downloaded with the app. Blazor WebAssembly apps are analogous to existing frontend JS based apps: you can deploy a Blazor WebAssembly app as a static site, support offline scenarios, build PWAs, and offload client concerns to the user's device. Blazor WebAssembly works in all modern browsers that support WebAssembly (basically all browsers except IE). Blazor WebAssembly is still in preview, but is expected to ship in May of next year.

Whether you use Blazor Server or Blazor WebAssembly, the component model is the same. This means you can use the same components with either hosting model, and you can switch between them with very little work. We also expect to introduce additional hosting models in the future for building hybrid and native apps.

So I'll say that I was a bit cautious about Blazor Server when I first heard about it. I felt like it was going to be WebForms and ViewState all over again. This was my early impression before I actually understood how it really worked. Using it has completely changed my perspective on it.

Ed Charbeneau
Chris Sainty

Personally, I'm really interested in Blazor WebAssembly - it's where this whole Blazor dream began after all! Much like you Ed, I was sceptical of Blazor Server at the start. But I have to say I really enjoy building Blazor apps using either hosting model now.

Egil Hansen

I actually have more experience with building WebForms webapps back in the days than building asp.net mvc apps, so the Blazor Server model was instantly familiar to me. I work as a consultant, and using it for quick LOB apps, much like WebForms, seems like a very good fit. No big issues with slow network or massive scale.

Daniel Roth

Yeah, if you're used to doing .NET web development on the server, there's a lot that feels familiar and natural with Blazor Server, while still enabling you to build rich interactive user interfaces that are typical of JS based single-page apps.

Don't get me wrong, I love the idea of Blazor WebAssembly too. Having choice is awesome, however I think there's an opportunity for some "big wins" with Blazor Server. I feel like Blazor Server apps can have a much shorter development cycle because you can choose to flatten your n-tier architecture into a single project that utilizes a database with a Web API.

Ed Charbeneau
Egil Hansen

However, Blazor WebAssembly is very appealing, and the joint component model is really cool. I have a bunch of apps I can imagine building using that. So I definingly see myself using WebAssembly much more in the future.

It might sound like an anti-pattern, but not every app is "File > New Netflix".

Ed Charbeneau 
Daniel Roth

We're finding there's a bunch of customers that are specifically interested in Blazor Server for embedded device and IoT scenarios, particularly because the client is so thin.

Chris Sainty

Speed of development with Blazor Server is - excuse the pun - Blazingly fast. 

Daniel, you mean those old Chromebooks ;)

Chris Sainty

One other great benefit from Blazor Server is that the code stays safely on the server. That has a lot of value for people who need to keep their code protected.

Excellent point Chris! I've heard a lot of concerns over security with Blazor.

Ed Charbeneau

There are aspects of Blazor Server development though that you need to be aware of. It is a connected client model where all the state is by default in memory on the server. If the server gets restarted then the clients get disconnected and the UI state is lost. You need to plan for this situation and think about how you want to reconnect clients and reestablish their state. We have some guidance in the Blazor docs to help you figure out how to do this.

I find security an interesting concern considering JavaScript code ships over in plain text already.

Ed Charbeneau
Chris Sainty

I would just advise developers to make sure they're not putting business logic in their Blazor components

Daniel Roth

Network latency is another concern with Blazor Server, but not as much as you might think. The payloads Blazor Server sends on the wire are really small (bytes). You do need to plan for your servers to be reasonably geolocated near your clients (don't connect a client from the US to Australia), but from our experiments connecting within the same continent/country works fine.

Egil Hansen

One issue I would like to raise about Blazor Server is those with timing and animation. Things get problematic when you want to drive an animation, that involved changing the rendered HTML a number of times, at specific steps, e.g. after 100ms, then again after 200ms, and so on. The speed of the network connection to the client, the browser version and speed of its JavaScript/WebAssembly runtime can make a smooth-running animation on a dev machine look silly on the users. In those cases, I find the promise of a non-JavaScript development experience will not hold up. In those cases, we really need to let JavaScript drive stuff to get a stable experience.

Daniel Roth

That's a great point - scenarios that require really low latency (drawing apps, real time games, etc.) will not work well with Blazor Server.

Chris Sainty

Definitely scenarios better suited for Blazor WebAssembly

Egil Hansen

Yeah, and you will most likely still need to turn to a little JavaScript and CSS to make everything stable.

I've experienced this myself and so has the engineering team at Telerik. There is definitely some opportunity for using the JavaScript interop to solve problems in regard to animation. Our solution is a reusable component that abstracts a set of JS events. I don't want to get off into the weeds of the technical details, but there are for sure times where JS is still valuable.

Ed Charbeneau 
Egil Hansen

But a lot of that can also be handled at a library level, so if devs pick a Blazor-based UI framework, they are more likely to stay free of JavaScript, which I know is something quite a few see as a great bonus.

Getting Started with Blazor

Let's shift the topic to "Getting Started with Blazor." What was the experience like for you?

Ed Charbeneau 
Daniel Roth

Nirvana!

Daniel's is probably something like, "Steve Sanderson walked in my office."

Ed Charbeneau 
Daniel Roth

I remember when I first got to play around with Steve's early Blazor prototypes. It was like I could finally be productive writing front-end web apps.

The first time I saw Blazor was at the Microsoft MVP summit. I think I was on the phone with engineering the next day discussing how we should build a proof of concept.

Ed Charbeneau 
Chris Sainty

I downloaded the Blazor source code before the 0.1.0 experimental preview came out. I can't go back as far as Dan but it was pretty early days.

Daniel Roth

For folks looking to get started with Blazor there are a bunch of great resources out there. To get setup, head to https://blazor.net. You can install the bits and build your first app in less than 5min. The Blazor docs are a great resource. There's also a full self-service Blazor workshop (https://aka.ms/blazorworkshop) that you can work through to learn all the ins and outs of Blazor.

I absolutely love the BlazingPizza workshop you mentioned Daniel.

It takes about one-two days to walk through in detail, but it's going to give you a massive head start on learning what you need to know about the framework.

I would also mention the webinar we did with Telerik about adopting Blazor and migrating from older tech.

Ed Charbeneau 
Chris Sainty

I set my team at work an exercise with Blazor before any of them had started looking at it. They all got up and running and produced a working app meeting the brief in about an hour. Now it wasn't anything fancy, but I think it says a lot about how easy Blazor can be to pick up - especially if you're coming from a ASP.NET background.

Daniel Roth

The community has also really stepped up to provide lots of great Blazor content to help you solve pretty much any scenario with Blazor. Books, blog posts, videos, samples, etc. A good resource for community content is the Awesome Blazor repo which collects links from all things Blazor on the internet.

Chris Sainty

I would second the Awesome Blazor repo, it's a fantastic resource and it's always being updated.

I like that I can get started with a simple File > New Project in Visual Studio, or a quick .NET new from the CLI. Best of all, there's no npm or Webpack because it's all .NET technologies, so instead you have NuGet and MSBuild. Essentially you just click run and it just works.

Ed Charbeneau 
Daniel Roth

We're working on support for Blazor in Visual Studio Code and Visual Studio for Mac as well. The Blazor tooling for Visual Studio Code is already in preview with the C# extension. The Blazor support for Visual Studio for Mac should be available later this year with the 8.4 release.

Egil Hansen

My first impression was "That is some year 2000-ish gradient coloring in the menu of the hello world app..."

No seriously, after watching Steve’s presentation in January this year I was very impressed with the possibilities, so I instantly started playing with it. I haven't actually built a big app with Blazor yet, my project has been to see how easy I could make working with Bootstrap in Blazor could be. It is crazy easy to build basic components, and when you dig a little deeper, you still get very far without much effort. My biggest challenges have been those that deal with JavaScript interop, deciding when to do JavaScript and when to do C# for the more advanced Bootstrap components (e.g. Carousel).

Egil Hansen

I am also a big TDD proponent, I really like that feedback loop and the satisfaction of seeing red tests go green, so that was one of the first things I started experimenting with in conjunction with my Bootstrap library.

Daniel Roth

We are testing the VS4Mac builds with Blazor tooling support right now. This is a new hyper agile Microsoft!

Chris Sainty

The tooling is just such a great positive for Blazor, especially when comparing to the JavaScript world. We've always been really lucky in the .NET community to have some of the best tooling.

Yes, to Egil's point, we're already seeing things like his test framework. There's Interop libraries, state management utilities, and all sorts of fantastic ideas springing up. And a ton of great UI component libraries like the one we ship at Telerik.

Ed Charbeneau 
Daniel Roth

OK - hot topic related to Blazor tooling: code-behind or no code-behind?

Chris Sainty

It’s like the tabs vs spaces of Blazor!


I personally mix. I use code blocks when the components are pretty simple. I then move to a code behind approach when components start get bigger.

Well, now that you mention it. I just tried the new (as of 3.1 Preview 1) method of introducing code-behinds. I really like the partial class approach, it's much cleaner than the inheritance model most people will be familiar with until recently.

Ed Charbeneau 
Daniel Roth

So we went with having the code in the same file based in part on trends we saw in the Vue community. The argument there is that the code in your @code block should just be UI code that's going to get compiled into the same class, so it made sense to just have it all in one file.

The argument that is typically made is separation of concerns. But, as Chris mentioned, as long as you're not putting business logic in your components then having UI code in the same file is seems perfectly fine.

It's not as cut & dry as how it gets compiled, you have to think about the Developer Experience as well. There's better tooling in .cs where you get ctrl + . completion for example.

Ed Charbeneau 
Egil Hansen

I generally like that model, but for the bigger components I have been building, where I needed tight control over the rendered HTML, a lot of @if, etc., in the code started to look messy. Then it was easier with different methods (RenderFragment) with good names that explained what they render.

Daniel Roth

We also understand there's a lot of history around having code-behind files in the .NET ecosystem, so we will support both models, including tooling gestures to easily add a code behind file, which is pretty nice with the partial class support coming in 3.1.

Chris Sainty

I think ctrl + . completion in .razor files is a must from a productivity standpoint.

Daniel Roth

The C# tooling limitations in Razor are a good point. We are working to improve the Razor tooling, so you get all the C# goodness.

When can we expect the release date for this :)

No pressure.

Ed Charbeneau 
Daniel Roth

.NET Core 3.1 is wrapping up now and will ship in Nov/Dec of this year.

Egil Hansen

Change something in a file, compile and refresh browser to see change.

Chris Sainty

Hot reloading - that would be great.

Egil Hansen

Not sure how that works right now in Blazor WebAssembly, but last I checked, it was actually quite slow, since it takes a while to do the first render in that.

Daniel Roth

We do have auto rebuild support for Blazor apps, where we rebuild and restart the app as changes are made to speed up the development workflow, but hot reloading would be much better. Support for hot reload is actually a broad theme across all the .NET UI stacks for .NET 5.

My advice for Blazor WebAssembly developers is to run without debugging. If you're using Ctrl + F5 you'll get a much better experience. Browser based debugging is still in its early stages anyway, you're not losing much with debugging disabled, but the performance increase is noticeable.

Ed Charbeneau
Egil Hansen

It isn't as big a deal when doing TDD though. Here my loop is 1. write a failing test, 2. make it pass, 3. refactor, (optional) 4. double check in the browser :)

But JavaScript and CSS stuff still needs to go the browser though.

Looking to start a project with Blazor? We've compiled a list of getting started resources to guide you when getting started with Blazor, in addition to the tips our guests share below.

Favorite Blazor Feature

It's time to change topics again and this is a tough one for me.

If you could choose just one thing, what would your favorite Blazor feature be?

Ed Charbeneau
Daniel Roth

C# (although I hear that F# is also really nice).

Egil Hansen

C# all the way to HTML.

So Egil and Daniel are basically saying "everything".

Ed Charbeneau
Chris Sainty

This might sound odd, but for me it's the fact that Blazor isn't opinionated about how apps are built.

It lets developers build things how they want, I think that's awesome.

I think that's something that may be overlooked at first. I feel that this allows more flexibility than prescriptive approaches do. This way you can still have community-based opinions that form around the base framework.

Ed Charbeneau
Chris Sainty

Yes, there are a lot of assumptions out there. I think that flexibility is a major plus to Blazor and as Ed said, it's often overlooked.

Daniel Roth

It's a conscious choice to leave Blazor unopinionated. By doing so, we're hoping that it gives the community room to innovate. So far, it seems to be working out well - the Blazor community is awesome!

Having a full-stack .NET solution is also nice. You can share code and reuse logic. Because it's .NET on both sides of the wire, scenarios like pre-rendering your app on the server are straight forward. You can even mix Blazor components into your existing MVC views and razor pages.

It really is hard to pinpoint a single feature, but I think the component model really sells it for me. I really like the simplicity of it all. When you begin to build larger UI's you really appreciate it since you can allow for child components and templates with absolute ease. You can essentially stick components inside of templates and change them completely.

I've done quite a few live demos where people ask if a component has X as a feature. At first the answer is "no" but then I quickly backpedal and think "but if we utilize a template region, we can add it". I've literally created new modes of operation for the Telerik Grid in live demonstrations in less than a few minutes. 

Ed Charbeneau
Chris Sainty
I'm a big fan of the component model as well. Components are a great way to build and reuse UI.
Egil Hansen

In my work, I often work with developer teams that must deliver a lot of business value very fast. The component model makes it very easy for us to build a central repository of components that abstract away all the tedious rules around e.g. Bootstrap and aria attributes. That enables the developers to quickly add business value.

Chris Sainty
Well there's another great feature of Blazor - productivity!

I think I'll refrain from asking what your least favorite feature is, there was quite a bit of bloodshed earlier about hot reloading, but Daniel already mentioned it's being looked into.

Ed Charbeneau
Egil Hansen

Well Ed, I would have suggested built-in support for isolating JavaScript and CSS to a component, like Web Components have.

But we can take that another time!

So this is an interesting topic, one that I can never manage to grasp the other side of the equation.

Ed Charbeneau
Egil Hansen

OK, so it would be great, if Blazor would be able to seamlessly handle loading a snippet of CSS and JavaScript related to a component, when it is first rendered. The WebComponents has something like that (don’t know all the details).

That would make it much easier to interop with CSS and JavaScript, not having to include files in a .cshtml or similar, and not have to worry whether it is loaded or not.

Daniel Roth

There's quite a few folks who'd like to see CSS isolation for Blazor. Again, our position is that we would prefer to remain unopinionated and let the community come up with solutions that they like. I believe https://blazorstyled.io/ is one community-based option. But there may also be valuable to the Blazor ecosystem in having a common solution. We're listening the to the feedback and thinking about how to proceed on the issue.

I typically use a Sass based approach, where my component CSS is neatly built into manageable modules in a Scss folder. While Scss helps fill gaps where CSS lacks features, I'm always weary when it goes full tilt and people start wanting to write the CSS in something like JS or C#. 

Ed Charbeneau
Egil Hansen

I get that. But I also think that is one of the bigger pain points for newcomers. How and when to load related resources.

I have a long-tired story about my early experiences with Angular and Webpack where those systems want to treat everything in the stack as JavaScript. To make a long story short, I spent 4 hours trying to solve a runtime error that came from a CSS file being introduced to the project.

At no point in time should CSS ever cause "RUNTIME" error. It still baffles me to this day why people want to work in such an environment. Worst case for CSS failure should be the page looking like it's still 1999.

No offence 1999, you were a good year!

Ed Charbeneau

I see things very similar to you Ed. I think keeping Blazor unopinionated and letting the community fill in the gaps, could be the best option. At least for now.

Migrating to Blazor 

There's a lot of buzz in the community about migrating to Blazor from Silverlight, WPF, MVC, AJAX and even Angular/jQuery. When we did the Adopting Blazor webinar, this was one of the most requested topics. What is that story like from your perspectives, do you have any advice? Is there a technology that is easier to transition from? 

I've had quite a bit of questions revolving around Silverlight specifically. However, I'm not that knowledgeable of Silverlight, so I'm not much help on the topic. It's worth pointing out that there's a lot of interest from that group of developers. 

Ed Charbeneau

I never got into the whole Silverlight buzz. I don't really get on with XAML if I'm honest. But I can see why that group of developers would be interested in Blazor.

It does always end up in the discussion of when Blazor will swap HTML for XAML though.

I think it's first important to recognize that Blazor is specifically for client-side UI. If you have an existing MVC or Razor Pages app, there is no need to rewrite everything in Blazor. Instead you can add Blazor to your app to handle your interactive client UI needs instead of having to write JavaScript.

I can only speak to moving from jQuery and JavaScript, and that has generally been very straight forward. My advice is to be aware of the network latency/round trip in Blazor Server scenarios especially, learn the component models life cycle, and don’t try to go 100% C# only, if you have well organized JavaScript code already. There are still things that are easier in JavaScript, so knowing when to stop fighting with Blazor to make things behave and just use JavaScript is a good idea (see earlier comment on animations).

I also think Blazor has a lot to like if you're coming from an ASP.NET Web Forms background. Like Web Forms, Blazor is an event driven component-based UI framework. At the same time, Blazor is also a modern open source framework based on .NET Core and modern web standards. So, if you're looking for a path to modernize from Web Forms, Blazor is a great option!

We've been working on a free open source book on Blazor for Web Forms developers. It's currently partially complete, but you can find the existing content on the .NET architecture site.

Awesome, Dan!

It's not so much about migration though, as it is about learning Blazor in a familiar and natural way for Web Forms devs.

Regarding Silverlight, one question I get a lot is whether Blazor is here to stay or is it another Silverlight. Blazor is similar to Silverlight in that both let you build front-end web apps using .NET, but it diffs in several important ways:

Blazor is based purely on open web standards – no browser plugin required

Blazor is for web developers, so it is based on HTML, CSS, and C#, not XAML

Blazor is open source and community based from the start – the community is enabled to carry Blazor forward

That said, we have big plans for Blazor!

Tweet Me

Looking forward to hearing this. The future of Blazor can greatly decide app migration paths.

Ed Charbeneau

In additional to Blazor WebAssembly and Blazor Server we also working on enabling a broad spectrum of apps with Blazor that cover everything from the web to native apps.

We plan to add support for building Progressive Web Apps (PWAs) with Blazor so that you can get more of that native app feel: offline support, pin to home screen or start menu, native OS integration, etc.

We have been working on Blazor Hybrid app support for a while with Electron. With Blazor and Electron you can build native cross-platform desktop apps that use web technologies for the UI.

And then we have also started to investigate building fully native apps with Blazor, where the app runs natively and also leverages native UI controls. This is accomplished by replacing Blazor's default HTML renderer with a custom one that can render native controls, very similar to how Xamarin Forms and Reactive Native function today. Blazor Native!

Tweet Me

MIND BLOWN

Ed Charbeneau

I'm really interested in Blazor Native!

For Blazor PWAs and Blazor Hybrid with Electron we expect to have previews for folks to try out next year. No roadmap yet on Blazor Native yet, but we are actively investigating different approaches.

I think this is going to make a lot of folks happy. There was an initial feeling that Blazor wasn't going to stay, it was this cool experiment that was too good to be true. But seeing a future roadmap like this develop means we have a bright future with Blazor!

I think we covered some great topics. I want to thank our panel guests for joining today for our chat. As Blazor is still very much under fast iterative development, make sure to follow the Blazor roadmap. Similarly, to make use of the only production-ready, native Blazor UI components, follow the Telerik UI for Blazor roadmap.

Thanks for putting this together, Ed! It was great chatting with you all. Feel free to ping me over email if you want to chat about any more of this stuff. Bye!

Great, thank you Ed for the invite. Fun discussion. Let’s do it again another time.

Thanks, Ed! It was a great discussion!
It's clear that Ed, Dan, Chris and Egil enjoy talking about Blazor and that's why they were the perfect guests to join this panel. We hope you enjoyed reading it and found the answers to your questions. Check out our Telerik UI for Blazor page, if you want to learn more about Blazor & how to experience shorter development cycles & quick iterations for your app development.


This piece was included as a gift to the community as part of C# Advent. To see other "gifts" click here.



Author

stella-ivanova 

Stella Ivanova

Stella is a part of the Product Marketing team at Progress. Her focus is the ASP.NET UI suite, and especially Telerik UI for Blazor. Stella has a passion for technology, a vision for product, and a story to tell. When she is not thinking of clever marketing campaigns, you will likely find her planning yet another trip around the world. You can follow Stella on Twitter @SMIvanova21.