Guidance for sharing Blazor Webview with browser?

[JohnGalt1717]

Any suggestions on how to share the webview code with browser?

I'd love some guidance on how we can do a targeted compile that does mobile but also does browser with the same code base (and obviously would have some sort of detection on if it is running in Xamarin or in a browser so that we could target functionality like say screen cap to either use Xamarin nuget packages or use javascript interop.

[Eilon]

Hi @JohnGalt1717 that's a very interesting question - one that a few of us have given some thought to already.

My current thinking is that the guidance for this scenario will revolve around Razor Class Libraries (RCLs). An RCL is a way to package up web UI + code + static assets (e.g. CSS, JS, images) and share them. They can be shared between projects in a solution, or even published as a NuGet package and shared with the world.

I think that some very basic scenarios already work today with RCLs. The main thing that doesn't work is static assets, which is tracked in https://github.com/xamarin/MobileBlazorBindings/issues/129

For having host-dependent behavior, in that same issue #129 there's a mention of using dependency injection (DI) so that each of your apps can provide different implementations of services to the code that's in the RCL.

For JS interop, I think that in theory it should also "just work" if everything is wired up correctly. But there could be a bug there right now, which might be what issue https://github.com/xamarin/MobileBlazorBindings/issues/150 is about.

So, we don't have any official guidance for this right now because we don't have the scenario fully working yet. But when we do, it should be tracked by that same issue #129 .

Please let me know if I missed any part of your question.

[JohnGalt1717]

So this is of absolutely VITAL importance. For Blazor to be successful it has to compete with Flutter which allows a single code base to run on Web, mobile and desktop without alteration. This should be first and foremost on your mind while building this. We should be able, with a single click in Visual Studio or a single command at the CLI create a project that just works using Blazor with the exact same code for Web, iOS, Android, macOS, Windows and Linux. It has to be transparent. And packages need to be able to target all platforms. That is, if I write a video player that supports HLS and DRM as an example, I have to be able to package that up with nuget so that it will then work on all 6 platforms transparently.

It's no longer good enough to provide tools for native apps and then a different tool for web. It has to all just work with one language and one markup. This is why the standard Blazor bindings weren't going to go anywhere, but this is interesting.

I'd strongly suggest you review what the flutter team is doing with platform interface and how they're building plugins (packages in .net terms) that can be incrementally built for a limited set of platforms and then have other platforms added with other packages from other people that share the same interface.

And look at how flutter create works and make sure that it's no more difficult to do the same with the same functionality for Blazor. Blazor has 3 massive advantages if done right over flutter:

1. It uses HTML markup which is familiar to many/most people.
2. It has the Xamarin Tooling behind it.
3. It's C# which is vastly ahead of Dart.

Once build once is addressed, Microsoft can beat Flutter if it can get to flutter performance levels (especially rendering and memory usage on ios/android) and provides free iOS build and simulator time to VS.net subscriptions so that we don't ever need a Mac. This also brings back devs from Mac and makes Windows the primary target of development again instead of Macs if you do this right, which then solves the Windows app gap as a side effect.

In short, what you're doing here determines the future of Windows, .NET for end users, and very likely Microsoft's entire future in the end user space. So, no pressure or anything.

[Eilon]

This is terrific feedback, thank you for sharing. In this experiment we're trying out lots of different directions to see what resonates, so this feedback is helpful for us to understand what your values are.

Can you share more info on what type of apps you'd want to build with the ideal tech? Are you building LOB apps, e-Commerce, etc.?

[ansarizafar]

I have proposed a Unified Blazor hosting model for building full stack, multiplatform, fast and interactive apps.

[JohnGalt1717]

@Eilon Basically I want to be able to build ANY (short of games) app and have it just work with the same code base. I.e. I want what Flutter does but using C#/blazor. To be clear, I'm looking for a C# solution that allows me to write even UX code once and it works across all platforms without alteration. Right now, the current blazor bindings require web code, and then mobile code. That's one too many and puts Blazor/Microsoft developers at a significant disadvantage both time-wise and cost-of-development-wide versus Flutter developers that write it once and it works everywhere as long as they write it using responsive UX. (i.e. using bootstrap for flutter etc.)

ALL of Microsoft's end user development talent and effort needs to be focused on that goal because Flutter has years of progress ahead of what Microsoft is doing, and especially in small teams (which make up the vast majority of developers, not your fortune 500 customers that you listen to most for feedback that are hell bent on making Winforms/WPF/UWP/Xamarin into the Cobol/Fotran of the 21st century and Microsoft is letting them) the productivity gains of using Flutter is phenomenal because we can use one set of code it and it just works everywhere including web. (and don't make us write Xaml)

