Aspnetcore: Ready for Production Projects?

[kevinjpetersen]

Hello I found this awesome framework from watching the Microsoft Build Conference and I really like it. It's amazing!

Since this is still in experimental stage, I was wondering if there would be any negative impacts of making a production ready project built on Blazor? I have a website that I need to port from ColdFusion onto ASP.NET Core, and by using Blazor's framework it's gonna speed up porting time faster than ever!

Am I ok to do this, or should I wait until an actual "finished release" of Blazor?

Thanks :)

[D3MaxT]

Microsoft has not officially committed to making Blazor a product. As the results, there is no official support for it from Microsoft. Not to mention that everything is changing at a pretty quick pace.

In other words, I would say this is not recommended for production use (yet).

[kevinjpetersen]

@D3MaxT I see.. Do you think there is a time estimate of how quick a possible production release would be ready? I know things take time, but it looks like the interest and development of this framework is growing rapidly.

[scottsauber]

Damian Edwards from the ASP.NET team has said it won't be this year. That's the only timeline I've heard.

[danroth27]

Our general guidance is that Blazor is not ready yet for production. We are planning to integrate the blazor component model into ASP.NET Core as part of .NET Core, which is scheduled to ship ~mid 2019. Work on the Blazor WebAssembly client-side support will continue in parallel, but will remain experimental for the time being.

[kevinjpetersen]

@danroth27 Thanks for the excellent answer! In regards to the development, If I say were to start making a project but not finish it/release it until mid-next year, would Blazor get any breaking changes like changing all the syntax or is the current state of syntax like @functions, @bind, Components etc, all gonna be the same (more or less)?

[Andrzej-W]

@kevinjpetersen Depending on your project needs you have to take into account that there are some areas in Blazor which are incomplete or have critical bugs. You can start learning and experimenting but be prepared for some changes in the future. I have already started work on my new project and I hope I will finish it sometime next year. I strongly believe that Blazor will not be abandoned, but who knows?

I think that general Blazor features will not change to much: Razor syntax, @functions, @bind, etc.
You can expect a lot of changes in these areas:

