Microsoft and the Web

[guardrex]

Moved from https://github.com/aspnet/Docs/issues/10977

Original post by @brice-prunier-dev ...

Microsoft has been a major player in the world of development for a long time now.

However if It has a pioneer in language with .NET & Typescript and desktop App it has surprisingly be inconsistent on WebClient development.

First it started by being innovative with ASPNET Forms (I’m talking of 1.0 at a time where CGI was the rule).

After it ran after Java to offer a real MVC development model.

Once again it tries to break the rule with Silverlight (we all know of it finished ) after what it was completely absent at a time where Javascript was rising up.

With Typescript an Angular initiative we though MS will offer an homemade framework ( I prefer not to talk about WinJS that was a dead born project ).

The response has been Blazor with WebAssembly. Why not …

At a time where javascript is becoming one of the biggest ecosystem with new module every day, choosing C# and WebAssembly seems a move that it putting aside plenty of existing resource. I understand that you can call JavaScript from Blazor App but what about JS 6 module import, I’m not sure OF Blazor compatibility with most of Js framework….

Choosing SPA model seemed at first time a good start but with latest Blazor release introducing client side hosting, we get exactly what has always been the error of Microsoft for many years.

Instead to clearly propose a model and be a leader, Microsoft tries to keep open different trend that brings more confusion then flexibility.

What does it means to come back on a server side pattern when SPA is the answer to use client cpu resources that are day after days more powerful: your phone is more power full than the server I started to work on 20 year ago.

Once a gain Web development in Microsoft seem to be a great mess: Client Hosting or Server hosting ?. You can choose one pattern or its opposite and you wonder what the good path is.

At the end i don’t want to rewrite my app because at the beginning it was small and because of success should scale up/out.

Response by @manigandham ...

What's the actual issue here?

React and other JS frameworks already have Server-Side Rendering (SSR) features that initialize and run the app on the server first and output the HTML directly to the browser, with the JS framework optionally picking it up from there.

There's no difference between that and what Server-side Razor Components offer, except that in this case you can continue to have the server rendering the app and still use highly interactive views without doing a full page refresh by using a websocket connection instead. This is Microsoft pushing forward, not copying others.

Response by @brice-prunier-dev ...

I take the risk to answer on this thread because my feedback is link to documentation.

When you propose a new technology i expect to get a precise understanding on what drive a technology. Blazor started on the client side why does it move to server side?

You expose a set of tradeoff for both technology that all application wants to solve:

1. I want a fast start (Server side)
2. I want to easily comply with crawler (Server side)
3. I want to scale (Client side)
4. I want to get an infrastructure as light as possible (Client side)

When you talk about limitation on scale-up for Server hosting what are you talking about:

• How many session can you run with Server Hosting compare to a state less API layer?

@manigandham : I don’t say MS is copying other vendor on Server-Side Rendering. I just say that Client Hosting or Server Hosting (with state management) comes with quite different constraints and today i don’t know where both choice take me.

• If it goes on SSR what’s the use of Web Assembly… Not using Web Assembly is not the same product…
• Is “client side hosting” will allow other JS framework reuse?
• Same question on Server Side ?
• If I go for OAuth on server side hosting, am i in a trusted flow or not ?

To come back to my original thread: Presenting Blazor should at first present what the product is targeting in terms of web solutions in the actual ecosystem.

Moving from Client Side to Server Side (with state management) change all the underlying technology! why such a 360° move?

Is you take SSR on Angular : it is a optimization for startup but the development model stay the same. With Razor we have two different development models without a clear understanding of the overall logic, this quite different in term of communication.

[Andrzej-W]

For those interested why we need C# and not JavaScript for web development: https://github.com/aspnet/Blazor/issues/901#issuecomment-393351887

At a time where javascript is becoming one of the biggest ecosystem with new module every day ...

This is not what programmers like me want. We create big, complicated systems and we have to support them for years. We don't want to rewrite our software every day.

Is you take SSR on Angular : it is a optimization for startup but the development model stay the same. With Razor we have two different development models without a clear understanding of the overall logic, this quite different in term of communication.

SSR in Angular is optimization and probably it should be called prerendering. This is planed (and already partially implemented) for Blazor (client side) and Razor Components (server side). Prerendering is used to speed up initial page display and to return complete HTML markup for each page to web crawlers (SEO optimization). I'm not an expert in JavaScript frameworks but all of them (for example Angular, Vue, React) are client side frameworks and eventually they offer prerendering. Razor Components is the only framework I know which offers full rendering on server which means it sends incremental UI updates to the browser when user interacts with the applications. This feature has one very important advantage for some developers. They can create an application which is very responsive and looks like typical SPA but at the same time all code is executed only on the server and never transmitted to the browser. If the application offers some unique functionality you can be sure that nobody will steal you code .

We don't have the final version of Blazor / Razor Components yet, but it is already easy to switch between two hosting models if you prefer client side mode and want to switch to server side only temporarily. If you want to create a fully optimized application for both hosting modes it will be a little bit harder because you will have to create some abstraction layer for data access. Personally I prefer client side (WebAssembly) but there are a few problems. In current implementation it is slow because it is not native WebAssembly. It is native .NET DLL which is interpreted in the browser. Debugging experience is also far from perfect (currently only experimental). On the other hand debugger in VS is first class and this is the reason why you want to switch to server side mode during development. .NET Core is probably more stable and has less bugs than Mono on WebAssembly. If you want to create and publish your application fast you should probably choose server side mode (Razor Components). It will be released as supported product together with ASP.NET Core 3.0. If you prefer client side mode and you can wait for a final product a little longer, then use it now and don't worry that you have a choice - use client side mode and switch to server side when you have to find a bug and you want to use Visual Studio debugger.