We would be vastly more productive if we could do ALL of our code in C# not just backened code, but until I can do so for Web/ios/android/windows/macos/linux like Flutter it's vastly more efficient for me to teach my devs Dart and make due with flutter. (dart is awful compared to C# but it's good enough when you factor in all of the other productivity gaines of the flutter rendering engine)

Honestly the best approach would be to do embrace and extend like Edge embraced Chromium and WSL2 embraced linux, but if, because of politics, it isn't viable to take Steve Sanderson's work on flutter bindings and run with it, then Microsoft needs to come up with a viable competitor to Flutter. Maui/Xamarin as currently outlined isn't it.

Unfortunately, while the Blazor Web View is better than nothing it still has a massive overhead and poor performance compared to Flutter rendering on ios/android because of the browser being in there. But it would definitely give you a foot in the door of creating a truly cross platform including web environment.

I know MS HATES me saying this, but hopefully someone at Microsoft steps up and makes the hard choices like they did with Edge and WSL 2 for .NET because the current approach is very very quickly making .NET irrelevant for all but legacy code for end user. Project reunion etc. is about serving legacy which is ever shrinking and being ported out to the web with no real future for windows apps as the browser gets more and more functional. It's clearly a response to feedback from fortune 500s that don't want to rewrite applications, which is fine as far as it goes, but there's no long term plan to compete with Flutter and the .NET/Xamarin team needs to get one yesterday which means one code base, Web, ios, android, mac os, windows, and linux and all of those without ever having to own any apple devices to build and publish to the ios store. Only then will UX developers come back to windows.

So really, take all of the flutter apps (hundreds of thousands in the stores now) and really any Microsoft apps and make sure that Blazor can build those and do so for all platforms including web in one code base and a single markup and you'll have the solution. If you want to write a competitor to Flutter's rendering engine on all those platforms and maintain it while being a 3rd party on all but one, and you think that's viable to do, then let's see that plan. You have a ton of C# developers that are begging you for this plan and desperately trying to get you to do it in some fashion. But even this it's like no one is taking the overall goal seriously and doesn't understand why Windows is failing and why .net has basically 0 inroads while Flutter is booming. This should have been designed from the ground up to be a single development story to compete with Flutter, not a "well we added this thing, and you've got a great idea that we've sort of tossed around, and now we're interested in your suggestions". That's deeply scary to me that no one internally has a plan. This should be driven from Panos Paney down the pike hard. Hell, Panos should be in charge of all Windows development tools too and simply consuming .NET to get it done and align the development tools with the rebirth of Windows and windows software development.

But I'm not from a fortune 500 company, nor are the rest of us that have spoken up on this in the past, so I guess it's falling on deaf ears because Microsoft is looking in the rear view mirror not the future.

(And please don't suggest React Native, it has exactly the same problems as Xamarin for exactly the same reasons. It doesn't matter that MS is using it instead of their own Xamarin tools for the vast majority of their cross platform work (which tells you everything you need to know about Xamarin and what MS thinks about it's own cross platform toos). React Native is yesterday's tooling. Flutter and one codebase are today's.)

[JohnGalt1717]

Any updates on this?

[Eilon]

Hi @JohnGalt1717 I don't have any update on this. Targeting native and web apps from a single UI codebase is of course a "holy grail" of UI tech and it's a huge problem to solve. Many platforms are approaching it by using HTML as the language for UI layout and content because it's already nearly perfectly supported on every platform. I'm not aware of any huge success of any platform that authors UI in anything other than HTML but yet targets all platforms, including web. I know that many have tried, but I'm not aware of any that stand out as a success story.

Of course, that doesn't mean no one is trying or that it won't happen. And it's something I've discussed several times with my colleagues at Microsoft. At this time we don't have any plans to share but it's certainly an angle that comes up every so often.

We haven't forgotten about it - it's a super huge and important topic - but as far as I know it's not currently set as the next step in our UI journey. (But I don't speak for all UI tech at Microsoft!)

[JohnGalt1717]

Flutter, flutter, flutter.

As in flutter in 2 years has more apps for it than xamarin has in its entire life.

And it works on web very well and macOS and now Linux and windows.

Microsoft either prioritizes this or becomes irrelevant on all app development.

Which is why I'm shocked that this isn't the first and only concern for end user dev at Microsoft. Literally nothing else matters because windows depends on a Microsoft answer to this question.

Smart money would do an edge with chromium and adopt the flutter rendering engine, make it best on windows and hook up c# and the xamarin tooling and make it so no one has to own a Mac.

Literally panos paney could solve his problems in one master stroke and give Microsoft a viable way back into mobile as google weakens because of anti trust and Apple locks itself in.

But if you're not going to do that, then you need to merge blazor and xamarin yesterday. It won't have the power of flutter because you don't solve the app gap as a result but at least it will be something for green field projects.

[Eilon]

No doubt that Flutter is successful but I wasn't aware that many people use it to target web as well (I know they can, but I wasn't aware that many people do).