• authentication and authorisation (not implemented at all, aspnet/AspNetCore#5472 aspnet/Blazor#698)
• routing (enhancements planed aspnet/AspNetCore#5489)
• event handling (a lot of missing features and bugs)
• internationalisation (#60, not implemented at all, bugs in mono with local time, only UTC supported)
• JSON (current JSON serializer/deserializer is not as powerful as Json.NET and it will be replaced)
• component enhancements (#1, aspnet/AspNetCore#5463, aspnet/Blazor#404)
• form and validation (#17)
• hard to predict changes related to server side rendering (#24 something similar to Angular Universal)

You should read all open Blazor issues and decide yourself. Also read closed issues to know how to overcome some current problems.

[danroth27]

@kevinjpetersen it's still too early for us to commit that there won't be breaking changes even in core functionality. We need the flexibility to be able to address key design issues and user feedback to make sure that we eventual ship the best framework possible. Also, as @andrzej-w rightly pointed out there are plenty of critical bugs and functionality gaps to address. My best guess is that things will start to stabilize early next year.

[kevinjpetersen]

I see! Thanks @Andrzej-W and @danroth27 for the fast response and comments on this matter! I'll definitely keep an eye on this as it evolves! :)

[Arshia001]

Blazor's internals and functionality aside, the ability to create client-side web apps with .net lets people get creative with lots of stuff. Can we at least be sure that a web framework based on client-side .net will eventually be released? In other words, can we be sure Blazor won't get completely abandoned somewhere along the way?

[danroth27]

Can we at least be sure that a web framework based on client-side .NET will eventually be released? In other words, can we be sure Blazor won't get completely abandoned somewhere along the way?

Blazor as a client-side WebAssembly based framework is still experimental, and as such it is not a committed product. While we are optimistic about Blazor's future, we can give no guarantee at this point as to if or when it will ship. This is one of the reasons we don't recommend putting Blazor into production at this time.

We are proceeding with integrating the Blazor component model into ASP.NET Core as part of .NET Core 3.0. This allows us to productize a good portion of Blazor programming model, while we work out the issues with running .NET on WebAssembly. The intent is that the same programming model will be supported both server-side and client-side.

[acrigney]

Any updates now guys?

[Suchiman]

@acrigney Server Side Blazor ships in .NET Core 3 in September and Client Side Blazor wants to ship early next year (no promises)

[acrigney]

Awesome! so I can starting switching my DDD architecture over to Blazor now then.

[Joebeazelman]

From the little bit I've gleaned on Blazor, I'm afraid Microsoft is making some very poor design decisions here. They appear to be adding supporting technologies to the ASP.NET stack that makes little sense and appears redundant. Instead of using the tried and true ASP.NET MVC architecture, it created a page/component model borrowed from other JavaScript frameworks. This application model doesn't offer any clear advantages, since .NET already has a superior infrastructure already in place. Many of the features mentioned by @Andrzej-W already exist and are working. It appears to be a common theme where different Microsoft teams are duplicating each other's efforts. It's probably due to the organization's management style where teams compete against each other.

[Pilchie]

Just a quick note - the same team is responsible for both Blazor and MVC. There is no competition, but different people want to build things in different ways, and we welcome them all.

[danroth27]

@Joebeazelman Blazor is a client-side web UI framework, similar to Angular/React/Vue/etc, but where you write C# instead of JS. MVC is a request-reply based server-rendered web framework. Blazor is actually not a replacement for MVC. In fact, you frequently use Blazor and MVC together. For example, prerendering in Blazor is handled using MVC under the covers. You can also use Blazor to render interactive client-side components on your MVC views. Blazor has a different app model than MVC because the client is inherently stateful. Blazor is intended to complete the picture for a .NET web developer. With only MVC, you had no way to leverage the client other than to write JS. With Blazor, you can now full leverage the client and server. It's full-stack web development with .NET! That's the advantage that we are trying to offer.

[Joebeazelman]

@danroth27 I'm concerned about productivity based on what developers already know. If we have to learn something new, it should offer clear benefits such as performance and productivity improvements, code quality, etc. As an example, .NETCore's WCF, is a senseless rewrite that is inferior to the one in .NET Framework. Reinventing the wheel, as Microsoft has done with UWP, Windows 8 and others failed initiatives, has been costly to invested developers and the adoption of the .NET platform.

Blazor seems to be using the same telemetry of doom. Why reinvent Form Validation and Authentication when it already exists in ASP.NET, .NET Forms, UWP and WPF. Aren't there already a ton of JSON serialization and deserialization libraries in existence? Also, why are you hung up on events? It's already working on every other .NET Framework application model, including WPF, UWP and WinForms. How are these in-production implementations insufficient for the task?

If you think really hard, you'll realize that Microsoft had already released Blazor many years ago. It was named...drum roll...SilverLight! It was a stateful, cross-platform client that ran in the browser and was quite impressive. While it didn't directly manipulate the DOM, it featured its own XAML markup, which could have liberated us from the HTML/JS nightmare we live with today. If you think about it, over half of the work is already done for you! There's a treasure trove of code you can use. Best of all, there's no royalties, unless the accounting department want to be clever.

[danroth27]

@Joebeazelman I certainly agree that reinventing existing technologies with no clear benefit wastes everyone's time, both Microsoft's and the developer's we seek to enable. I also agree that Microsoft hasn't always got this right in the past. But with Blazor we are enabling a completely new scenario: client-side web development with .NET (yes, Silverlight also addressed this scenario, but it did so in a proprietary way that didn't use open web standards and is now incompatible with the modern web). Because Blazor is addressing a new scenario, some new concepts are expected.

At the same time we also want Blazor to leverage what existing developers already know. With Blazor we are specifically targeting web developers, and this leads us to decisions that you may or may not be happy with depending on whether that matches your background. For example, we are using HTML & CSS with Razor syntax instead of XAML because those are what web developers are generally more familiar with. We also want Blazor to not only appeal to existing .NET developers, but also to web developers coming to .NET for the first time. That's why if you squint at Blazor you may notice it looks like some existing JavaScript frameworks, especially React.

I'm not saying we've got everything right in Blazor. There are almost certainly things in Blazor that could be better handled using an alternative approach or technology. We appreciate the feedback on these areas! Regarding the specific areas you mentioned:

• We did introduce a new Forms & Validation model for Blazor that tries to leverage Blazor's client-side nature. If you have feedback on the model or ideas on how to improve it file an issue and let us know!
• Blazor doesn't handle authentication. It integrates with the existing authentication features in ASP.NET Core.
• Blazor didn't introduce a new JSON serializer, but .NET Core did, and Blazor uses it. For the reasoning why .NET Core introduced a new JSON serializer see https://devblogs.microsoft.com/dotnet/try-the-new-system-text-json-apis/.
• We use events in Blazor because that's a common pattern in stateful client-side frameworks. You can, however, still integrate Blazor with a variety of app state management approaches including MVVM.

We also understand that there are a bunch of developers that would also like a Blazor-like model that is closer to the various XAML stacks. This is a completely reasonable request. It's just not in scope for what our team is trying to build. There are, however, other efforts in the community looking at bringing WPF/UWP/Xamarin/Silverlight programming models to the web (many via the same .NET WebAssembly support that Blazor uses) that are worth looking at and even contributing to if you're interested: Uno, Ooui, FrogUI, CSHTML5.

Lastly, I hope you will give Blazor a try! If you end up liking it, great! If not, we hope you will continue to share with us your feedback on how we can make it better.