I work on a cross-platform desktop application written in C#. We use .Net on Windows and Mono on Mac.

The thing with desktop applications is that an "industrial-strength" one needs to look native; thus it's in our best interest to use the native language of choice. This means that our Mac UI is Objective C, and we're very good at integrating Objective C and C#.

The other thing with desktop applications is that if you're doing something interesting, you probably need to call native APIs for OS concepts that are unique to each platform. A cross-platform environment can't do this very well; and we drop into C++ APIs on Windows and Objective C on Mac to do this.

The sweet spot for cross-platform development is your business logic, and networking calls. That shouldn't change as you move among platforms, and that should be the area that cross-platform development gets right. If you're willing to do this in C or C++, everything will be straightforward, but you have to deal with the warts of C and C++. If you need a higher-level language, it better integrate well with the languages you need to do your UI and low-level logic in.

> The thing with desktop applications is that an "industrial-strength" one needs to look native

I don't think this is the case for every application. It's definitely true for mobile apps, and it's probably true for desktop apps that are relatively small and/or use mainly standard OS GUI functionality.

But for things like Photoshop, or Office, or Unity/Unreal, too much of the UI is application-specific for it to really matter, and I think they benefit from a consistent cross-platform codebase and appearance.

Xamarin makes this separation work pretty well. Not Xamarin.Forms but a core business logic project with custom UI projects for each platform.

I'm hoping this will turn into a good solution. Xamarin already supports Mac (in addition to iOS and Android) and when it aligns more with UWP (XAML Standard etc.) that could cover a large slice of the platforms you'd want to target.

React native could be another option. I hear Android support has gotten better and you can supposedly also target UWP: https://github.com/Microsoft/react-native-windows

I wrote this a while ago but it's still fairly relevant: https://unop.uk/cross-platform-native-mobile-app-development...

You could also look at https://github.com/AvaloniaUI/Avalonia or https://github.com/picoe/Eto.

This is actually the only use case we have for C++, besides interacting with the native APIs from JVM/CLR.

The trend for multi-platform software is to build it on web technologies. There's nothing for the user to install and they can access the software from anywhere there's an internet connection.

If you need it to be offline and integrate into the operating system, then electron would be the next logical step in that direction.

If you want deep, and award winning support, you're going to have to write your product natively for each OS using native APIs. There's just no way around that requirement unfortunately.

With GTK, QT, Tk, etc we used to have a fairly good near-native cross platform story before mobile happened. Apple's reluctance to accept non-native code, Google's pick of Java for Android and early smartphone resource limits made native code a necessity. Meanwhile the web developed into a universally supported application platform which made it inevitable that JavaScript made its way to mobile as processing power increased.

The desktop became just another platform to target. Few cross platform apps can afford to not target the web with all of its benefits like instant, no install required delivery. A whole generation of developers is growing up on Webpack, Babel and React.

Who can fault Electron for existing?

As a user I mourn the cost at which this new wave of desktop apps come. If it were only memory I could buy more – up to a limit – but many of these apps put us back a good 10 years in responsiveness and even screen real estate. My workstation feels like a two year old phone. Who thought unchecking “Show window contents while dragging” would ever make sense again?

Luckily, to get to the original question, we are getting new options. I'm quite excited about Xamarin, which lets us provide a good experience on mobile, against the native toolkit if we like, but also a fast, familiar desktop app.

This isn't worth anything as long as we can't target the web and this is where I hope WebAssembly will bring us.

I remain hopeful. We must be able to do better than ship web browsers to our desktop users, but maybe we're not quite there yet.

If only Microsoft would let us build native UWP apps in F# without having to jump through hoops with web frameworks

https://news.ycombinator.com/item?id=15007166

Wait what? That's totally astonishing - I thought the entire point of .NET and the CLR was to be a language-agnostic runtime. Why can't you build UWP apps with it? How do they even know?

There is no CLR on UWP, everything is AOT compiled to native code, excluding JavaScript.

VB and C# make use of .NET Native and C++/CX are just a few C++ extensions that look like C++/CLI but compile to native code as always. One can also use standard C++ with WRL or C++/WinRT libraries.

.NET Native shares the compiler backend with Visual C++.

The issue is that the .NET Native compiler team doesn't care about supporting the IL required by F#.

