Repository navigation
Replies: 81 comments 56 replies
|
In theory I think the new proposed renderer architecture ( #28 ) should make it even easier to implement a Blazor based backend. I love your work so far on your blazor renderer experiment, and it's something that you could probably keep working on and transition to the new renderer architecture fairly easily in the future. |
|
This is a must to compete with Flutter which is about to eat Xamarin for breakfast. One platform, means one platform. I don't want to have to have Blazor for web and then write a separate MAUI app. |
Thanks! I definitely intend to try once MAUI settles a little more and it's clear what the rendering engine looks like. One issue with doing XF or MAUI on the web is closely related to the never-ending debate about lookless vs. native look. Web has no native look (at least not one anyone would ever want to use!) so MAUI either needs to go primarily lookless and have the framework take care of the chrome, or we'd have to commit to a particular web design framework (probably Material Design) at some point. I'm still hoping for the former in which case the renderer becomes almost trivial. |
|
@legistek I'd definately say lookless, and then let the developer opt for "Shared styling across all" or "Platform specific". Shared styling would work with web as well, just a set of css that copied it. Platform specific, just use bootstrap or material as a default and let them go from there. Either case, customize with overrides just like CSS allows. |
Agreed, but it's not up to me. :) If for example the renderer has to provide a fully working implementation of a |
|
I would prefer Silverlight style aka WPF Everywhere (XAML/C# not HTML/CSS/Whatever). This time it wouldn't be a browser plugin (SL killer), but it would be based on web assembly. |
|
when they bring Blazor into MAUI - it will be XAML/C# - thats the whole point of MAUI
Blazor is just a bridge now to cut out javascript from web dev
Adding the web target to MAUI (which effectively replaces Blazor) will remove HTML/javascript/css completely and any MAUI app will be able to target web as just another target
this is the ultimate i agree, and something I am very looking forward to
… On 22 May 2020, at 09:41, Tomas Fabian ***@***.***> wrote:
I would prefer Silverlight style aka WPF Everywhere (XAML/C# not HTML/CSS/Whatever). This time it wouldn't be a browser plugin (SL killer), but it would be based on web assembly.
See also Uno platform <https://platform.uno/>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <https://github.com/dotnet/maui/issues/62#issuecomment-632546269>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOGERXXSSAXPM46OH4J5XDRSYUBHANCNFSM4NF6FJMQ>.
|
|
i couldn't agree with you anymore, and this is what i always tell someone. this is EXACTLY how MAUI should be, and how it should target the web. i absolutely can't wait for the day when JS is gone bye bye completely. i never was a fan of HTML/CSS/JS. i would rather have full stack dotnet. the way MAUI was built with abstraction sets it up for this ultimate goal. there just needs to be a web assembly render target instead of blazor. like you mentioned, the maui blazor template right now, as far as im concerned, is just a temporary "get by for now" template. microsoft needs to push this somehow someway. if they already aren't. which i don't think they are based on what i read. something about it's up to the community. total rubbish. Microsoft.Maui.Handlers needs a web assembly target. that would be the nail in the coffin. there would be full cross platform UI consistency for once in the microsoft world. none of this fragmentation mess. Flutter targets web assembly for it's web portion, and i believe Uno does as well. i'm really not sure how a wasm handler target hasn't existed since day one, but i am beyond ready for the day. |
|
I use blazor WebView to display data and native navigation to other BlazorWebView Pages using ContenPage.xaml |
Like it or not [I don't; HTML + CSS is not my vision of a universal UI platform], "web standards" won. Blazor's long term future is secure: IMHO, it replaces the weakest part of web standards (javascript) with one of the best modern languages, C#. I wish and hope that Maui has a good long term future. But that is less certain. |
|
@mrwcjoughin thanks for your clarification. I have to admit, that this thread confused me. It seemed to me that Blazor replacement or web targeting is questionable at the moment.
|
I'm not sure what you're referring to, but if you're talking about this (https://github.com/xamarin/MobileBlazorBindings), unfortunately that is actually going in the opposite direction than what we're talking about. Yes that lets you use Blazor SYNTAX for your mobile app markup, instead of XAML, but you're still only making a mobile app. It does not allow reusing that markup to make a web app as there would still need to be platform renderers developed to implement the Xamarin Forms controls in a web framework such as Blazor's BACKEND (we really don't care about the Blazor/Razor markup syntax because we'd be using XAML). So we're might be talking about two different things. |
|
The problem of course with the current plan is we still have web dev and mobile/desktop dev separate from each other. Even if you being blazor bindings that still means html for web and separate xaml/mvu for everything else. So as a result you're still behind flutter. Using skia means you can compete with flutter because it now becomes viable to write once and cover the web too. Better, co-opting flutter and using c# instead of dart and then contributing Windows skia gets you all of Google's hard work for free just like edgium. And with the tooling that comes with xamarin wrapping 100% of the platform's API so you can write it all in c# instead of knowing swift and kotlin too, remote emulators and azure devops build and publish in the cloud, and you have a major advantage over flutter that Google can't compete with meaning major win, and devs don't need a Mac if done right which means major win there too because that's the #1 reason Windows dev went down the tank. Windows was left to web since every dev was forced to own a Mac anyhow. This current approach doesn't feel well thought-out and still results in Microsoft being way behind flutter in the end of the day and that's 18 months away, versus .net 5 timeframe if they just adopted flutter's rendering engine. |
|
Actually this is the most important requirement for MAUI from our company. But I have to admit, that I as a fullstack .NET developer, I'm not able to keep tracking these rapidly changing web frameworks, plus the rest Docker etc. Therefore we would really appreciate a real C#/XAML/BCL (NETSTANDARD libs eg OData client) ecosysten in the browsers (without Blazor intertwined logic approach). Without the web target we are honestly fine with separate mobile (Xamarin.Forms) and desktop WPF (in the future WinUI 3) platforms, even if we could target WinUI on top of MAUI. From this standpoint Uno platform seems to be more promising. Thank you for your understanding. |
|
I agree. Not including the web target is a huge limitation and Blazor brings with it the burden of using html5/css. |
|
You can use OpenSilver to run Silverlight on modern browsers with webassembly. https://opensilver.net/ |
That's hilarious. The endless circle of tech continues :-) |
|
@tomasfabian I also have a background in WPF. |
|
@mrwcjoughin I understand that the unification of my mobile and desktop apps would be for free. I wanted to emphases that the whole effort from MS doesn't worth it, without a viable browser/web target. But it's only my point of view. Thank you for your support and shout! |
|
Just wanted to give a shout out to one of the forks of my original POC that has started to add some additional renderers: https://github.com/andresgutice/Xamarin.Forms.Platforms.Blazor Would also really love if someone from the Microsoft team wanted to weigh in on this topic. My main question is what would be the reason NOT to officially do this? |
|
Hi @legistek, I found a similar Blazor project in the Xamarin repository Mobile.Blazor.Bindings. It uses .razor files with XAML intertwined with C#. Probably this is the way Microsoft would like to add Blazor to MAUI. |
|
We need WASM/Web target! |
|
What I wrote above is nothing new - it is known from the beginning and written million times at many places - this thread, other github threads, many Microsoft threads and even asked as question in Microsoft online presentations. Believe me - I am highly interested in this topic and I follow any news on it. So I am sure they know about it. Single-liners is just desperate voice for a well-known thing to be heard - despite the fact they do not response. Which leads me towards assumption they have agreement with Uno to not break their business model or with MVC team to not break their. |
|
I've already provided them with this verbally and in email. This is very straight forward: If you're not a tone deaf fortune 500 company with dozens if not thousands of programmers, you're team is made up of people that are vertically integrated throughout the entire stack (and many, many, many companies have a single dev). Let's say your iOS app costs you $30,000 to build. If you have to build it for Android too the cost will be about the same, so you've now doubled your cost. Same for windows so now you've tripled your cost. Same for MacOS so you've now quadrupled your cost, same for Linux so now you've quintupled your cost. Same for Web so now you've sextupled your cost. So, companies do the rational and support the minimum number of platforms they can get away with, which right now, because of Microsoft's poor decision making since iPhone came about, is iOS, Android and Web. Apple recognized what was happening, and so that their desktop platform didn't just become a gateway to a web browser and ensure that the vast majority of the population didn't just buy Chromebooks for vastly less money, they made iOS apps work on Mac. Microsoft has no such option because they drove all of the devs away reinventing the wheel with no backwards compatibility. Worse, when they did finally buy Xamarin, they let it continue to be a hobby project for a very few people instead of doing what Windows desperately needed which was to make it fully cross platform, provide upgrade tools from WPF, UWP, Silverlight and Xamarin Forms to one place for all windows development that also pixel perfect worked on all other platforms. Fast forward a decade and they STILL haven't figured out the only way that Windows actually has a value prop beyond a Chromebook gateway to a web browser because they're still reinventing the wheel instead of providing what their customers want. And what do they want? They want to create their brand exactly once, pixel perfect, across all platforms for the same cost of a single platform. This is self-evident that what I'm saying is true because Flutter, which does exactly that is eating the world (fastest growing development platform in the world BY ALOT) while Maui does virtually nothing more than Xamarin Forms 5 did and still uses a wacko version of XAML instead of just adopting WinUI XAML as should have been the case (and they should have dumped xaml markup and gone to Flutter style code markup at exactly the same time) Why do they want to create their brand and app once? Because $30,000 is vastly cheaper than $180,000 and the ongoing maintenance is 6x less too. And then they don't have to pick what platforms to support and deal with the endless complaints about not supporting xyz platform (although for most of us, people don't care because Windows and Linux are glorified web browsers now, so apps are irrelevant. Only Devs and to a lesser extent engineers and artists actually care, and the later uses Macs, so the justification for using Windows is virtually 0 in most companies with the exception of a few machines for a very few people. And that is dire for Microsoft, because Office sells as well as it does, because of Windows, and Azure sells as well as it does because of Office and Windows. If Windows dies on the vine because of the short sighted decision making of the .NET/MAUI teams as has been the case since 2008, then the office cash cow dies slowly too, and Azure will suffer greatly as well. That's the business case for Microsoft. For everyone else, the use case for devs is pretty straight forward:
Only UNO actually has this capability right now because Flutter uses Dart and Dart sucks on the server side because all of the libraries to do it are 3rd party and die on the vine. (which goes to the business opportunity for Microsoft. See below) And we that this is exactly what EVERY OTHER MAJOR TEAM IN MICROSOFT THEMSELVES ALREADY FIGURED OUT. The office team uses React and builds wrappers using React. they don't use Teams. Even the new Outlook is just a web wrapper around Outlook on web. PowerBi? Same deal. In fact, I don't think any major team in Microsoft uses MAUI, Xamarin or even WinUI unless they're a utility like PowerToys. Microsoft themselves have fled their own development tools because the .NET team was busy reinventing the wheel instead of providing the tools everyone wanted. (And if you think that this BS about platform specific look and feel is a thing that customers actually want, I refer you to the iOS and Android versions of all of the office apps. None of which look any different between platforms. And I dare you to find any app from any major brand that looks significantly different between iOS and Android anymore. But very, very specifically, even Microsoft itself doesn't agree with this inane excuse. Objections with Answers
Yea, no. I'm not going to run a bloated compiled container, to run compiled Blazor inside a web view with interop to compiled Maui. This is possibly the most technologically dumb solution to a problem I've ever heard off and creates a bloated pig of an app that requires you to code both MAUI XAML/C# + HTML + CSS + Blazor on top of server side. There is no upside other than the code is C#. Every other part of it is horrific.
Because of the complete and utter neglect and poor business decisions of Microsoft over the past 14 years, the vast majority of Windows users NEVER use the app store and when they do, it's a waste land of crap so Microsoft can claim a ton of apps in the store, so you're competed out in searched by trolls and spammers. (You could cut 95% of all of the apps in the Windows App Store and you'd still be predominately spam.) And then there are Chromebooks that are taking over for the very reasons I've stated above, and running in Chrome is vastly easier than running Android apps on a Chromebook so we have to cover that audience. (But please make it easy for us to compile to Chromebook as well).
This one is hard to argue. But if there is no point in this then the MAUI team should be tossed entirely as it's a waste of time and resources for Microsoft. And wait 5 years and Windows will be a minority share on the desktop too, and then another 5 years and Office will be one of many running in web browsers and nothing else.
Nope. Not at all. The data from multiple surveys says that companies want a consistent look and feel of their brand across platforms. Microsoft themselves follows this too. No one cares about platform look and feel. Flutter is proof of this. They released the Cupertino skin and 99% of Flutter apps never bother to use it. They all use material because they don't care about platform look and feel.
Yes. These companies, because their priorities are their own, and IT people hate change, are conspiring accidently to destroy Microsoft. They're not aware that they're doing so, but nevertheless, they are. If you keep listening to these companies, you'll be IBM in 10 years at most. Irrelevant and shrinking. You MUST move fast, break things, and fix 14 years of rot. This rot has VASTLY more impact to Microsoft than just the success or failure of MAUI/Xamarin Forms Retread (TM): Windows depends on Microsoft getting a cross platform development story that doesn't suck. Office depends on windows depending on Microsoft Cross Platform, and ultimately Azure does too. (Which should finally get the CEO to notice). In short, Microsoft is on the same trajectory as IBM as they will slowly dump and sell off business units that "aren't making money" to "focus on our core products" not realizing that the stuff that their CEO let languish because he's a server guy, make the stuff that allows the "core products" to make money. So What's the Solution? The solution is the same as it was the day that they bought Xamarin:
If you do this, you win. If you really want to flip the world, create Python.net, make it type safe and create an import tool for python libraries that instantly run faster and have access to the CLI and call it your new VB.net and you'll also win back to the AI and machine learning devs because it will all go together with the above. But this is optional to save MAUI and the desktop. Or you could skip ahead and just buy UNO and then focus on the rest of the pieces and optimize it and save yourself a TON OF TIME. PLEASE start listening. If you don't, Microsoft is a zombie. |
|
@JohnGalt1717 super good writeup, so lovely to see that someone else gets it. Azure and MAUI are treats, but not at all feasible long-term nor market breaking. I do prefer my XAML over the flutter style code, but to each there own I guess :P |
|
Web support is much needed |
|
We can talk a lot, but in 2022 not having web support is a shame. How can we call such a product cross-platform? With all respect. |
|
What can we do to make it better? |
|
Till the time ,when .net maui support web & Linux ,at the time other product like Flutter ,React Native already have eaten the cream of .net maui |
|
Hi. |
|
There are a lot of strategies to support web. Should MAUI components be mapped to HTML components or rendered into a |
|
I think rendering directly on the web canvas is way better and easier. Avoiding the HTML/CSS/JS whole thing is a huge plus comparing that to XAML/MVVM or MVU in every aspect (debugging, ease of development, layout, etc...). |
|
@M144-Coder What about accessibility and responsiveness using a Canvas? |
|
Flutter has solved it now mostly so it isn’t an unsolvable problem and compared to the disaster that is the alternative it’s vastly preferable. Plus MS owns edge that uses Chrome for which Google benefits with flutter if MS makes contributions to chromium that help solve this problem. |
|
For this use case, is it not a minimal extra step? Just build your Blazor app, and within the same solution, add a MAUI project that targets it with BlazorWebView? Voila, you have cross-platform app as well as something you can host and serve over a web browser as well. I don't think it's a good idea to try to awkwardly map XAML into HTML (or let strange voodoo hidden from the user render it into a canvas) and a much more sensible option is to use an established templating engine like Jade that Blazor can already do. Otherwise, you'll just inevitably run into cases where you start wanting to know more about the actual markup and influence it when a complex interface doesn't automagically render into something you want via MAUI anymore. MAUI can then just say "No can do" and guide you towards a limited setof Stack Overflow XAML-wranglers. HTML and adaptive styling of it with accessibility etc. can get complex these days and then I think Blazor is a far more pragmatic approach that lets you actually work with what is being presented. |
|
@jonasnordlund no one tells you that you should not use HTML/JS/WebView/Blazor to make write-once-run-everywhere apps. Just you also do not stop us use XAML/C#/WASM to make write-once-run-everywhere apps. And then having both options let developers to choose between awkward solution to write desktop apps in web technology like HTML/JS (even it has fancy styling) vs. writing performant desktop apps in native technology like C# and only when needed extend them with no additional code and time to some side platform such as web. |
|
Hmm, I do not think I follow entirely here. The whole point of Blazor is to code mostly in C#/.NET and not Javascript. Blazor was designed from scratch to not feel awkward like HTML + Javascript. It’s supposed to be a cross-platform development model where you can fluently transition to the web without doing something very alien and disconnected. You can keep using Entity Framework Core on a Blazor backend etc. Blazor apps are also apps much higher performing than what “web apps on desktop” have unfortunately been known as due to Electron bulk where Blazor apps are much leaner. This can be seen in the “Teams for Home” app shipping with Windows 11 and with little in terms of warmup, and of course much less memory use than an Electron app. |
|
@jonasnordlund the key here is XAML vs HTML. There are many XAML/MVVM developers which do not use HTML/MVC as they write desktop and mobile apps. There are also bulk of existing XAML/Xamarin Forms apps waiting to be migrated to MAUI. In both cases extending to web would require rewriting if you use Blazor. Generally - what's the point to have new MAUI thing (including support of Xamarin Forms dialect of XAML) if you need to write all new apps to HTML and have XAML apps cut from web? |
|
I fully agree.
Blazor avoids us using JS, but still maintains the ballast of HTML5/CSS.
In my opinion XAML is by far more productive than HTML5/CSS.
…________________________________
De: Plamen Ivanov ***@***.***>
Enviado: miércoles, 29 de junio de 2022 00:28
Para: dotnet/maui ***@***.***>
Cc: rperazzolli ***@***.***>; Comment ***@***.***>
Asunto: Re: [dotnet/maui] [Enhancement] Web? (Discussion #62)
@jonasnordlund<https://github.com/jonasnordlund> the key here is XAML vs HTML. There are many XAML/MVVM developers which do not use HTML/MVC as they write desktop and mobile apps. There are also bulk of existing XAML/Xamarin Forms apps waiting to be migrated to MAUI. In both cases extending to web would require rewriting if you use Blazor.
Generally - what's the point to have new MAUI thing (including support of Xamarin Forms dialect of XAML) if you need to write all new apps to HTML and have XAML apps cut from web?
—
Reply to this email directly, view it on GitHub<#62 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFNYYC5BMSUB4D6CN332SG3VROKBTANCNFSM4TSO7IGQ>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
This! I honestly don't care about JS, my issue is HTML/CSS (divs, id, classes are unpleasant to use if you're from XAML) |
|
Check out more sample here for any .Net Projects including Avalonia. |
|
The issue #4528 got mentioned with the words
By @danroth27 at .net 8 preview 1 news articel on devblogs.microsoft.com |
|
Given mauis current state they need focus on getting it stable |
|
I'd be comfortable publishing my MAUI application not only to different OS but to the web too, especially if I am using MAUI.Blazor |
|
HI, Now with ChatGPT o3, can we think about making it quickly create handlers? |
|
Consider asking in this issue instead since that is the issue that gets the attention from the team. that being said „attention“ is a strong word, because as you will see from the last messages in the issue the question if there is anything new is unanswered from the team for 2 years, so yeah don’t get your hopes up to receive any answers from the team they couldn’t careless even if they tried… web seems to be a to small of a user base for the team to even bother answering questions /s |
|
Microsoft was giving money to these project and no one use this framework it feels like sometimes capitalism doesn't exist internally in cooperate and is overwritten by bureaucracy and abuses of power to me |
|
Hi guys, i made a project called Maui2Blazor. I think that the best way is to use .NET MAUI Handlers, as Android, iOS done, to reuse the almost code but is very complicated, for a single developer. The simple and fastest way for me a .NET MAUI mobile developer, was to port MAUI API to blazor web assembly, without references from .NET MAUI Packages, but ask to an' Artifical Intelligence to make a Button, Label, StackLayout as wrapper of html button, textarea, div and reuse all MAUI ViewModels and navigation style. The results was interesting, check it into this repository -> https://github.com/giuseppenovielli/Maui2Blazor The main cons that i have found are:
PS. This is an'experiment, feel free to fork, improve, edit, add code. |
|
Did you test this in a browser, or using Maui Blazor (an app)? Performance bottlenecks may be in different places in code, in those two environments. |
|
tl;dr I'd love to code to MAUI, and have that run awesomely everywhere, including browsers. @giuseppenovielli, I perused your Maui2Blazor. Seeing what you did, sparked a related idea for me. First my concerns:
So, turn it around. We desire a cross-platform UI without the pain of HTML + CSS. Let's treat HTML + CSS as the "assembly language". A much simpler task than making MAUI work well in wasm:
I'm going to fork Maui2Blazor, and make an initial stab at this. Test how the result works, both in a browser, and in Maui Hybrid. |
and others
Uh oh!
There was an error while loading. Please reload this page.
I guess I'll be the first to address the elephant in the room. Or rather the conspicuous absence of the elephant in the room:
What about web???
Since it's pretty clear Microsoft isn't going to pursue this (at least right now) the more relevant question is will something like my experimental XF renderer for Blazor still be viable with MAUI?
All reactions