Unified Blazor hosting model for building full stack, multiplatform, fast and interactive apps.

[ansarizafar]

C# developers were very excited when Blazor was first announced but after years of waiting, It seems that now developers are frustrated and disappointed with the current state of Blazor https://github.com/dotnet/aspnetcore/issues/5466#issuecomment-640224557

Even in 2020 software development is very hard. In my opinion, Microsoft failed to understand the pain points and requirements of software developers and lost them in last decade. With .Net 5, C#9 and Blazor, We have a great opportunity to understand and solve these issues to win developers back.

What developers want?

A simple, unified full stack platform/framework for building beautiful, fast and interactive cross platform apps with single codebase.

No mash-up of complex, overengineered technologies (Rest API, GRPC, GraphQl, MVC, Razor pages, Blazor server, Blazor Webassembly, xamarin, xamarin forms, MAUI etc).

What is the Problem with Blazor?

Blazor has two hosting models and both have serious issues.

Blazor server store state and render everything on server, requires more system resources and latency is unacceptable in most cases specially If app is hosted in a different country and on slow internet connections.

Blazor Webassembly has a large initial payload and runtime performance is not so good etc.

Blazor currently follow ReactJs approach of virtual dom and state management. It would be much better If Blazor can use SvelteJs https://svelte.dev/ approach of no virtual dom and compile time reactivity and state management.

Considering the developers requirements, pain points and features offered by other competing technologies, We need to think out of box to find a better solution .

Proposed Solution

I propose a unified Blazor model for building full stack, multiplatform, fast and interactive apps.

In this unified model, Blazor page will have two parts @server and @view.

@server and @view both can have private state and private/public methods. Public methods can be invoked/called from client or server. Server will not store view state and view rendering should be done on client. Web apps can have optional prerendering on server for initial page load.

View should be complied to multiple targets

• Web apps (Javascript, Webassembly) Default target for web apps = Javascript
• Android
• IOS
• Desktop (Mac, Windows, Linux)

This will also enable us to develop features like hot reload and code push.

Blazor Page

@page "/"
@using namespace on server
@using another_namespace on client
@inject service on server
@inject anotherservice on client

@server {

    private User loggedInUser;

    //Public method can invocked from client/view     
    public Task<User> GetUser() {
         return loggedInUser;
     }
   //Public method can invocked from client/view    
     public Task<Product> GetProduct(string Id) {
         //Get product from database
     }

}

@view {

    private bool collapseNavMenu = true;

    //Public method can be called from server
    public void alert(message) {

    }
    private void render() {
       // C# markup
       return new VStack([
                         new Text("Hello World").Color(Colors.Red)    
                         ]).Margin(10);
                 }
}

Note: These are initial ideas and further brain storming is required.

[corylulu]

I would love to see something a bit more streamlined than SignalRClr (Example of using SignalR and Blazor WebAssembly together), but it's gonna be hard to mix server and client memory as if they aren't separate when they actually are.

The issue I'd see when you start using this code inside your template. Some of your template would need to be built server side, other parts would be built client side depending on which code is used...

I suppose you could do a check for if a variable from @server is being used, render it server side, otherwise render it on @view, but if you mix that code, you'll have problems... If the template has @server properties that are dependant on @view properties or the other way around, they would have to make calls back and forth from the client and the server to determine how to build said template. And if that happens in a nested fashion or in a loop, it could be a big invisible performance tax.

This seems not very possible to do automatically and have it still feel like C#... @server would need to be comprised of purely serializable properties and functions would need to be restricted so that they can't be laced in with the @view code when building the template...

[ansarizafar]

@server and @view state is local/private. @server state will not be available in @view and @sever will not be able to access @view state directly. Only public methods are callable from @server or @view.

[JohnGalt1717]

Personally I think that Blazor Bindings for Flutter's rendering engine should be resurrected so that we're not reinventing the wheel and all of the work that Google has put in that has massive adoption. If Windows support was prioritized for the rendering engine and Blazor could just work against flutter automatically and used web assembly code which would make web faster too and all of the Xamarin tooling was brought for ios/android development including writing plugins without having to use Swift/Kotlin and done all in C# and Microsoft committed to free simulators in the cloud and publishing for ios to the store support so we didn't need a mac, they could finally get devs back to Windows because they wouldn't need the mac, and Windows would become a first class citizen.

This would BY FAR, be the best use of resources for ALL of Windows end user development and have the shortest path to production, the greatest success and ensure Windows applications for everyone writing Flutter be it Blazor or dart.

And since the flutter engine works great on web, you'd have a single set of bindings that would work everywhere without requiring Chromium etc. wrappers. You'd get native-like speed with way less overhead.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!