Either way, targeting web is definitely an idea that is being discussed, but there just isn't any plan to share about it right now.

For this project the next steps are to improve hybrid app support which will absolutely enable building a single UI in a single project using HTML and Blazor and have it run on any platform that exists, either in a hybrid host, or in a web browser. There are a lot of improvements in Blazor, Xamarin.Forms, and Mobile Blazor Bindings, that should continue to make this experience better and we think will solve a huge problem that app developers have today.

[JohnGalt1717]

50,000-70,000 new flutter apps a month that could just work on windows too.

And flutter web is about to go final which gets all of those apps that aren't front line landing pages just working on web too (and tons of web sites already. I'd guess more than all of blazor combined.) and macOS and Linux. (Like blazor wasm it isn't suited for landing pages)

I strongly encourage you to champion a real solution that is fully baked and not a mishmash mess as you've outlined. This needs to be going to vp/ceo desks and made as big a deal as internet explorer in 1997. This is the future or end of windows. Do it right and windows is viable, google is doing work for you like they are with chromium and as google has to divest and Android becomes Samsung for all intents and purposes Microsoft has a google plan as a 3rd party system. Especially if people don't need macs to do iOS viably care of azure Mac emulation for free in vs subscriptions.

Do it wrong and why would anyone dev on windows or even use windows when most apps are increasingly flutter and work better on Linux even than windows?

[Eilon]

Hi @JohnGalt1717 thank you again for sharing your thoughts. I've shared this thread with my colleagues who work on Blazor, Xamarin.Forms, and some other tech so that they can internalize this feedback as well.

The goal for Mobile Blazor Bindings right now is what I mentioned earlier: Having a great way to build native and hybrid cross-platform apps and sharing HTML-based UI code in reusable projects.

These are still early days and we are experimenting in many different areas to figure out the best ways to leverage the technologies we have while also pursuing new areas.

[Kukks]

I agree with @JohnGalt1717 that this is incredibly important.

There is another Blazor based project https://github.com/Daddoon/BlazorMobile which lets you package Blazor for multiple platforms, including web via WASM and server.

They are also considering integrating this library, tracked by this issue: https://github.com/Daddoon/BlazorMobile/issues/229

But until then, I am not sure I would be able to choose to build projects with this as I would end up needing to write 2 separate applications for Web and native experiences.

[jspuij]

The fundamental difference between flutter and Blazor is that Flutter uses Skia as a rendering engine and does not render (or use HTML). Native skia implementations exist for IOS/Android/Windows/Linux/Mac and there is both a Dom Canvas javascript renderer and a WebAssembly renderer called CanvasKit.

Flutter's web support is still poor and I doubt it will ever catch up with real web development. The same kind of disadvantages for you mention for Blazor more or less apply to Flutter for web as well:

• Dart is compiled to javascript for web to run on the javascript instead of running directly on a Dart VM. This implies subtle differences not at all different to running Blazor on WASM.
• Perfomance of the Dom Canvas Renderer is horrible. CanvasKit is better, but still has to travel a javascript / webassembly interop not all too different from Blazors JS interop reliance to render.
• You lose all the native web tools like inspection of the DOM or native browser gestures. These are all re-implemented by Flutter for web inside SKIA and just feel less native or responsive on e.g. a windows laptop with a touch screen.

Try the gallery app once and you'll know what I mean. especially resizing across different screen widths or dragging or scrolling some UI elements.

So while Flutter gives you web support, it's far from being a native citizen on this platform. In this regard it's not so different from Uno which brings XAML (I know) rendering to the browser and aims to be a universal solution for .NET.

Now I know that Blazor WASM performance is slow compared to native .NET because of it currently being interpreted. AOT might change this and will allow Blazor on WASM to bridge that performance gap. MobileBlazorBindings does not suffer from this because it runs on a real .net runtime and draws native controls. The renderer interop inside the BlazorWebView is still javascript on all platforms, but as browsers open up this might change in the future.

That does not change the fact that Flutter is hugely popular and the scattershot approach to cross platform GUI development by MS (Xamarin Forms, UWP, MAUI, Blazor with MBB) does not help in creating a platform that is used and loved by many.

I still have more faith in HTML, CSS (as imperfect as they may be) bridging the gap to desktop and mobile development than Flutter becoming the de-facto web platform of the future, but I might be wrong ;-)