[brice-prunier-dev]

@Andrzej Włoszczyńsk I do agree on most of your remark and as you, I’ve been on mission critical apps but don’t miss understand what i said : At a time where javascript is becoming one of the biggest ecosystem with new module every day ... Doesn’t mean you have to change your third party tool every month but rather that the JavaScript ecosystem is huge and can be a big help for your project. Razor Ecosystem is the opposite and if you look at « Windown phone » being not compliant with existing ecosystem can kill your roadmap.

For me the main point is the following:

• Blazor started as a Client Side hosting product with an architecture based on WebAssembly,
• Suddenly it becomes Server Side with a brand new engine (No more Web Assembly but SignalR becomes the core middleware for state management )

What is the logic in this evolution…?

The two strategy are completely different:

• SPA architecture is well known i won’t come back on it.
• Server side hosting if full of challenging question
  • How do you maintain few thousand of session with high availability ?
  • Will be Web Socket mandatory?
  • What if I a server fails do we lost all the session…
  • What will be the performance impact to implement a share state among different server to insure high availability ?
  • As i bet the solution will rely on webfarm does it implies having load balancer with session affinity….
  • How will it stand with reverse proxy ?
  • @Andrzej Włoszczyńsk you said it will be « very responsive » from my experience the main reason why SPA is so efficient is that it spares many useless round trip call to the serve what won’t be the case with Blazor on a server hosting mode :
  • Ex. a basic use is a list the user can sort it on different columns.

My core remark is Blazor “Server side hosting” is presented as a new feature when it is in fact a new product with a totally different engine even if the coding seems the same.

Once again Microsoft is waiting for the end user to make the choice where I was expecting to have a clear vision on how Microsoft sees the future of web development? Web assembly or not?

[manigandham]

@brice-prunier-dev

It's true that the messaging has been somewhat unclear during the experimental phase but I'll try to clear it up:

The big new feature is Razor Components. They are a new way to create views using "components" that can be nested, similar to what we have with React. This is all C# code and assemblies.

Blazor is just a way to run .NET code on the client using the Mono runtime in WebAssembly. This means you can run the Razor Components code wherever you want for your application. They are the exact same DLLs and you can run them on the server (using .NET Core) or on the client (using Mono with WebAssembly).

Server-side Razor components will require a persistent connection so that they can update the UI but SignalR already handles the connection (with multiple transport options) and there are already many ways to share state across multiple servers. If you don't want to do that then you can use the client-side option to run all the logic on the client itself. Or you can just do normal server-side HTML too.

Razor components can already interoperate with other Javascript code in the browser, however mixing completely different frameworks is untested and probably won't work. I don't think anyone actually mixes separate frontend frameworks anyway so that's not a big concern but you can call JS methods and use other JS libraries from your Razor components. You can even run NPM modules directly on the server too with NodeServices.

The result of all this is the ability to develop complex frontends in C# that can run anywhere while still using existing JS code if you need it. It's the best of both worlds. Hope that helps.

[danroth27]

Hi @brice-prunier-dev,

What is the logic in this evolution…?

Our goal is still to support .NET in the browser on WebAssembly along with Blazor as modern .NET based SPA framework. This has not changed. Shipping support for running the Blazor component model, which we now call Razor Components, on the server is a pragmatic step along the way.

Razor Components decouple their rendering logic from how the UI updates get applied. This means they can be run in any process as long as you have some channel to receive the UI events and to apply the UI updates. The same components can be used in-process in the browser, out of process with an Electron app, or even server-side in an ASP.NET Core app.

It's actually easier for us to ship support for running Razor Components on the server initially because all the required pieces are already available. The components run on .NET Core, a shipping a stable runtime. That's why we're moving forward with shipping Razor Components in .NET Core 3.0.

In parallel we are continuing work on Blazor and support for running the same components client-side in the browser on WebAssembly. The biggest work item to finish is the WebAssembly based .NET runtime itself. We don't have a concrete time frame yet for when the .NET support for WebAssembly will be done, but as soon as it is, then client-side hosting of Razor Components will be fully supported.

Server side hosting if full of challenging questions

Agreed - the server-side hosting model has specific scale out considerations, and it is not a one size fits all solution. We do provide the Azure SignalR Service to help with the connection scale out problem, but apps will still need to handle app state persistence and scale out. However, many customers have told us that they prefer this solution for a variety of reasons: it keeps the code on the server where it can be centrally managed, faster startup time, no WebAssembly requirement, works with older browsers, etc. Later, we will also support running client-side in the browser on WebAssembly.

Once again Microsoft is waiting for the end user to make the choice where I was expecting to have a clear vision on how Microsoft sees the future of web development? Web assembly or not?

We absolutely see WebAssembly as part of the future of web development. But different apps have different requirements. We are trying to provide a flexible solution while still maintaining a consistent programming model.

I hope this helps!

[199621616]

关键是如何认识、如何定位Blazor的问题。尽管Angular、React、Vue等目前最热的前端Javascript框架的已经形成一个很大的生态系统，但是也不能否认它们具有巨大的局限性。Blazor是这些Javascript框架的替代品，是下一代的大前端框架。支持您danroth27，一路顺风！

[dmarquezbh]

The key is how to understand and how to locate Blazor. Although the hottest front-end Javascript frameworks such as Angular, React, and Vue have formed a large ecosystem, they cannot be denied that they have huge limitations. Blazor is an alternative to these Javascript frameworks and is the next big front-end framework. Support your danroth27, bon voyage!