I once had to really compile one of my UWP apps to get it working on a locked down Surface Hub (otherwise, I just ever ran them in the debugger). My freaking god, it took 45 minutes to compile a small app...no way...they threw out everything that was good about the CLR for AOT that allowed them to what...run on embedded devices?

It's really too bad, Win2D was quite nice.

Performance.

Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL).

UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together.

COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine.

C++ is still there for the kernel, device drivers, audio and graphical critical performance components like DirectX.

Everything else can enjoy the productivity of .NET languages and respective tooling.

Which meant that any of my WP 8.x and 10 devices run considerably faster than Android devices of similar price range, while having less overall memory requirements.

I get it: a UWP app might be noticeably faster with AOT vs. the standard CLR JIT, but for a UI program that isn't crunching numbers, you are unlikely to tell the difference. Also, the CLR, like the JVM, is no slouch when it comes to running things. As such, there is always a huge asterisk attached to AOT claiming it might improve performance, but it could also degrade it, it is hardly an obvious win. The way it was explained to me was that AOT is necessary for UWP to support IoT and lower end hardware, that on full computers you probably won't notice.

Also, look at all we gave up for AOT. Dynamic compilation in the DLR was pretty nice...and it was reduced to an interpreter in UWP because....no JIT. Granted, I was probably the only person to notice because no one else probably thought to cross the two.

The problem with Microsoft is that as soon as they move to the next thing, they basically abondon the previous one without having the next thing truly replace the previous one. So here comes UWP, meant for "different" things, but it gets all the new stuff while WPF is basically dead. Ya, want to use those new APIs? Sorry, you'll need to use UWP even if you have no intention of running on low end android devices.

So much good stuff, but you have to make a Faustian bargain to use them.

Yeah F# is a good example.

Two years after UWP was introduced still no roadmap in sight for .NET Native support, Visual Studio 15.3 just shipped with the F# team telling people to use VS Code instead.

I bet it will be joining Silverlight in a couple of years.

However Microsoft is not alone in these kind of decisions. I can think of a few similar ones from Apple, Google, IBM, HP, Oracle, Sun,....

Ya, I wouldn't single out MS as particularly bad here, but they used to be much better about this than the other companies. Now they are reaching down to parity, and developer support used to be their greatest strength.

I'm currently working through a CLR via C# book club at work, so I'm curious as well. I know you can make WPF apps in F#.

There is no CLR on UWP, see https://news.ycombinator.com/item?id=15015761

There is some work starting to happen for XAML Standard [0] for .NET. The React Native [1], is promising with JSX abstraction and JavaScript !

I wish Oracle should do more with JavaFX, may be embrace JSX templates.

[0] https://github.com/Microsoft/xaml-standard

[1] https://github.com/CanonicalLtd/react-native

I am currently working on a .NET Core/Mono integration with QML.

https://github.com/pauldotknopf/net-core-qml

The idea is to only have bindings for QML engine and it's parts, with the ability to use .NET objects (properties, signals, slots, methods) with vice-vera (using dynamic).

It is very much in the early stages, but to me, the idea seems very promising.

Don't forget Delphi and C++Builder.

