8 ms·

I wish I had a better sense of where cross-platform desktop app platforms stood these days: Electron, Java, .NET, QT. All I hear are "Eww, Electron is ridiculou

by SiVal 9y ago

I wish I had a better sense of where cross-platform desktop app platforms stood these days: Electron, Java, .NET, QT. All I hear are "Eww, Electron is ridiculous, slow, heavy Web junk for desktop", "Eww Java is blub, insecure, and half-abandoned by Oracle", "Eww, .NET is Microsoft and unreliable for anything serious on non-MS OSes", "Eww, by the time you pay the license, learn QT, learn the odd variant of C++, and manually deal with different bugs on every platform, you discover you would have been better off using the OS makers' preferred tech on each," and so on. It's hard to tell how much of this emotional reaction is due to current reality, how much is leftover from old experiences that are no longer relevant, how much is just language preference (not platform quality), etc. I could just try them all, but my experience years ago was that the cross-platform tech, when it worked, made things easy at first, but that final 5% of your code was always trying to find hacks to do what no one had ever tried before--very time consuming and risky (no guarantee of success). So "trying them all" won't really give me a true sense of where the technologies are in reality. There's no rush in my case, but I do wish I had a more realistic sense of what the various desktop dev technologies were like these days in case I ever go back to it.

cormacrelf 9y ago
I wasn't aware .NET Core 2.0 had anything to do with desktop apps?
- pknopf 9y ago
  Not at the moment, but I am looking to bridge that gap. https://github.com/pauldotknopf/net-core-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.
hacker_9 9y ago
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.
jarjoura 9y ago
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.
- sjmulder 9y ago
  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.
  - TensorMetric 9y ago
    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 https://news.ycombinator.com/item?id=15007166
newhere420 9y ago
Try looking at the technology used by the software you enjoy using the most. The proof of the pudding is in the eating.
- SiVal 9y ago
  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.
Scarbutt 9y ago
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.
- dvfjsdhgfv 9y ago
  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.
  - Scarbutt 9y ago
    I see Electron as an example of the "Worse is Better" theme.
    - dvfjsdhgfv 9y ago
      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.
    - pantalaimon 9y ago
      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.
mike_hearn 9y ago
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-630x451.jpg 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.
pknopf 9y ago
I am currently working on a .NET Core/Mono integration with QML. https://github.com/pauldotknopf/net-core-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.
ledgerdev 9y ago
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-standard-demystified/ https://developer.telerik.com/content-types/tutorials/xaml-s...
crudbug 9y ago
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 https://github.com/Microsoft/xaml-standard [1] https://github.com/CanonicalLtd/react-native https://github.com/CanonicalLtd/react-native
pow_pp_-1_v 9y ago
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_Target_Platforms http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Supported_...
carlosrg 9y ago
I don't think .NET Core is targeted for desktop applications, at least not at this moment.
pjmlp 9y ago
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.
gwbas1c 9y ago
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.
- jsingleton 9y ago
  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 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-options/ https://unop.uk/cross-platform-native-mobile-app-development... You could also look at https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia or https://github.com/picoe/Eto https://github.com/picoe/Eto.
- Rusky 9y ago
  > 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.
vintagedave 9y ago
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.
- locusm 9y ago
  I quite liked C++ Builder pre .Net days, tons of useful libs included and community projects like Jedi.
- pjmlp 9y ago
  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.
tracker1 9y ago
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.
samuell 9y ago
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/ https://www.lazarus-ide.org/ [2] https://forum.lazarus.freepascal.org/index.php?topic=24948.0 https://forum.lazarus.freepascal.org/index.php?topic=24948.0 [3] https://news.ycombinator.com/item?id=14973706 https://news.ycombinator.com/item?id=14973706

by SiVal 9y ago

cormacrelf 9y ago

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

pknopf 9y ago
Not at the moment, but I am looking to bridge that gap. https://github.com/pauldotknopf/net-core-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.

hacker_9 9y ago

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.

jarjoura 9y ago

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.

sjmulder 9y ago
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.
- TensorMetric 9y ago
  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 https://news.ycombinator.com/item?id=15007166

newhere420 9y ago

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

SiVal 9y ago
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.

Scarbutt 9y ago

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.

dvfjsdhgfv 9y ago
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.
- Scarbutt 9y ago
  I see Electron as an example of the "Worse is Better" theme.
  - dvfjsdhgfv 9y ago
    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.
  - pantalaimon 9y ago
    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.

mike_hearn 9y ago

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-630x451.jpg 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.

pknopf 9y ago

I am currently working on a .NET Core/Mono integration with QML. https://github.com/pauldotknopf/net-core-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.

ledgerdev 9y ago

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-standard-demystified/ https://developer.telerik.com/content-types/tutorials/xaml-s...

crudbug 9y ago

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 https://github.com/Microsoft/xaml-standard [1] https://github.com/CanonicalLtd/react-native https://github.com/CanonicalLtd/react-native

pow_pp_-1_v 9y ago

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_Target_Platforms http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Supported_...

carlosrg 9y ago

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

pjmlp 9y ago

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.

gwbas1c 9y ago

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.

jsingleton 9y ago
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 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-options/ https://unop.uk/cross-platform-native-mobile-app-development... You could also look at https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia or https://github.com/picoe/Eto https://github.com/picoe/Eto.
Rusky 9y ago
> 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.

vintagedave 9y ago

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.

locusm 9y ago
I quite liked C++ Builder pre .Net days, tons of useful libs included and community projects like Jedi.
pjmlp 9y ago
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.

tracker1 9y ago

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.

samuell 9y ago

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/ https://www.lazarus-ide.org/ [2] https://forum.lazarus.freepascal.org/index.php?topic=24948.0 https://forum.lazarus.freepascal.org/index.php?topic=24948.0 [3] https://news.ycombinator.com/item?id=14973706 https://news.ycombinator.com/item?id=14973706