6 ms·

This post actually highlights more of XF's downfalls than positives. I've been a big XF developer for years, and XF has many positives but this example just sho

This post actually highlights more of XF's downfalls than positives. I've been a big XF developer for years, and XF has many positives but this example just shows that they needed SkiaSharp, Lottie, and native platform code just to get their app out. Not to mention the need for additional components such as horizontal scroll, carousel view etc. If you look at Flutter, most of this app could be done with just the Flutter SDK. Haven't really played much with RN, so not sure how that compares.

jamesg 8y ago
That's fair, but I think that XF has a good story around integrations with other frameworks to fill its gaps: SkiaSharp has the SkiaSharp.Views.Forms namespace, for instance, and there's solid documentation on integrating the two, right there on Microsoft's Xamarin.Forms docs. Actually, speaking of docs, Charles Petzold's book on XF is an awesome resource -- I've not seen commensurate investments in documentation made by XF's competitors (admittedly it's not something I track that closely). Similarly XF's ability to add a native control directly to a StackLayout via extension methods makes it fairly straightforward to just drop in a native component if that's what you want to do. I think it's a reasonable strategy to say "hey, we're not going to be able to solve all the problems, and it's probably not the right way to spend our time even if we could. What we will do is make integration with other solutions straightforward so we're not the bottleneck". Making a strategic choice not to be the bottleneck seems like a good call regardless. That said, the things I've found to be a hassle are things like getting OpenGL working on UWP from C# (tractable, but that's really not how I want to be spending my time). But yeah, wow what a difference it's made having Microsoft throw their resources at it. My current codebase lets me build for iOS, Mac & UWP at present (I'll get to Android at some point), with really not very much effort. Being able to debug on the Mac version rather than waiting for iOS deploys is just about enough to repay the time investment on its own. I'm anxiously awaiting them getting their web platform support up to snuff -- I'd dearly love to never have to JavaScript again. :)
pjmlp 8y ago
On the other hand this app would work across desktop OSes as well, whereas Flutter not, as it isn't their focus. Given past experiences, I am sceptical of using languages not part of platform SDKs for production code. When I do use such third party languages then the eco-system plays a major role in the decision, and for .NET vs a language clinging for survival, the decision is obvious if I care about having the same code in production in the next couple of years.
- apedley 8y ago
  I understand the need for some apps to work on desktops, but I haven't personally done any of these before. Just iOS and Android, is all clients ever seem to ask me. So of course Flutter wouldn't work well for desktop atm. But FYI: it is being looked at - https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding Even seen an MS employee contributing to it as well. As for Dart, its similar to C# in a lot of ways and certainly is gaining traction. I didn't have any difficulty writing Dart code.
  - pjmlp 8y ago
    Dart might be similar to C# in syntax, it just has like 1% of libraries available to C#, no IDE support at the same level as C# and no commercial value to put on the CV. When comparing programming languages one always must look beyond grammar and language semantics. Flutter is trying to be Dart's Rails, it remains to be seen if it will actually accomplish it. How are pure Ruby projects doing in the market outside plain Rails apps?
rogihee 8y ago
The next step in my view is the addition of quality components to the Forms base, and they are doing just that at the moment. I have reviewed and given input for CollectionView, FontIconSource and other specs that are actively being worked on. I saw Miguel demo-ing my input in .NET Conf in the demo Shell app, so they are listening! You did a few stellar Pull Requests yourself, with the Label Spans. I took them a long time to restructure the project after Jason Smith's leave of absence, but I think David Ortinau is doing a stellar job and the GitHub project is an exemplary open source project. It needs more community involvement, and the F100 stuff you helped drive was very, very good. Next to better components and adding more resources this is another challenge for the project at hand. I agree it is a bit of a Linux on the Desktop story, "next year", but taken the task at hand (so many platforms), the pace is not that bad. In the mean time I can produce good apps with a few extra libraries, so what...
- apedley 8y ago
  Its great they seem to be listening to you, they never really listened to me. F100 was brought about because they weren't listening, and the community had to do things they wanted because Xamarin weren't ever getting around to it. I put a lot of effort into XF, and at the time, it was the best x-plat development environment (for my usage) around. But Flutter has really highlighted its shortcomings and I don't hold much faith that Shell is going to bring it to the front again.
skrebbel 8y ago
> downfalls > SkiaSharp, Lottie, and native platform code So a healthy ecosystem and easy bridging to native is now a downside? This is like blaming React Native for having a useful ecosystem of components.
- apedley 8y ago
  A healthy ecosystem and easy bridging to native isn't a downside at all. But this article is saying look how awesome XF is at all these pretty animations and functions, which are mostly done by other components or custom native code. And they aren't quick and easy to implement either. But you then compare it to Flutter, and you could do most of it right off the Flutter SDK. To me it highlights where XF lacks in a cross platform development. Especially when you think of the knowledge you have to know to bring in to use all these components. ActionScript, Skia, and each platforms native API usage.