Windows, Mac, iOS, Android, Linux Server, cross-platform UI framework with native controls as well as native-themed ones. Runs on the GPU, vectorised, fast. Two languages, including C++ and Object Pascal (similar to C# in feel, but not C-style syntax.) Very large set of libraries for app development, server development, etc.

I used to think C++/CX could finally be what would make Visual C++ actually Visual and comparable to C++ Builder, but the talks at BUILD and the exclusivity of C# even for HoloLens and Fluent Design demos shows that it failed to gain momentum, being mainly used by Microsoft to write low level code.

I quite liked C++ Builder pre .Net days, tons of useful libs included and community projects like Jedi.

I'm really interested to see what comes of the XAML standard. Supposedly there's a Macos and GTK# implementation in the works.

https://developer.telerik.com/content-types/tutorials/xaml-s...

I wasn't aware .NET Core 2.0 had anything to do with desktop apps?

Not at the moment, but I am looking to bridge that gap.

https://github.com/pauldotknopf/net-core-qml

The idea is to only have bindings for QML engine and it's parts, with the ability to use .NET objects (properties, signals, slots, methods) with vice-vera (using dynamic).

It is very much in the early stages, but to me, the idea seems very promising.

I'm surprised no one here mentioned Lazarus [1].

Sure, it is based on a language which some people have aversions against (for unclear reasons), but it in fact does cross-platform GUI development almost flawlessly, and almost completely friction-less (no, or very little, code change to compile on the three desktop platforms).

Try open up a stable version on your platform of choice, drop a button on the form, double click and write some code (with autocompletion) and compile ... and then import the project on another OS and compile ... It's all a pretty mind-blowing experience, just how productive and "Just Works" the whole thing is.

To expand a bit, it compiles to compiled binaries in the range of MB, uses native GUI libs on each platform (GTK or Qt on Linux for example)... and you can now link it with a language like Go if you need some heavy multi-core processing, or need to access stuff that FPC doesn't have good libraries for [2].

It was discussed in depth here on HN just 5 days ago [3]

[1] https://www.lazarus-ide.org/

[2] https://forum.lazarus.freepascal.org/index.php?topic=24948.0

[3] https://news.ycombinator.com/item?id=14973706

The first things you should do is identify what it is you're trying to create, what your skills are, and what your options are. Also, what platforms you need to support.

The more platforms you need to support with the fewer people, then the more web-based options may appeal to you. Electron works well enough for a lot of applications, and gives you the big three desktop environments. Judicious use of Cordova gets you the two big mobile options. It won't run as buttery smooth as native, and is very easy to let bloat if you don't keep on top of your dependencies.

Java is a bit less liked for desktop applications, mainly because they tend to look clunky, or are otherwise requiring a larger runtime as a prerequisite.

.Net has similar issues. For desktop applications the Xamarin tooling, now in the box, is a decent option, but you will get a few headaches. While I personally prefer C# as a language to Java, the latter is definitely got a bigger community.

QT, etc, are non-starter if you also need a mobile platform.

In the end it really depends on what you need to accomplish and what skills/tools are brought to the table. I'd lean towards using Electron/Cordova for any proof of concept just because it's easy to move fast on that side. I also happen to like Node a lot. You may also want to consider ReactNative as a first or second pass depending on your targets, again.

I wrote a cross platform JavaFX app a couple of years ago. I can't talk to .NET or Qt but I can at least discuss my experiences with that.

Firstly, there aren't any modern, serious, cross platform desktop development environments I'd describe as lightweight. That is not always a problem. If your UI needs are fairly straightforward and you want to use native widgets, then you can use Java+SWT or even AWT. It may sound ridiculous but for small utilities and such that want some buttons, tabs, menus and edits, you don't actually need a modern toolkit - and there are quite a few abstractions over native widget toolkits that work well enough if you aren't demanding.

Now what about the rest. You can see a screenshot of my app here - it's open source but I no longer distribute it:

https://media.coindesk.com/uploads/2015/01/Lighthouse-630x45...

I wrote a desktop app in Java for several reasons:

• It was a peer to peer app. Web and mobile don't really 'do' p2p networks.

• I had already written a library that was the engine of the app, in Java.

• Ignoring the P2P issue for a moment, my target market of early adopter cryptocurrency fans was split across several mobile platforms but all of them had laptops. Cross platform dev on the desktop is more mature than mobile.

• The app had a content creation component that wouldn't have worked well on small screens.

• I wanted to try new ideas in auto update technology, specifically, to enable signing keys to be held in a Trezor hardware device, and allow multi-signature auto updates. So that meant I couldn't distribute via an app store.

My experience of JavaFX was pretty good. It's the third gen UI toolkit after AWT and Swing. It's not abandoned by Oracle. It is however in maintenance mode. There is a reasonable sized team working on it but they focus mostly on bug fixes and rounding out the API these days rather than major new features.

JavaFX dates from around 2010, so it's a modern toolkit. To try and stay on topic, it's similar to .NET XAML. It has all the mod cons like a proper scene graph, support for fully reactive programming, GL/Direct3D based rendering with shader accelerated effects and so on. The design is very nice. The people who built it have done UI toolkits before and you can see their experience shining through. You can style with CSS and I found I could make a UI that looked like a Twitter Bootstrap app just by applying some CSS rules. Combined with a few simple rules (e.g. no menu bars, tree views, etc) I was able to make a UI that basically felt like a web app without actually being so. Nowadays I'd use TornadoFX which is a Kotlin framework that makes it even easier to use.

The big catch is always distribution. All desktop toolkits except Electron suck at this.

There's a tool that creates native installers for your Java app on Mac, Windows and Linux. The user won't know it's Java and doesn't need Java installed, but the resulting installers don't auto update at all. Acceptable if it's 1998 but not so much anymore. I rolled my own auto update framework as I wanted to make it high security anyway, and this wasn't hard, but it was never quite satisfying. I see that Electron uses a separate framework called Squirrel, maybe that's the way to go for Java apps too. But what I really want is an app browser.

I hit a few bugs along the way, none critical. JavaFX has spent the last few years with the team mostly focused on bug fixes and bringing features from internal APIs to the public API, and I felt it get more solid as I worked. Some glitches were platform specific but none were hard to diagnose or work around. It's no worse than any other framework.

Overall I much prefer JavaFX to the web platform. One was designed and implemented by a unified team with a unified vision. The other is a warty swampland which I'd describe as the product of evolution, except that evolution implies some kind of natural selection, which when talking about the web would be too kind. The web can do peer to peer video chat but does not have basics like a decent virtualised table or list view. JavaFX nails the basics all UI toolkits should have, but also supports things like composited h.264 and some basic 3D graphics. It can also embed WebKit if you find you need it.

My wish-list for JavaFX ends up being quite short. Integrate Squirrel for auto updates. Provide direct access to an underlying OpenGL context for more sophisticated 3D work (and let you force GL on Windows). Optimisations. Bug fixes. That's it.

FWIW, Delphi has a cross platform UI library called FireMonkey[1]. It supports Windows, OSX, iOS and Android.

[1]: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Supported_...

Every technology has it's problems, and you should be careful what you use as your source of information. Always do your own research when choosing a new technology to fit your needs best, and talk to other people/consultants who have experience in this area and can point out problems before you commit to anything.

Try looking at the technology used by the software you enjoy using the most. The proof of the pudding is in the eating.

That's always a good suggestion and provides existence proofs, but you have to remind yourself that apps can take years to become favorites, so favorite apps tend to favor older technologies even when the older technologies might not be better.

We use WPF/UWP on Windows projects, Java/Web when needed to be cross-platform, depending on the use case.

Native or Web on mobile projects, again depending on the use case.

I don't think .NET Core is targeted for desktop applications, at least not at this moment.

For the desktop, electron has mostly won really, the web browser becoming the primary most widely used platform for delivering applications made shipping a desktop application with an embedded browser the next obvious choice.

Electron means you need 2GB of memory for a simple chat app like Slack to talk about the application you're building in a fully featured all bells and whistles included application like Visual Studio that only takes 700MB of your memory.

Compare what Visual Studio + ReSharper does versus what Slack does. I have no idea what 70% of the features in Visual Studio do yet I'm using it professionally for years and years, there's just too much.

> Electron means you need 2GB of memory for a simple chat app...

No, it doesn't. Visual Studio Code is an extensible IDE that is stuffed with features - yet it doesn't use that much memory, and it's fast.

And yet there are seemingly simple Electron apps that use a lot of memory and are slow - it seems, just like with any other framework, it's possible to write both good and crappy code.

> No, it doesn't. Visual Studio Code is an extensible IDE that is stuffed with features - yet it doesn't use that much memory, and it's fast.

When I first used Visual Sutdio it was VC++ 6 and I upgraded my machine to have 256MB of RAM so I could run it. What features does VS Code have that VC++ 6 didn't?

I didn't use VC++ 6 myself, but I'll take a guess at a few things:

  - IntelliSense

  - Tasks for external tools

  - Themeable

  - Extensible through plugins, for which there is a large ecosystem

  - Support for many languages, with syntax highlighting and linting (through plugins)

  - Support for different debuggers (e.g. debugging a Cordova app)

  - Support for different version control systems (TFS, Git, SVN...)

  - Minimap

  - Highlighting of all instances of selected text in the scrollbar (don't know if this feature has a name, but it's really useful)

  - Ability to edit multiple lines at the same time

  - Bracket matching

  - Code folding

  - Live, inline reference information

  - Not sure if 'go to definition' or 'go to implementation' was a thing in the days of VC++ 6?

  - Workspace zoom

  - Support for screen readers

  - Integrated terminal

It had most of those things, especially the important ones:

  - IntelliSense - Yes

  - Tasks for external tools - I think so

  - Themeable - Yes, back then you could theme the whole windows desktop and native apps would comply.

  - Extensible through plugins, for which there is a large ecosystem - Kind of, all the "plugins" came from MS.

  - Support for many languages, with syntax highlighting and linting (through plugins) - Yes, not sure how many.

  - Support for different debuggers (e.g. debugging a Cordova app) - Don't think so.

  - Support for different version control systems (TFS, Git, SVN...) - Not sure, it predates everything on that list.

  - Minimap - Don't think so.

  - Highlighting of all instances of selected text in the scrollbar (don't know if this feature has a name, but it's really useful) - Not sure

  - Ability to edit multiple lines at the same time - No

  - Bracket matching - Yes

  - Code folding - Yes (I think)

  - Live, inline reference information - Yes

  - Not sure if 'go to definition' or 'go to implementation' was a thing in the days of VC++ 6? - It was (not sure about goto implementation though)

  - Workspace zoom - Don't know what that is.

  - Support for screen readers - Probably via windows API's, but I'm not sure.

  - Integrated terminal - not sure.

Sure doesn't look like a lot of process in the intervening 20 years.

Huh, kind of impressed it could do so much!

Ah, I missed one important one though:

  - Cross-platform

By 'Workspace zoom', I mean you can dynamically change the zoom level of open files, without having to go through settings menues to increase/decrease the font size

I mean, I have one window open with one file right now and it is using 400MB which is kind of crazy.

I just opened a large project in VS 2017 - 1GB of memory usage, vs 250MB by VS Code.

Sure, 250MB is a lot by 1990 standards, but for something as fully featured as cross-platform VS Code with today's machines (and especially when compared to full VS), it's rather impressive.

I have VS Code with a dozen plugins running, and using about 1GB two editor windows, each with a few tabs open, as well as the terminal (best point of integration imho) in each.

Spotify seems to be using a bit under 200MB.

For comparison, libre-office with a 60-row spreadsheet open is using 145MB.

Frankly, it's not that bad... I've got 16GB on my laptop (thanks apple), and 32gb on my home desktop, though may go threadripper at the end of the year with 64-128gb. It's there to be used.

VS Code is much more responsive than Visual Studio... and the plugins and integration are great. Integrated terminal, and the git integration are nice, though I wish they'd get closer to full 3-way merge support.

Spotify uses Chromium Embedded Framework, not Electron - doesn't change your argument, but it's good to know.

Source: https://www.quora.com/How-did-Spotify-make-a-multiplatform-l...

Many of us still have 8GB systems or even plain 4GB.

Well, Code and the browser are my main two applications... the rest take up very little by comparison. But, you're right, I wouldn't want to rely on a dozen electron based apps being loaded. That doesn't mean it isn't a good option for a lot of things.

I'm sorry, but as for now, Electron is really not the best choice for a desktop platform, and you can't declare it a standard only because some developers choose it, mostly because it's easier for them to create or port apps using a familiar stack. In the future, certain things may change - the performance might be better and resource usage might get lower (although I honestly doubt - with browsers getting more features it's even likely to go the other way round), but as of now, Electron as a desktop platform is inferior when compared to a native app in all aspects.

I see Electron as an example of the "Worse is Better" theme.

In what respect? Start-up time, memory and cpu, speed, lack of native controls, poor optimization, complex debugging... What's the worst for me is the fact that you know there are certain parts of the app you will never be able to optimize. It's just like having empty loops inserted in different places of your app, only because of the choice of platform. Sometimes it feels like Swing in the old days.

No, usability matters.

I've removed the Slack app because it's way too sluggish, just use the website when I want to check it.

I've tried Atom but it felt just not right, mainly because it lacked a certain snappyness - so I'm back to Sublime.

Sure when the users don't have any alternative they might bear with it, but a major selling point of a native app is that it feels right.

Agreed on the slack app... but I've been using VS Code very happily, especially since the integrated terminal was added, which is a feature I've wanted in my editor for a very long time... The terminal was pretty sluggish on some things at first, but works well... still not much of a fan of hyperterm, which shares the same terminal integration modules.

Most of the electron apps I've used I don't use much... except vs code, and for what interactions I have they aren't bad. However, most of my time is in one of several browser tabs, vs code, and a terminal window. I keep Goofy (fb mobile as electron app), and Spotify (electron iirc) open... that's about it.

I hope it dies quicker than Flash.