Show HN: Cross Platform .NET Desktop Application Framework | Hacker News Reader

Show HN: Cross Platform .NET Desktop Application Framework

browseemall.com

129 pointsAlikhanPeleg49 comments

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

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

Right now, it's only on the roadmap.

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 :)

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

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

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.

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

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

Xaml + .net core would surely be an electron killer

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

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

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.

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.

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.

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

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".

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

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.

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.

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.)

Apparently this is a hot topic.

The options I'm aware of are:

https://github.com/picoe/Eto (OP - BSD)

https://github.com/AvaloniaUI/Avalonia (MIT)

Currently only with a preview for Mac, Xamarin.Forms is roadmapped for desktop platforms "Q3 2017": https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/

Licensing for Xamarin Forms was funky for a while (required paying for Xamarin prior to MS acquisition) but appears to be MIT now.

And for games, there's MonoGame.

http://www.monogame.net/

It's based on the old XNA framework. At least one successful commercial game (Fez) was written with it.

Quite a few successful games were written in it, before Unity changed their license model.

Bastion was another one that comes to my mind.

As additional remark, indies have been doing games in C# since the Managed DirectX days.

Also, Unity is more a tool for designers, while MonoGame or LibGDX are more coding oriented libraries.

Kind of agree, but if you look at the curriculum of universities teaching game development degrees, they have all moved into Unity/Unreal, plus the console SDKs.

Also the love they are getting from MS and Google for VR/AR.

This is a hot topic? Not so sure.

Either that or someone figured out how to beat HN's vote ring detections to hit #4+ on HN for 2 hours, no?

http://hnrankings.info/14409553/

Given the title, it seems that this should rather link to the framework itself (https://github.com/picoe/Eto).

Yes template would be more descriptive.

You can mail the mods at hn@ycombinator.com to have the title fixed.

Or even the blog post about the framework (https://www.browseemall.com/Blog/index.php/2017/05/23/creati...).

Thanks, we've updated the link from https://bitbucket.org/positionfixed/crossplatform.

It can't since the authors of the post are not the authors of the framework. Title should probably say template or something to that effect.

I'd be wary about investing too much time into something like this. Microsoft is making a massive push with .NET Core and its availability on both Mac OS and Linux. Coupled with the expansion of the .NET Standard to encompass more of the .NET Framework APIs, it won't be long now before Microsoft announces the ability for the Universal Windows Platform to run on all major operating systems. Of course they may want to rename it to something more friendly - like Univeral .NET Platform, or just Universal Platform - but I suspect we'll see this in the next year or maybe two.

Build apps for Windows, OS X, Linux, Android and iOS with C# and XAML. Sounds pretty cool to me. So it isn't to say this isn't a great idea by the BrowseEmAll devs, but I'm just not sure how needed it'll be once Microsoft steps in.

Yeah, I felt that trend too with XAML Standard.

I carry this file around to detect platforms with .NET:

https://github.com/SirCmpwn/TrueCraft/blob/master/TrueCraft....

I hereby release it into the public domain.

Kudos for releasing to the public domain, but you should also attach a license to it (MIT is good)

Edit: sorry, I see there's a top level license. Browsing github on my phone wasn't giving me the info I wanted :)

This is exciting news, but in the world of Electron apps I do wonder if it is not too late already.

Qt has been around for a while and though it gained traction Electron is far outpacing it. It seems that there is no ASP.NET Core since it was borne out of an actual use case with ASP.NET.

Again, kudos to the author and it seems like a great technical feat, but to my knowledge what matters is adoption rate.

> This is exciting news, but in the world of Electron apps I do wonder if it is not too late already.

You're acting like the whole desktop app industry has moved to implementing desktop apps in HTML with Electron.

Fortunately for users this assertion is false, given how shitty most Electron apps are usability and performance wise (VSCode being the only exception).

The performance problems with electron are widely known, but I rarely see anyone complain about electron usability? Surely that's got nothing to do with the underlying technology?

Thankfully no one around me is either using Electron or thinking about even trying it out.

As for Qt, web devs have C++ allergy, hence why the company behind Qt came up with QML. exactly to fight against this trend.

I'm feeling an increasing sense of hostility towards "web devs" lately.

It's frustration, not hostility. The solution is always HotNewFrameworkStillInBeta.js

Yes, web devs do have C++ allergy. More specifically I think the aversion is to doing your own memory allocation.

To me this makes sense. Web developers will typically have a handle on HTML, CSS, JavaScript, Python, PHP, SQL, NodeJS. Some will even be good at most of these. There's design patterns on most of these that are significantly different. The context change from one language to another exacts a toll, which I imagine why Node found a niche in the first place. Electron seems to be finding another.

Why not link to something that explains it first, like an overview?

Can I use this in .net core projects?

This uses .Net and mono

c# for unity, asp and xamarian. wow.

Reply on news.ycombinator.com