We've gathered some important folks from the community from different backgrounds and perspectives in technology.
With us today are:
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 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 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 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.
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?
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.
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.
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.
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.
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".
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.
Speed of development with Blazor Server is - excuse the pun - Blazingly fast.
Daniel, you mean those old Chromebooks ;)
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.
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 would just advise developers to make sure they're not putting business logic in their Blazor components
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.
That's a great point - scenarios that require really low latency (drawing apps, real time games, etc.) will not work well with Blazor Server.
Definitely scenarios better suited for Blazor WebAssembly
Let's shift the topic to "Getting Started with Blazor." What was the experience like for you?
Daniel's is probably something like, "Steve Sanderson walked in my office."
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.
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.
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.
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.
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.
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.
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.
My first impression was "That is some year 2000-ish gradient coloring in the menu of the hello world app..."
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.
We are testing the VS4Mac builds with Blazor tooling support right now. This is a new hyper agile Microsoft!
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.
OK - hot topic related to Blazor tooling: code-behind or no code-behind?
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.
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.
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.
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.
I think ctrl + . completion in .razor files is a must from a productivity standpoint.
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 :)
.NET Core 3.1 is wrapping up now and will ship in Nov/Dec of this year.
Change something in a file, compile and refresh browser to see change.
Hot reloading - that would be great.
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.
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.
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 :)
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.
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?
C# (although I hear that F# is also really nice).
C# all the way to HTML.
So Egil and Daniel are basically saying "everything".
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.
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.
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.
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.
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.
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.
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#.
I get that. But I also think that is one of the bigger pain points for newcomers. How and when to load related resources.
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!
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.
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.
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 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.
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.
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!
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.
This piece was included as a gift to the community as part of C# Advent. To see other "gifts" click here.