[JohnGalt1717]

The fundamental difference between flutter and Blazor is that Flutter uses Skia as a rendering engine and does not render (or use HTML). Native skia implementations exist for IOS/Android/Windows/Linux/Mac and there is both a Dom Canvas javascript renderer and a WebAssembly renderer called CanvasKit.

Correction: Blazor currently uses HTML. It has been demonstrated using the flutter rendering engine, which is the work that should be resumed instead of killed.

Flutter's web support is still poor and I doubt it will ever catch up with real web development. The same kind of disadvantages for you mention for Blazor more or less apply to Flutter for web as well:

I've tested the same application in Blazor and Flutter. Flutter is smaller by about 10%, loads faster, and uses exactly the same code as our iOS and Android apps. It does full tree shaking, linking and minimization which Blazor still doesn't do because of AOT issues. If you choose to enable webassembly mode for rendering in some cases, it increases in size to similar to blazor, but then becomes vastly faster at rendering in some cases. In all case other than landing pages which Blazor WASM also isn't a good idea for, there is no case that we've found where Blazor is superior to (other than C#) Flutter on web. So while it was previously true that Flutter web was weak, it is no longer and is getting progressively better on a weekly basis.

• Dart is compiled to javascript for web to run on the javascript instead of running directly on a Dart VM. This implies subtle differences not at all different to running Blazor on WASM.

I don't know what this is supposed to mean. Everything renders identically web to ios, android, and macos and every case where it isn't, filing a bug with the flutter team gets it fixed quickly.

• Perfomance of the Dom Canvas Renderer is horrible. CanvasKit is better, but still has to travel a javascript / webassembly interop not all too different from Blazors JS interop reliance to render.

Yes, you don't want to be writting JS games with Flutter. Nor should you without CanvasKit. But worst case scenario you're Blazor on web but get ios, android, macos, linux and windows for free. So I fail to see the point.

• You lose all the native web tools like inspection of the DOM or native browser gestures. These are all re-implemented by Flutter for web inside SKIA and just feel less native or responsive on e.g. a windows laptop with a touch screen.

...And the flutter developer tools fill in nicely. Not sure what you're point is.

So while Flutter gives you web support, it's far from being a native citizen on this platform. In this regard it's not so different from Uno which brings XAML (I know) rendering to the browser and aims to be a universal solution for .NET.

No one claims it is. But what it is, is a viable solution for writting Web, Windows, iOS, Android, MacOS and Linux in a single code base with pixel perfect results between platforms. Uno is trying, but the reality is that it will never get there unless MS embraces supporting all of it. Given that MAUI won't have web support, good luck for UNO.

Now I know that Blazor WASM performance is slow compared to native .NET because of it currently being interpreted. AOT might change this and will allow Blazor on WASM to bridge that performance gap. MobileBlazorBindings does not suffer from this because it runs on a real .net runtime and draws native controls. The renderer interop inside the BlazorWebView is still javascript on all platforms, but as browsers open up this might change in the future.

That does not change the fact that Flutter is hugely popular and the scattershot approach to cross platform GUI development by MS (Xamarin Forms, UWP, MAUI, Blazor with MBB) does not help in creating a platform that is used and loved by many.

I still have more faith in HTML, CSS (as imperfect as they may be) bridging the gap to desktop and mobile development than Flutter becoming the de-facto web platform of the future, but I might be wrong ;-)

No one is claiming Flutter is going to become the de-facto web platform. What they're saying is that Microsoft has no answer to Flutter which is the real competition: LOB, and even consumer companies being able to quickly prototype and build apps for iOS, Android, and Web in a single language with one set of code that largely just works and speed is good enough to be acceptable to essentially everyone except for maybe dialup and 3 mbps DSL users.

