3 ms·

Uno is a really interesting approach to writing cross-platform UIs. It's interesting that they basically have a native implementation of say Button for every pl

Uno is a really interesting approach to writing cross-platform UIs. It's interesting that they basically have a native implementation of say Button for every platform. This might lead to a unified style across platforms but as it does not use the same rendering logic/code on every platform I'd doubt that it's pixel perfect. Building a text editor would probably expose a lot of these close but not similar scenarios. On the other hand this adds the benefit of getting native behaviour of text boxes maybe ? Avalonia on the other hand does custom rendering using Skia and therefore really has pixel perfect rendering across platforms. This also means that it does not use the native controls and behaviour differs. If I had to write a cross platform app (and had the budget) I would probably use Xamarin and just write platform specific UIs. If there are heavy UI components these could still be shared. If on a budget something like this seems fine. Would probably go with avalonia UI tho tbh.

octopoc 6y ago
Here are some differences I was able to find: - Uno uses the UWP API and XAML, whereas Avalonia uses a derivative of WPF - Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think) - Uno is based on WinUI, so in theory WinUI components should be usable in Uno apps - Uno supports WebAssembly, but not Linux and MacOS natively Links: - https://github.com/unoplatform/uno/issues/17 https://github.com/unoplatform/uno/issues/17 - https://github.com/AvaloniaUI/Avalonia/issues/587 https://github.com/AvaloniaUI/Avalonia/issues/587
- oscargrouch 6y ago
  > - Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think) This line remembers a constant pitch i see here on HN, where people ask for native controls to be rendered for multi-platform UI sdk's that i think go on the "faster horse"(Ford) sort of misdirection. The problem with the 'faster horse' paradox is that the only way to make people forget about wanting a faster horse is by showing them the car. I think a platform like Flutter get this right, as do HTML/CSS/JS, because theres no way to get really consistent if you have to use the platform native controls. It will also be messy for the developers, requiring a lot of effort and money to make things partially right. I bet with you that most of these people asking for this use a Mac, and while Apple is more or less half of the market of US, in the rest of the world Apple have much smaller deploy base. So sometimes, you need to be careful because even HN can suffer from a bubble social effect, that will misguide people that actually listen what they are asking for. In the long term there's already a multi-platform UI paradigm there is set to win, and its called HTML.. Native UI platforms had a sort of comeback because of the iphone revolution, but in the long term, they will not be the winners, because Apple is doing the same mistakes they did in the eighties.

octopoc 6y ago

Here are some differences I was able to find: - Uno uses the UWP API and XAML, whereas Avalonia uses a derivative of WPF - Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think) - Uno is based on WinUI, so in theory WinUI components should be usable in Uno apps - Uno supports WebAssembly, but not Linux and MacOS natively Links: - https://github.com/unoplatform/uno/issues/17 https://github.com/unoplatform/uno/issues/17 - https://github.com/AvaloniaUI/Avalonia/issues/587 https://github.com/AvaloniaUI/Avalonia/issues/587

oscargrouch 6y ago
> - Uno renders using the underlying platform, uses native controls whenever possible, particularly for input controls. Avalonia focuses on using its controls, not native ones (although support for native controls is WIP I think) This line remembers a constant pitch i see here on HN, where people ask for native controls to be rendered for multi-platform UI sdk's that i think go on the "faster horse"(Ford) sort of misdirection. The problem with the 'faster horse' paradox is that the only way to make people forget about wanting a faster horse is by showing them the car. I think a platform like Flutter get this right, as do HTML/CSS/JS, because theres no way to get really consistent if you have to use the platform native controls. It will also be messy for the developers, requiring a lot of effort and money to make things partially right. I bet with you that most of these people asking for this use a Mac, and while Apple is more or less half of the market of US, in the rest of the world Apple have much smaller deploy base. So sometimes, you need to be careful because even HN can suffer from a bubble social effect, that will misguide people that actually listen what they are asking for. In the long term there's already a multi-platform UI paradigm there is set to win, and its called HTML.. Native UI platforms had a sort of comeback because of the iphone revolution, but in the long term, they will not be the winners, because Apple is doing the same mistakes they did in the eighties.