Goodbye Xamarin Forms
itnext.io
itnext.io
I use a 3.4 GHz Quad-Core i5 iMac with 24 GB of memory. Storage is a Fusion Drive. On this configuration Visual Studio often slows down to a crawl doing whatever it does.
I've recently switched to JetBrains Rider [0] and the experience is so much better. Rider never slows down for me. Occasionally the debugger disconnects, but just closing and re-opening the project fixes this issue most of the time. The key binds take a bit of getting used to.
To improve my experience in Visual Studio the few times that I am forced to use it, I'm moving my view code mostly to C# files (not making use of XAML anymore). Since the XAML editor is also very often slow to autocomplete and such in Visual Studio.
So with Rider, I now have a good experience. Sadly Rider is not free, but it's also not very expensive and my developer experience has improved in a big way. Rider also gives much better advise for refactoring, which is also a nice bonus.
---
I think Visual Studio just kinda sucks in general. It's bloated and clunky and its editor feels incredibly dated.
Unlike Uno, it does not rely on native controls and does its own rendering.
Having now used multiple of these cross platform frameworks (Xamarin Forms, Flutter, Ionic) frankly I'd just write the UI for each platform separately and use native design tools, using common C# library for business logic.
Otherwise use Ionic/WebView if you don't care about result quality and need fast development, you'll knock out a web UI faster than anything, every front-end dev can do web, plenty of design tools, designer workflows.
Since WinUI 3 is multiplatform (in conjunction with the first party Linux/Android and OSX/iOS support in .Net 5 and 6, and with MAUI), Uno no longer needs to exist outside of dealing with legacy UWP code (which, as per Microsoft rules, shall never die).
Also, re: web UIs, I hate to inform you, but everyone hates these. They are slow, clunky, optimized for all the wrong things, inconsistent, and sometimes ugly. The move to HTML canvas-based UIs in otherwise native apps Android and iOS is why most apps on phones are slow, even though a purely native one would have been fast on an ancient phone. Please do not repeat this mistake.
If you care about user experience - writing it for each platform would have ended up being faster in the last app I did with flutter - so many subtle things that dragged the development out for weeks where as native had all these things working out of the box. I haven't worked with Xamarin in a while but I remember the quality was the worst out of all solutions I've used. So many moving parts, "this works in the latest version" and then half of other dependencies haven't been updated, and you just said the same thing.
Hm? I thought MAUI was the multiplatform UI toolkit and WinUI 3 was the native Windows 10 UI toolkit (evolved from UWP) repackaged for bundling with each app?
I hope I do not destroy the dreams of someone.
You kinda did. :)
I was trying to grok the point of Uno if WinUI was truly multi-platform in the MacOS/Linux/Android/iOS sense.
Flutter would have been a much better framework if it was built on typescript
Whatever Uno is supposed to be, I was very disappointed
Argument about UI is also suspect. Forms gives a lot of customization control, and with the new material visual you can get a good cross-platform material design. Personally, I think Material is ugly, but it isn’t exactly uncommon these days.
At this point I also hate Xamarin.Forms, but I like Uno even less, mainly because it is built off the absolute abomination that is UWP. (Heads up: it renders paths/SVGs even worse than WPF). If you are a .NET developer, you do not want to explore the mess of buggy controls, COM threading issues and old Silverlight help pages that is UWP. Yes, when you sign up for UWP, you are signing up for an immature wrapper over COM.
But a few weeks ago, Google humiliated me by removing my app from the store with no prior warning(it is back now). This has led me to explore building the app in WASM. Today, I have finally verified that the app's core functionality runs faster on a browser than on native Android or iOS
The author has a point that Android support has always lagged iOS support, but I've not had problems to the point that they have. Xamarin is great for business apps, and can definitely be performant on both platforms.
MAUI was promising to become such a thing [although MS themselves are being a bit non-committal about Linux], but should I be wary of the bigger architectural picture?
You shouldn't be wary realistically because Microsoft has spent almost a decade grinding away at something that needs to exist for both Windows to survive, and for Microsoft to stay relevant in app design. The existing code that makes WinForms, WPF, and WinUI 2 apps (the API in UWP) also has been reused or extended by WinUI 3.
Microsoft just wants app development not to suck. They designed C# for a post-Java world for this goal, they rebooted Visual Studio years ago for the C# era to achieve this goal, they took XML out of the places it didn't belong and put it into the places it did belong (ex: XAML, for actual real document-style code autogeneration) for this goal, they switched to Git to handle their famous monorepo to accelerate development of Windows, they bought Github because of how much they used it internally (and made their job so much easier than their kinda shitty internal mixed heritage VSS quasi-fork), and they're one of the largest users and committers of the Linux kernel itself and would love if they could run their own modern MDL2/Fluent(=MDL3) apps on Linux natively.
.NET has long been rock solid in C/C++ <=> .NET transitions and WinRT <=> .NET transitions. (System.Windows.Forms does a ton of it and .NET 5 seems to have the expected performance from all those transitions.) The new interesting transition that it is still too early days to tell how well it will perform is the new .NET approach to Objective-C <=> .NET transitions/projections (which is more like the modern WinRT projection techniques) that is also different from the Objective-C <=> Mono transitions in Xamarin.Forms. (Though the article points out that the Objective-C <=> Mono transitions were fine and the new .NET approach on paper should be even better.)
Also, from what I was reading, a modest version of the architecture change that the article was lamenting needed to happen to reduce Java <=> Mono transitions in Xamarin.Forms is supposedly happening in MAUI and they were trying to reduce the surface of "managed Renderer" code that transitioned in/out of OS level services. I don't know if what they are doing would be enough to satisfy the article's writer, but it apparently has been something on their radar.
C# also comes with Visual Studio, which can be used in the free version with teams of up to 5.
I myself barely used it either though, most of my development is in java, JS/TS and python.
No thanks. Why would you build with a tookit from a vendor that has such a history of abandonware?
I really dislike this name overloading. It hampers search. It adds no value. It leads to name clashes.
I much appreciate unique names without much pre-loaded meaning, like Google, or Kodak, or Inkscape, or Linux, or Debian.
Apparently coming up with such a name is hard, though, especially because of a desire to come up with an excellent pun / acronym, and because of the corporate desire to play safe and use a tried name.
It falls short of fixing the issue.
We need to make web open to technologies beyond the legacy stack.
XAML? no thanks