[oblio]

Eto is very interesting but unfortunately there seems to be just 1 (very active) developer behind it, from what I can see.

On the other hand, Xamarin.Forms had an announcement recently, an announcement that Hacker News missed. I submitted the news a few days ago but it didn't reach the first page:

https://news.ycombinator.com/item?id=14383467 ->

https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/

TL;DR:

Xamarin.Forms will support desktop environments:

- Windows (WPF)

- MacOS (Cocoa)

- Linux (GTK#)

This is on top of the mobile bits: iOS, Android, UWP.

As an added bonus, they've added Xamarin.Forms embedding into native interfaces.

It's actually major news since Xamarin.Forms would become the first cross platform UI toolkit that:

1. supports both desktop and mobiles

2. is backed by a major vendor

3. is truly usable from a memory managed language as part of the core offering

[clintcparker]

Great call out. Also, Xamarin Forms should be even more useful when XAML Standard drops.

https://github.com/Microsoft/xaml-standard

[roryisok]

Xaml + .net core would surely be an electron killer

[maxxxxx]

I have never heard anything positive about Xamarin.Forms from people who have used it. Has this improved?

[tluyben2]

It has improved. It works well for a lot of use cases. And if you want to have a platform more focused you just make custom renderers for those elements. It is not for everything but especially if it will support more platforms it will be very interesting for LoB apps.

[king_magic]

I use it a fair bit, mostly for enterprise apps. It definitely has its quirks but overall it's come a long way.

All depends on how polished your UI needs to be. Anything too polished and you're better off going straight Xamarin or pure native.

[kevindqc]

I've never used Xamarin, but I'm curious what their complaints are?

[devopsproject]

To be clear: "Xamarin.forms" is different than "Xamarin" and the following is based on my experience with "Xamarin.forms".

Also note that my experience with this is building an extremely simple business-y app for internal users.

1. Its moving fast so documentation is lacking and the "right" way to do something, posted 6 months ago, is wrong\deprecated\wonky

2. The tooling leaves a lot to be desired. Although this has greatly improved, there are still tons of steps to publish (https://developer.xamarin.com/guides/android/deployment,_tes...).

3. Updates constantly breaking things. To be fair, this is also improving

4. There may still be instances where you have to drop into native code or split code based on platform. This means you sometimes will need to know: c#, xamarin.forms oddities, java\android stuff AND objective c\iOS. This may not be an issue for simple apps

5. UI builder is limited. The apps will be native looking but you won't be winning any design awards. Some things also seem impossible so it helps if the customer\designer\stakeholder is really flexible. If someone asks for an app to collect and display data, you will probably be ok. If they give you pixel dimensions and other minutiae run.

[badprose]

I don't know that people missed it, or we're still suspicious of "one UI framework to rule them all"...

[oblio]

The major factor is obviously the fear of Microsoft lock-in, I think. Which is reasonable.

If it's more about the technical details, such as general issues regarding cross platform UI frameworks, I think we're way past that point considering HTML5/Js :)

[pjmlp]

Every single time I am forced to do web development, I miss such frameworks.

[roryisok]

What does that mean? The web is already cross platform, that's kind of the whole point

[pjmlp]

It means the Frankenstein of CSS/JavaScript/HTML tooling, still catching up with the 4GL RAD tooling of the 90's, or expressive native environments like Microsoft Blend, iOS and Android native layout managers.

Or the lack of integration with native animation frameworks, widgets, behaviours and system APIs, even with HTML 5.

Or hacks like Service Worker with in browser database, to be able to write offline apps, something that just works out of the box in native apps.

[j_s]

Right now, it's only on the roadmap.

[zerr]

Well, there is Qt/QML, and if the price is not an issue - Embarcadero FireMonkey.

[revelation]

There is Qt Widgets (yay for HiDPI).. everything else is one big garbage fire. I recently launched a QML Quick Controls 1/2/+inf/who knows app and trying to select text in an input box caused it to switch tabs because that's what caught the events. It was impossible to select text.

I get now why people use Electron. It's 2017, Qt has been around forever, and they still haven't figured out the fricking deployment issue! You still have to cobble together a bunch of scripts and otherwise crappy solutions to get something that runs on Linux/Mac/Windows in any shape or form that approaches "out of the box" and "continuous integration".

[floatboth]

Yeah QML has one big problem — it only supports integer scaling for HiDPI. Have these people ever seen a fucking 28 inch 4K display?!?! I NEED 1.5x SCALE. 1x looks extremely tiny, 2x looks comically huge.

[oblio]

Oh, if you think that's painful, try to see what happens when you're targeting mobile.

If you want extra layers of pain, try to use any of the Python bindings for Qt on mobile :D

[simonh]

I've never had any problems getting my PtQt and PySide apps working on Windows or Linux. OSX on the other hand, yep, dumpster fire.

[vintagedave]

I'd say FireMonkey too. ARC-based language, long-standing vendor, FMX is a very nice toolkit (runs on the GPU, vectorised, skinnable, has native widgets.)