zerr 8y ago
Or in Delphi/C++Builder using FireMonkey framework, especially after they introduced community editions.

jamesg 8y ago

That's fair, but I think that XF has a good story around integrations with other frameworks to fill its gaps: SkiaSharp has the SkiaSharp.Views.Forms namespace, for instance, and there's solid documentation on integrating the two, right there on Microsoft's Xamarin.Forms docs. Actually, speaking of docs, Charles Petzold's book on XF is an awesome resource -- I've not seen commensurate investments in documentation made by XF's competitors (admittedly it's not something I track that closely). Similarly XF's ability to add a native control directly to a StackLayout via extension methods makes it fairly straightforward to just drop in a native component if that's what you want to do. I think it's a reasonable strategy to say "hey, we're not going to be able to solve all the problems, and it's probably not the right way to spend our time even if we could. What we will do is make integration with other solutions straightforward so we're not the bottleneck". Making a strategic choice not to be the bottleneck seems like a good call regardless. That said, the things I've found to be a hassle are things like getting OpenGL working on UWP from C# (tractable, but that's really not how I want to be spending my time). But yeah, wow what a difference it's made having Microsoft throw their resources at it. My current codebase lets me build for iOS, Mac & UWP at present (I'll get to Android at some point), with really not very much effort. Being able to debug on the Mac version rather than waiting for iOS deploys is just about enough to repay the time investment on its own. I'm anxiously awaiting them getting their web platform support up to snuff -- I'd dearly love to never have to JavaScript again. :)

pjmlp 8y ago

On the other hand this app would work across desktop OSes as well, whereas Flutter not, as it isn't their focus. Given past experiences, I am sceptical of using languages not part of platform SDKs for production code. When I do use such third party languages then the eco-system plays a major role in the decision, and for .NET vs a language clinging for survival, the decision is obvious if I care about having the same code in production in the next couple of years.

apedley 8y ago
I understand the need for some apps to work on desktops, but I haven't personally done any of these before. Just iOS and Android, is all clients ever seem to ask me. So of course Flutter wouldn't work well for desktop atm. But FYI: it is being looked at - https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding Even seen an MS employee contributing to it as well. As for Dart, its similar to C# in a lot of ways and certainly is gaining traction. I didn't have any difficulty writing Dart code.
- pjmlp 8y ago
  Dart might be similar to C# in syntax, it just has like 1% of libraries available to C#, no IDE support at the same level as C# and no commercial value to put on the CV. When comparing programming languages one always must look beyond grammar and language semantics. Flutter is trying to be Dart's Rails, it remains to be seen if it will actually accomplish it. How are pure Ruby projects doing in the market outside plain Rails apps?

rogihee 8y ago

The next step in my view is the addition of quality components to the Forms base, and they are doing just that at the moment. I have reviewed and given input for CollectionView, FontIconSource and other specs that are actively being worked on. I saw Miguel demo-ing my input in .NET Conf in the demo Shell app, so they are listening! You did a few stellar Pull Requests yourself, with the Label Spans. I took them a long time to restructure the project after Jason Smith's leave of absence, but I think David Ortinau is doing a stellar job and the GitHub project is an exemplary open source project. It needs more community involvement, and the F100 stuff you helped drive was very, very good. Next to better components and adding more resources this is another challenge for the project at hand. I agree it is a bit of a Linux on the Desktop story, "next year", but taken the task at hand (so many platforms), the pace is not that bad. In the mean time I can produce good apps with a few extra libraries, so what...

apedley 8y ago
Its great they seem to be listening to you, they never really listened to me. F100 was brought about because they weren't listening, and the community had to do things they wanted because Xamarin weren't ever getting around to it. I put a lot of effort into XF, and at the time, it was the best x-plat development environment (for my usage) around. But Flutter has really highlighted its shortcomings and I don't hold much faith that Shell is going to bring it to the front again.

skrebbel 8y ago

> downfalls > SkiaSharp, Lottie, and native platform code So a healthy ecosystem and easy bridging to native is now a downside? This is like blaming React Native for having a useful ecosystem of components.

apedley 8y ago
A healthy ecosystem and easy bridging to native isn't a downside at all. But this article is saying look how awesome XF is at all these pretty animations and functions, which are mostly done by other components or custom native code. And they aren't quick and easy to implement either. But you then compare it to Flutter, and you could do most of it right off the Flutter SDK. To me it highlights where XF lacks in a cross platform development. Especially when you think of the knowledge you have to know to bring in to use all these components. ActionScript, Skia, and each platforms native API usage.

zerr 8y ago

Or in Delphi/C++Builder using FireMonkey framework, especially after they introduced community editions.