Yes, if you have the dollars to be able to fund writing your app at least 3 times, (and note that even large companies don't have the budgets for Windows too which is a massive problem for MS as it gets religated to being an expensive Web Browser) you'll write a custom web app in HTML, a custom iOS app in Swift and a custom Android app in Kotlin. All of which has nothing to do with Microsoft because with the exception of Typescript which is optional on HTML, none of that entire pipeline involves Microsoft. None. Which should be sending alarm bells up the flag poll at Microsoft.

And if you investigate Xamarin, with the exception of the superior C# and the remote simulators you're going to say to yourself "wait a second. I can have my team write iOS, and Android as well or better than Xamarin, and I get macOS, Linux, Windows, and Web for free out of the deal? And the web is more than acceptable for most LOB apps just like any of Microsoft's tech? Why would I use Xamarin, and Blazor and UWP/WPF and Swift for Mac and GTK+ when I can cut that all down to 1 or maybe 2 if I really don't like Flutter's web support?" (and no, Xamarin on Windows, mac and Linux are not viable for anything more than hello world as I'm sure everyone is aware)

[Kukks]

The fundamental difference between flutter and Blazor is that Flutter uses Skia as a rendering engine and does not render (or use HTML). Native skia implementations exist for IOS/Android/Windows/Linux/Mac and there is both a Dom Canvas javascript renderer and a WebAssembly renderer called CanvasKit.

Correction: Blazor currently uses HTML. It has been demonstrated using the flutter rendering engine, which is the work that should be resumed instead of killed.

Flutter's web support is still poor and I doubt it will ever catch up with real web development. The same kind of disadvantages for you mention for Blazor more or less apply to Flutter for web as well:

I've tested the same application in Blazor and Flutter. Flutter is smaller by about 10%, loads faster, and uses exactly the same code as our iOS and Android apps. It does full tree shaking, linking and minimization which Blazor still doesn't do because of AOT issues. If you choose to enable webassembly mode for rendering in some cases, it increases in size to similar to blazor, but then becomes vastly faster at rendering in some cases. In all case other than landing pages which Blazor WASM also isn't a good idea for, there is no case that we've found where Blazor is superior to (other than C#) Flutter on web. So while it was previously true that Flutter web was weak, it is no longer and is getting progressively better on a weekly basis.

• Dart is compiled to javascript for web to run on the javascript instead of running directly on a Dart VM. This implies subtle differences not at all different to running Blazor on WASM.

I don't know what this is supposed to mean. Everything renders identically web to ios, android, and macos and every case where it isn't, filing a bug with the flutter team gets it fixed quickly.

• Perfomance of the Dom Canvas Renderer is horrible. CanvasKit is better, but still has to travel a javascript / webassembly interop not all too different from Blazors JS interop reliance to render.

Yes, you don't want to be writting JS games with Flutter. Nor should you without CanvasKit. But worst case scenario you're Blazor on web but get ios, android, macos, linux and windows for free. So I fail to see the point.

• You lose all the native web tools like inspection of the DOM or native browser gestures. These are all re-implemented by Flutter for web inside SKIA and just feel less native or responsive on e.g. a windows laptop with a touch screen.

...And the flutter developer tools fill in nicely. Not sure what you're point is.

So while Flutter gives you web support, it's far from being a native citizen on this platform. In this regard it's not so different from Uno which brings XAML (I know) rendering to the browser and aims to be a universal solution for .NET.

No one claims it is. But what it is, is a viable solution for writting Web, Windows, iOS, Android, MacOS and Linux in a single code base with pixel perfect results between platforms. Uno is trying, but the reality is that it will never get there unless MS embraces supporting all of it. Given that MAUI won't have web support, good luck for UNO.

Now I know that Blazor WASM performance is slow compared to native .NET because of it currently being interpreted. AOT might change this and will allow Blazor on WASM to bridge that performance gap. MobileBlazorBindings does not suffer from this because it runs on a real .net runtime and draws native controls. The renderer interop inside the BlazorWebView is still javascript on all platforms, but as browsers open up this might change in the future. That does not change the fact that Flutter is hugely popular and the scattershot approach to cross platform GUI development by MS (Xamarin Forms, UWP, MAUI, Blazor with MBB) does not help in creating a platform that is used and loved by many. I still have more faith in HTML, CSS (as imperfect as they may be) bridging the gap to desktop and mobile development than Flutter becoming the de-facto web platform of the future, but I might be wrong ;-)

No one is claiming Flutter is going to become the de-facto web platform. What they're saying is that Microsoft has no answer to Flutter which is the real competition: LOB, and even consumer companies being able to quickly prototype and build apps for iOS, Android, and Web in a single language with one set of code that largely just works and speed is good enough to be acceptable to essentially everyone except for maybe dialup and 3 mbps DSL users.

Yes, if you have the dollars to be able to fund writing your app at least 3 times, (and note that even large companies don't have the budgets for Windows too which is a massive problem for MS as it gets religated to being an expensive Web Browser) you'll write a custom web app in HTML, a custom iOS app in Swift and a custom Android app in Kotlin. All of which has nothing to do with Microsoft because with the exception of Typescript which is optional on HTML, none of that entire pipeline involves Microsoft. None. Which should be sending alarm bells up the flag poll at Microsoft.

And if you investigate Xamarin, with the exception of the superior C# and the remote simulators you're going to say to yourself "wait a second. I can have my team write iOS, and Android as well or better than Xamarin, and I get macOS, Linux, Windows, and Web for free out of the deal? And the web is more than acceptable for most LOB apps just like any of Microsoft's tech? Why would I use Xamarin, and Blazor and UWP/WPF and Swift for Mac and GTK+ when I can cut that all down to 1 or maybe 2 if I really don't like Flutter's web support?" (and no, Xamarin on Windows, mac and Linux are not viable for anything more than hello world as I'm sure everyone is aware)

I'm unsure what your point is here now. For me, this issue is about being able to, for the most part, write once deploy everywhere. And by everywhere I mean mobile, desktop and web. Seems like the basis for Mobile is covered, desktop is almost there( windows variant is buggy, mac works, linux nonexistent?) and web is on its way with #178 and #195

Most designers have struggled to deal with Microsoft's painful history of XAML support and I'm no fan of it either(dev) and have often rejected jobs that would have required me to work with it (and have chosen non .NET based work over it). Blazor still presents its own major dealbreakers compared to standard JS SPA frameworks such as the lack of hot reload but projects like https://livesharp.net solved it beautifully where Microsoft seems to have failed (how and why remains a mystery but i hope they throw a buttload of money at buy and incorporate livesharp into dotnet tooling).

I don't care much for Xamarin but this project is incredibly valuable in that I can finally run C# on both frontend and backend with an HTML based UI and with the proper abstraction and planning, can leave Xamarin out and deploy to web too!

[jspuij]

The fundamental difference between flutter and Blazor is that Flutter uses Skia as a rendering engine and does not render (or use HTML). Native skia implementations exist for IOS/Android/Windows/Linux/Mac and there is both a Dom Canvas javascript renderer and a WebAssembly renderer called CanvasKit.

Correction: Blazor currently uses HTML. It has been demonstrated using the flutter rendering engine, which is the work that should be resumed instead of killed.

Flutter is more than a rendering engine. It's a component library as well. There is absolutely no advantage to using Flutter (other than a tech demo) from Blazor as it only adds indirection layers and uses a foreign component library. However it would make sense to write a MAUI (as nextgen cross platform App UI by MS) renderer using webassembly and WebGL directly for the browser. This way there will be MAUI support everywhere, equal to UNO and equal to flutter without the indirection layers. I predict that this is the direction MS will be taking. MBB will serve in a future incarnation as the Blazor bindings for that (in addition to XAML and MVU that is already supported).

Flutter's web support is still poor and I doubt it will ever catch up with real web development. The same kind of disadvantages for you mention for Blazor more or less apply to Flutter for web as well:

I've tested the same application in Blazor and Flutter. Flutter is smaller by about 10%, loads faster, and uses exactly the same code as our iOS and Android apps. It does full tree shaking, linking and minimization which Blazor still doesn't do because of AOT issues. If you choose to enable webassembly mode for rendering in some cases, it increases in size to similar to blazor, but then becomes vastly faster at rendering in some cases. In all case other than landing pages which Blazor WASM also isn't a good idea for, there is no case that we've found where Blazor is superior to (other than C#) Flutter on web. So while it was previously true that Flutter web was weak, it is no longer and is getting progressively better on a weekly basis.

I do not second that. Try running the gallery and scrolling or resizing. It's still horrible. Things like scrolling and scaling should be snappy and it is very hard to achieve that in the browser from webassembly.

• Dart is compiled to javascript for web to run on the javascript instead of running directly on a Dart VM. This implies subtle differences not at all different to running Blazor on WASM.

I don't know what this is supposed to mean. Everything renders identically web to ios, android, and macos and every case where it isn't, filing a bug with the flutter team gets it fixed quickly.

I'm not talking about the renderer. I'm talking about Dart as a language. Dart now runs on its own VM outside the browser, and is not transpiled anymore to javascript for these platforms. That leads to stuff being created that does not work inside web anymore like dart:ffi. This is the same kind of issue as threading currently not supported on Blazor WASM that people regularly walk into. As soon as you have two different runtime environments, you will get these kind of issues.

• Perfomance of the Dom Canvas Renderer is horrible. CanvasKit is better, but still has to travel a javascript / webassembly interop not all too different from Blazors JS interop reliance to render.

Yes, you don't want to be writting JS games with Flutter. Nor should you without CanvasKit. But worst case scenario you're Blazor on web but get ios, android, macos, linux and windows for free. So I fail to see the point.

CanvasKit relies on emscripten bindings to receive mouse events etc from the browser. Take my word for it that it has overhead comparable to the JS interop from Blazor. Or maybe not, have a look at one of the dart developers: https://github.com/dart-lang/sdk/issues/37882#issuecomment-588551881. If you have to take it into consideration for one platform and you want to target it, you have to take it into consideration and think of workarounds.

So while Flutter gives you web support, it's far from being a native citizen on this platform. In this regard it's not so different from Uno which brings XAML (I know) rendering to the browser and aims to be a universal solution for .NET.

No one claims it is. But what it is, is a viable solution for writting Web, Windows, iOS, Android, MacOS and Linux in a single code base with pixel perfect results between platforms. Uno is trying, but the reality is that it will never get there unless MS embraces supporting all of it. Given that MAUI won't have web support, good luck for UNO.

MAUI is extensible so I fully suspect a community effort (or maybe even later support from microsoft) to develop a MAUI Renderer directly on top of mono-wasm using WebGL. Also the new MAUI architecture should support both fast rendering of native controls, as well as rendering of your own control library based on graphics primitives (the UNO or flutter way to speak) Question is whether it eventually will deliver on performance. Time will tell. Your call for more priority within MS I certainly agree with. (It'd be nice to also speed up AOT for WASM and multithreading support for WASM).

Now I know that Blazor WASM performance is slow compared to native .NET because of it currently being interpreted. AOT might change this and will allow Blazor on WASM to bridge that performance gap. MobileBlazorBindings does not suffer from this because it runs on a real .net runtime and draws native controls. The renderer interop inside the BlazorWebView is still javascript on all platforms, but as browsers open up this might change in the future. That does not change the fact that Flutter is hugely popular and the scattershot approach to cross platform GUI development by MS (Xamarin Forms, UWP, MAUI, Blazor with MBB) does not help in creating a platform that is used and loved by many. I still have more faith in HTML, CSS (as imperfect as they may be) bridging the gap to desktop and mobile development than Flutter becoming the de-facto web platform of the future, but I might be wrong ;-)

No one is claiming Flutter is going to become the de-facto web platform. What they're saying is that Microsoft has no answer to Flutter which is the real competition: LOB, and even consumer companies being able to quickly prototype and build apps for iOS, Android, and Web in a single language with one set of code that largely just works and speed is good enough to be acceptable to essentially everyone except for maybe dialup and 3 mbps DSL users.

Yes, if you have the dollars to be able to fund writing your app at least 3 times, (and note that even large companies don't have the budgets for Windows too which is a massive problem for MS as it gets religated to being an expensive Web Browser) you'll write a custom web app in HTML, a custom iOS app in Swift and a custom Android app in Kotlin. All of which has nothing to do with Microsoft because with the exception of Typescript which is optional on HTML, none of that entire pipeline involves Microsoft. None. Which should be sending alarm bells up the flag poll at Microsoft.

And if you investigate Xamarin, with the exception of the superior C# and the remote simulators you're going to say to yourself "wait a second. I can have my team write iOS, and Android as well or better than Xamarin, and I get macOS, Linux, Windows, and Web for free out of the deal? And the web is more than acceptable for most LOB apps just like any of Microsoft's tech? Why would I use Xamarin, and Blazor and UWP/WPF and Swift for Mac and GTK+ when I can cut that all down to 1 or maybe 2 if I really don't like Flutter's web support?" (and no, Xamarin on Windows, mac and Linux are not viable for anything more than hello world as I'm sure everyone is aware)

I'm not sure I'm following you. With MBB and Blazor I've been able to develop LOB applications perfectly fine that support maximal code reuse and don't require any platform specific code other than some stubs. Also there are 40K repos on github that use Xamarin, v.s. 175K repositories that use Flutter. Yes flutter is more popular, but to say that Xamarin has no future is just not true.

I'm worried though that Blazor does not get enough attention from MS to catch up with other frameworks. Hot reload, AOT, threading support have all been pushed back from .NET 5 to .NET 6. Equally worrying MAUI is by no means on schedule to fullfill all it's goals before .NET 6. The world might have moved on by then.

[arivera12]

I read all comments and points of view it was very interesting. I would just simply stick to the web and forget how flutter works. We just want single base code for multiple platforms right? We just need Html, css and javascript. Blazor tackles most of javascript stuff. Web is and should be the standard of UI development, all platforms have web browsers and web runs everywhere browser is available, for me since I started developing, web have been the only true standardized portable technology.

[Kukks]

I've created a repo at https://github.com/Kukks/Hara that allows you to share a blazor app with MobileBlazorBindings and Blazor WASM/Server. Included is also integration with Livesharp, which gives you hot reloading on all platforms for both frontend and backend code.

[jspuij]

I've created a repo at https://github.com/Kukks/Hara that allows you to share a blazor app with MobileBlazorBindings and Blazor WASM/Server. Included is also integration with Livesharp, which gives you hot reloading on all platforms for both frontend and backend code.

Very nice!

[Daddoon]

I agree with @JohnGalt1717 that this is incredibly important.

There is another Blazor based project https://github.com/Daddoon/BlazorMobile which lets you package Blazor for multiple platforms, including web via WASM and server.

They are also considering integrating this library, tracked by this issue: Daddoon/BlazorMobile#229

But until then, I am not sure I would be able to choose to build projects with this as I would end up needing to write 2 separate applications for Web and native experiences.

I may have missed the train (and also overwhelmed by work theses last weeks !) but what did Mobile Blazor Bindings do not do out of the box for the one code all platform experience ? Is it about interop and DI, or is it about some kind of build workflow ?

I'm asking because if there is a big gap but somehow reached by Mobile Blazor Bindings on one side and one BlazorMobile on some other sides, it would be cool to revamp the current codebase of the BlazorMobile projects in order to try to achieve theses new goals.

EDIT: And not to mention that current BlazorMobile template do not use RCL format yet for the end-user project by default even if it can, and would have surely helped in some ways on some area.

[Kukks]

I agree with @JohnGalt1717 that this is incredibly important. There is another Blazor based project https://github.com/Daddoon/BlazorMobile which lets you package Blazor for multiple platforms, including web via WASM and server. They are also considering integrating this library, tracked by this issue: Daddoon/BlazorMobile#229 But until then, I am not sure I would be able to choose to build projects with this as I would end up needing to write 2 separate applications for Web and native experiences.

I may have missed the train (and also overwhelmed by work theses last weeks !) but what did Mobile Blazor Bindings do not do out of the box for the one code all platform experience ? Is it about interop and DI, or is it about some kind of build workflow ?

I'm asking because if there is a big gap but somehow reached by Mobile Blazor Bindings on one side and one BlazorMobile on some other sides, it would be cool to revamp the current codebase of the BlazorMobile projects in order to try to achieve theses new goals.

EDIT: And not to mention that current BlazorMobile template do not use RCL format yet for the end-user project by default even if it can, and would have surely helped in some ways on some area.

The killer feature in MobileBlazorBindings is being able to run backend and frontend in one process(so that means no http communication to do interactions) and not running via WASM on the mobile platforms (I can use Xamarin features directly in Blazor components if I wanted to without js interop).

[Daddoon]

@Kukks Thanks for your feedback, also i had some additionals info from @jspuij on my repository about this question yesterday.

It seem that there is nothing that is missing today on Mobile Blazor Bindings for a crossplateform scenario. If i have understood the only missing thing is an official template with already everything configured for this kind of project / model share, but nothing impossible we cannot do by hand.

[Kukks]

@Kukks Thanks for your feedback, also i had some additionals info from @jspuij on my repository about this question yesterday.

It seem that there is nothing that is missing today on Mobile Blazor Bindings for a crossplateform scenario. If i have understood the only missing thing is an official template with already everything configured for this kind of project / model share, but nothing impossible we cannot do by hand.

Yes, I think everything is there. Any limitations I've found are from xamarin itself not this library. I do think additional templates with wasm embedded in electron would be beneficial too.