Create a Ubiquitous .NET Client Application Development Model
This vote is for developers who wish to see the idea of a ubiquitous .NET client application development model created by Microsoft and the Visual Studio team.
A ubiquitous .NET client application development model is a model that is defined in .NET-based technologies and is able to run in a multitude of runtime environments -- both native-compiled (store-hosted) and web-hosted.
A *very* rough image of the vision can be found here:
The goal is to enable *one* .NET Client Application Project to build deliverables for the following platforms:
1) Windows 10
2) Legacy Windows
3) *nix (Unix/Linux)
8) ??? (Extendible to different, future platforms)
In order to achieve the above, a ubiquitous .NET client application development model should strive to possess the following qualities:
1) Native Cross-Platform Capable - For native-compiled/store-hosted scenarios (iOS/Droid/Windows Store)
3) Consistent User Experience - For brand recognition, reinforcement, and optimal usability across all known scenarios
4) Cross-Boundary Accessibility - For shared code/assemblies between server and client boundaries
5) Xaml-Powered - Harnessing one of the greatest inventions in Microsoft's great history
6) Object Serialization Congruence - Markup used to describe serialized objects is what is created in memory
7) Holistic Development Consistency - The same guidelines and conventions are used in both client and server scenarios
For more information around this idea and the qualities above, a series of articles has been created to discuss the notion of a ubiquitous .NET client application development model at length. You can view that series here:
Finally, this is intended to be a starting point for discussion, and not a final solution. THAT is meant for the experts there at Microsoft. :) Thank you for any support, dialogue, and feedback around this idea!
I appreciate your efforts, sir. I will also make effort to involve in the other location you pointed to.
So, in response to your latest feedbacks. I do think Xamarin.Forms supporting WebAssembly is enough. Rendering to the same usual HTML, CSS & JS, the other obvious option, is not actually a plus, cos it forfeits the essence of the native approach in the first place, even though I support that Xamarin.Forms should support the Web. WebAssembly is just enough to make things complete. A perfect cross-platform solution will not be easy to achieve. OK, what if we had more than Android and iOS to deal with? Wouldn't there be more platforms to target? Of course, yes.
For UWP, I do think that with the current amount of investment that has gone into it, if Microsoft should try to start over again with something else, it might finally make people forget about Windows development for good. It would likely be a disastrous move for Microsoft. I bet Microsoft will not try that but to simply keep enhancing UWP to become better.
I have used WPF (few years after it was released and got more stable and accepted) and UWP. Being that I do appreciate UX and UI responsive design, the first thing I instantly noticed about WPF is the flexibility of XAML in achieving a great UI design. But then, I noticed the serious absence of responsive design capabilities. Then came UWP eventually to take care of those areas. Business logic didn't change much. UWP XAML, even though differently intentioned, is still better at doing modern UI design than WPF XAML.
Btw, making WPF to run on mobile devices was going to be harder than UWP. Because if Microsoft hadn't done something about a unified Windows development, people would have complained too.
What makes the Web better today is with the introduction of true responsive design and adaptive design capabilities. Much of the development in the Web arena have been about the UI in a long time and much less about JS until more recently.
UWP vs WPF is a tough one. UWP can only become problematic when things get really complex, and if examined carefully, bad application-wide design approach is mostly to be blamed. These days, there are various ways to implement application design in a more modern way and things don't have to be done in old ways.
One other issue I had with UWP was not being able to easily use SQL Server with it, and that has now been taken care of, even though SQL Server data could be accessed over APIs or over a network. But if examined critically, it wasn't a real problem if one could only think in a more modern way. SQLite was just OK for the client in the more connected world of today, unlike when computers were more independent like in the early days of WPF era. Most times, it's an app design/architecture issue.
I recommend that we should all help UWP to succeed. And ensure that we contribute towards Xamarin.Forms achieving WebAssembly capabilities.
I guess we do care about Microsoft.
BTW @Olumide I super appreciate your line of thinking in providing potential solutions. Please do not think that I do not find them valuable with my line of questioning. If you want to join the discussion there on that Disqus thread it is a better way of posting comments and I can upvote them, too. :)
@Olumide. Have you tried Xamarin.Forms? It's not very well liked or broadly used, mostly because it's very difficult to use and has fundamental architectural/design issues (not to mention INCREDIBLY buggy -- but this is getting better). For one, if you have a custom renderer for a control, you must make that renderer for each platform you wish to support. So if you also include web as you are suggesting, you could end up creating four custom renderers for each control. Hardly viable.
When you say XF is closer to the web, we should ensure that you mean that it LOOKS closer to the web. XF has NO plans to become web-based technology, save for WebAssembly when it reaches RTM (but when? this is still a risk).
Also, have you actually tried to make a UWP application vs. a WPF application? Have you encountered an error in UWP? And then tried to find out more context around that exception on StackOverflow? If you haven't, give that a whirl before suggesting that UWP should be promoted in any capacity. There is also the HUGE issue with the Xaml model which I can't even begin to get into it here.
At the end of the day, the best thing that could possibly happen is the .NET/Core group to assimilate the UWP group, hopefully gutting all its management in the course of doing so.
BTW I am wrecking shop on this very topic here, if you are up for some good reading/discussion:
@Mike-EEE @Marc Roussel
Thanks for the feedback.
I still have the following to say..
Xamarin.Forms is still the right candidate I suggest for whatever cross-platform endeavour that Microsoft does. Even now that CSS is a part of the tooling for Xamarin.Forms, it's closer to the Web than ever. In the end, it's essentially all about UI and backing business logic.
UWP must stay unique so that it can evolve even if other platforms happen to not evolve or evolve in different directions.
Also, the Web should not be helped by any native platform. All that have tried it essentially failed (e.g. Silverlight and Flash). TypeScript is still the wisest of them all because it's very compliant with the present and future plans of web standards. UWP will fail if it tries to satisfy the Web. WPF's XBAP essentially failed. Enough lessons learned there. Even Java failed to reinvent the Web. All of them who didn't abide by web standards failed.
So, my recommendation is that Xamarin.Forms should be Microsoft's cross-platform effort. It's not uniquely about sacrificing Xamarin.Forms for that course. Xamarin.Forms should simply maintain compliance with the current state of the technologies it's rendering to. It shouldn't move faster than them, especially the Web.
Also, Microsoft should implement Visual Studio in UWP and forget WPF. They should create new ways for UWP to be as ubiquitous as WPF have been. Now, there's an upcoming feature that will enable multi-instance running of UWP apps on Windows. Things are happening, but until Microsoft implements their own serious apps, especially Visual Studio in UWP, people will find it difficult to take them seriously. It is doable. In the end, it's basically about the UI and the backing business logic.
So, Xamarin.Forms is the best logical bet if Web development is also to be in Microsoft's unified cross-platform effort. No need for a new drastic change.
Also, for people who hate to design the UI, i.e. people who honestly but wrongfully think UI designers are irrelevant, Microsoft should make more effort to make the Windows Community Toolkit more featured so that UI designers can have a new place for creating customizable UI controls for people who hate to do UI design, and Xamarin.Forms should have something similar for it too. Google is already doing something similar with the much acclaimed Material platform (which I actually had thought would eventually become more like the CSS Bootstrap that web designers use), because they realized that every app began to look the same.
This issue is not that complicated.
Marc Roussel commented
@Olumide If I may add to that, at the beginning we had one code base, VB then VB 6 following by VB.NET and 90% of these coders switched to C# and I don't want to argue here about syntax but let stick with C# as a major player. We were all happy in our happiness but something was missing. The whole Windows development wasn't working on the WEB then came an unpredictable thing we welcomed so well : Silverlight. All developer were in extreme joy. Suddenly we reached a canyon and felt in it (without dying of course) and now we are at the bottom wondering how to go back up. Meanwhile at the bottom, many dyed of starvation and the rest of use that still struggle with many syntax and poor foundation which result in a long development process are waiting for a rope or a ladder to help us regain what we had at the top of a canyon which is getting deeper with time.
I appreciate that you appreciate, @Olumide. :D Thank you for that.
Unfortunately, if you are not aware, the Xaml Standard is dead. UWP group simply does not play well with others, or at all for that matter. UWP has hijacked Xaml and for whatever reason someone continues to allow their questionable management maintain power despite the fact that they are the primary reason Windows has lost its relevance during the past 5 years. More "discussion" here: https://github.com/Microsoft/xaml-standard/issues/230
(I denote "discussion" because all of "management" has abstained from any communication with the members they have been delegated to serve. Perfect example of UWP at "work.")
I especially like the "new" XamlDirect "feature", which is basically a wrapper around System.Activator... a nifty class that has been around since v1.0.
Also, I respect and understand what you have to say about the web. It *IS* the common denominator. Taken in the context of a few more years, however, it will be even closer to native technologies than what it is today.
ALSO consider (in my opinion) that "amazing" applications really do not need that much technology to be amazing. I am more of a minimalist in my style, however. I think less is more. If you are looking for super graphics intensive power and/or a game, you are 100% correct. However, for about 95% of LOB's out there (Windows Forms, even), the web currently has you covered.
The issue of course is that it is a total pain to work with, especially when .NET is involved, and that is what we are aiming to fix here.
First off, I appreciate your work here and everywhere, sir.
I checked the link. But no matter how productive and efficient it can be to satisfy the Web by compelling native platforms, a truth is that the front-end Web will keep being the one to slow others down. Against my deepest wishes, I see a future where the front-end Web, albeit advanced enough too, would only keep being a common ground and/or interface between various proprietary and public technologies but where no one will be willing to wait for the front-end Web to match up.
If we examine things critically, so far, the front-end Web has slowed down innovations. With time, other platforms are going to be evolving really faster than the front-end Web can catch up. There are many features on native platforms now that the browser and Operating Systems (OS) built on the front-end Web will not match in a long time, or that it will struggle to match.
Web Assembly will do a lot but it will possibly not catch up with native platforms because of the limitations of the browser, even though it can be made to run elsewhere.
In the end, a way forward I see here is to see the outcome of the XAML standard, and also let Blazor and ASP.NET Core keep doing their thing to satisfy the Web. With Blazor, .NET developers won't need much of all the complicated front-end Web framework fragmentations (i.e. Angular, React, etc.).
We have to let Xamarin.Forms keep trying its best with being cross-platform. And let the precious UWP keep evolving to great extents, even beyond Xamarin, which brings me to why I sometimes think that the XAML standard is not necessary because it's unlike how HTML emulates XML and its predecessor(s) by simply respecting their syntax and stuff but not like the XAML standard is intended to be a word-for-word unification of XAML for both UWP and Xamarin.Forms, which I think is going to hinder the growth and evolution of UWP.
I believe that Microsoft cannot afford to comform their native platforms to the limitations of the Web. It's dangerous for innovation. So, we should try to live with having Blazor & ASP.NET Core, Xamarin.Forms and UWP if we want to give room for great innovations to happen.
Sounds good but its not that simple, all MS controls are inside the OS not in .Net or in Was.
My favorite solution would be to:
1. Have .NET Core 3.0 working in WebAssembly, excluding the subsets that need system services like File IO.
2. Complete open source WPF so that the DirectX layer can be replaced with WebGL or OpenGL equivalents.
Xamarin can be and is already being used for this. Microsoft cannot/will not/should not do this using the main proprietary platforms, e.g. Windows UWP, for example, which is bound to evolve in a direction that other non-Microsoft platform may not.
Xamarin is enough to sacrifice for the cross-platform course.
Xaml sucks, so no.
@Mike-EEE I asked friends and colleagues to vote because of this announcement:
Hope it can bring change.
Suddenly we're only 300 votes away from 10,000... did something happen or something? An event or something? ;)
exactly what standard do you have in mind? please don't tell me Java, we've seen what Google did with Android, they're still fighting on this with Oracle in courts
If you want compatibility, there's .Net for that. Muddling with .NET Core cross-platformness will just taint its reputation. Younger programmer might not know what Microsoft did in 1990s but I remember when they lie to us about "embracing" such standard just to muddle with it later on.
on the contrary, it's very good news: the power of Microsoft was all these years that they'd strive for backwards compatibility and interop with older tech (can still run Win16 in 32-bit Windows for example and would hope they also had it in x64 since there are some nice older 16-bit educational apps that need a VM to run), not ditch a technology for the latest trendy stuff and tell you to write all your stuff from scratch
btw, interesting reading on what happens at the world of trendy that's called web development currently:
I feel pessimistic after their most recent announcement on .NET Core 3 and Support for Windows Desktop Applications. Seems like Microsoft is reverting back to their old embrace-extend-extinguish behavior...
FWIW we're discussing the dumpster fire of Xaml Standard and //build 2018 here (skipping to an interesting post, if I do say so myself):
Worth an investigation: http://platform.uno/