Ask HN: What would you use to make cross-platform desktop application? | Hacker News Reader

Ask HN: What would you use to make cross-platform desktop application?

44 pointsshubhamjain115 comments

Seeing Electron as an unpopular choice here for making Desktop applications (size-heavy, and slow), I am interested what all options exist to make cross platform apps.

View on HN

I would take opinions on here from developers with a big grain of salt. I read people saying things like Spotify and Atom are "unusable" and slow because they're written in JavaScript when they have plenty of happy users.

A few 100MB of RAM or disk space extra is a nonexistent issue as well to typical users. I know some developers get very offended at a program using a bit more RAM or CPU than it should be but developer efficiency is more important most of the time so it's a completely rational trade-off. Some of these apps wouldn't exist at all if everyone insisted on native everywhere.

It's all just my opinion as well, but approaches like Electron are very efficient at creating good cross platform apps. Developing and maintaining several native apps is a huge resource drain when most users aren't going to care.

My laptop has 2GB RAM. Firefox takes up about a quarter of it on average, Emacs is about 10-100MB, the system (Xubuntu) seems to take up about a GB, and what remains is indeed a few hundred megabytes. This means that I can run half an Electron app at a time on my machine. And normal people don't have more than 4-8MBs of ram on their computers. And high CPU and RAM usage drains battery, and most people are on laptops nowadays. So RAM and CPU use is still a thing for users. If anybody thinks otherwise, that's probably because they're in their bubble of hackers and have only a guesstimate about an ordinary user's use of a computer.

> I would take opinions on here from developers with a big grain of salt.

If you "Ask HN" for opinions how can you take those opinions with a grain of salt?

Surely if you can't trust HN commenters then Ask HN is a waste of time.

Speaking as someone with an Ultrabook that had to run Chrome, Outlook, Skype, and various office apps and so forth, this attitude infuriates me.

Slack uses 400-500MB of memory. That's 15% of my RAM. For a chat application. Every Electron app is in this range. None share a runtime or memory footprint.

Believe it or not, not everyone has 16GB of RAM. This level of inefficiency is utterly inexcusable.

Not everyone has 16B of RAM, and those that do get worse battery life because that much RAM is a significant part of a laptop's power budget.

Now that you mention it, this is pretty ridiculous: http://imgur.com/a/HyFay

Code Helper is from VSCode. VSCode, Evernote and Slack are all completely idle right now. I don't think they should be using any memory at all. Especially not over 700 MB. I don't even understand how they could possibly be using that much memory.

Is it just memory leaks?

That image means nothing. Apps and the operating system cache lots of different things. If your system was under memory pressure then you'd see it lower.

Fact is if the ram it available, an app should cache as much as possible. It has no idea what you'll need next, so better it use a free resource to reduce latency.

You cannot think of an app in just terms of the text it handles but also window pixmap data.

Apps and the operating system cache lots of different things. If your system was under memory pressure then you'd see it lower.

There's a problem, though: it doesn't work that way.

The size reported by Windows is (if I'm not mistaken) the committed heap size of the program. Unless the application actively surrenders allocated pages back to the OS (and hint: no application does that), that memory is committed.

Edit: to add some color: when a program calls malloc, memory is allocated from pools inside the process itself. If no memory is available in the internal pool the allocator will call out to the OS for additional pages (in the Unix world this is a call to sbrk). When free is called, memory is returned to the internal pool but is not surrendered back to the OS and thus remains committed to the process. Actually reducing the committed heap size once again requires an explicit call to the OS (e.g sbrk).

Of course it may be swapped out by the OS, but that just means slow disk I/O when that application comes to the foreground or accesses those swapped pages (which presumably contains the precious cached data you refer to).

Should the OS use memory to cache transient data? Certainly. OSes typically contain logic to throw away those caches if memory is needed.

But applications that do this without intelligently surrendering cached pages back to the OS when memory is low (as an OS does with its own caches) just put that much more memory pressure on the overall system itself. And I've never heard of an application that does this. Certainly I've seen no evidence that Electron is that sophisticated in its memory management, though I'm happy to be proven wrong.

Don't know if it's relevant, but that screenshot is from macOS, not Windows.

Anecdotally: I am currently running VSCode and Task Manager reports 19,8 MB of memory usage right now (vscode Window being idle, with 6 files opened on Win10)

The size reported by windows is the private working set. If windows pages out data for non-use it doesn't show unless you add the commit column.

I tried switching to Atom a few times, but I couldn't handle the slowness. It's just too laggy. On the other hand, I recently switched to VS Code, and I couldn't be happier. The startup is still a little slower than Sublime, but the editor is blazing fast. I really think this is just a problem with the architecture of Atom.

Spotify is also a bit slow and clunky, but it's not too bad. There's no reason why they couldn't aggressively pre-fetch a lot of pages to make the UI feel snappy. E.g. "Browse", "Radio", and all the tabs under "Your Music". And if you're playing a track, just pre-fetch the artist and album pages. If I can click something in the UI, it should already be loaded.

But even when stuff is already cached, the UI takes about 500ms to render the new page. Sometimes it's only a few hundred ms, but there's a nasty black flash before it renders. the new page. There's really no reason for that either. There are so many ways you could speed that up to make it instant. For example, just render everything above the fold, then add the rest of the content later.

Spotify's internet connection detection drives me crazy sometimes. Sometimes it takes 20-30 seconds to get back online, but I don't think that's related to JS. Their polling interval is just too long. There's no reason why they couldn't poll once per second and come back online immediately.

Maybe Microsoft is making heavy usage of Node native modules. I don't know for sure, but I suspect this is the reason why VS Code is much faster than Atom.

As far as resource consumption goes, VS Code is definitely the lesser of two evils.

I can't help but be reminded of the "VS Code uses 13% CPU when idle due to blinking cursor rendering" post that was on HN earlier last week, referring to the following issue:

https://github.com/Microsoft/vscode/issues/22900

Every Electron app I tried halved my battery life. Sure, regular people won't complain about your electron "desktop" app, they'll just complain about crappy batteries of their laptop, or about "my computer getting slow".

In fact, every time you hear a non-programmer complain about their computer it's usually not a hardware, but a software like electron that's ruining their experience.

OSes have started to add application profiling recently, so once every mainstream OS starts loudly pointing a finger at offensive applications (like "uninstall Spotify/Slack and you'll get 4 more hours of battery life"), you'll start hearing complaints from non-programmers.

This is absolutely the case.

I can get literally double the battery life on my Thinkpad if I close Slack, Messenger for Desktop, Atom/VSCode. Chrome uses multiple extra watts of juice in powertop than Firefox, and every Electron.JS application is really just a Chrome instance.

I'm not sure about battery life but I was a huge fan of Slack (based on Electron) until I set it to run at startup. Before then I'd routinely have three Visual Studio instances, a SQL manager and Chrome running with 10 or 15 tabs open. No problem. Suddenly, I noticed my Windows machine would bog down with just one Visual Studio and take minutes to load Chrome. I was sure I had a virus.

Actually, Task Manager showed 90% of my 8Gb ram being utilized and caching to disk constantly with most of the ram and CPU being hogged by eight(!) Slack threads. This is with Slack minimized and sitting idle.

The fix was to replace the Slack/Electron app and use the browser version instead. That solved it.

Electron is a super cool piece of tech that could enable all kinds of great app development but needs to go on a serious diet first.

But atom is actually unusable, I've tried it, the lag is terrible, thank god for notepad++

>I read people saying things like Spotify and Atom are "unusable" and slow because they're written in JavaScript when they have plenty of happy users.

Well there isn't exactly a choice of what spotify client to compare it to is there - so users have to use it by default rather than be 'happy' about it.

Obligatory: Qt.

I've been tasked as a Qt dev at my day job for the past ~2.5 years writing cross-platform applications. It works, the documentation is pretty fantastic, and you'll find no shortage of help online to get over the admittedly decent learning curve if this is your first swing at "c++" programming.

Edit: As mentioned below, PyQt is also pretty fantastic. My most recent venture into the PyQt world at work was writing a touchscreen application on a 800x450 touchscreen, and it all "just worked."

PyQT is a nice alternative if you don't know/want to program in C++ .

AFAIK Qt also has support for writing apps in JS (isn't that what Qml is?).

Yes and no. You need a C++ skeleton to integrate the Qml files. Also Qml/JS is slow and doesn't support all the features of Qt/C++. Practically you use Qml for the GUI, but C++ for the logic.

Or you can create components in C++ callable from Qml, but this requires some extra code ( and work ).

Or wxWidgets for a native GUI look.

Seconded:

- QT is a great and very-well designed library with solid performance, a fast release cycle and superb documentation.

- It provides a rich and well thought-out component library.

- It is used by many companies to build real-world applications.

- It has a pretty liberal licensing scheme. The commercial license (if you need it) is not that expensive.

- It provides bindings for many scripting languages like Python.

- It has great IDE support and lots of tooling around the core library that make GUI design easier.

- It emabraces model-driven design and has stylable components (via CSS).

- It will usually beat most JS / WebKit based frameworks by a large margin performance-wise and makes distribution of your application much easier (forget about >100 MB downloads).

FWIW its version of CSS is just terrible, there are a lot of properties you cannot control with it (e.g. display properties), its style inheritance model is equally terrible (for some reason if you do .foo, the foo object will get the style as will all of foo's children), and forget about animations. To be fair, I did test it out at v5 and they may have improved it, but at that time it was by no means a fair thing to call it css.

And that's why they call it QSS (Qt style sheets). :)

- The commercial license (if you need it) is not that expensive.

I consider it very expensive. More than +US 3000/year for 1 developer?

The open-source is useless for desktop apps?.

Why is the open-source version useless for desktop apps?

> As mentioned below, PyQt is also pretty fantastic.

Isn't Python just as slow as Electron?

Qt ought to be a thinner layer than Electron, and most computation-heavy things you'd do in Python end up in the C libraries that the modules are implemented in, anyhow.

I program in C++ professionally and about every 6 months I get the Qt tingle and think "I should really get around to learning Qt". But whenever I start to look into it I start to feel like I'm supposed to learning some custom language and it's not C++ at all - and how am I going to work this into the rest of my workflow

I've got a pretty vanilla workflow with CMake, the GNU tools, the STL and emacs/KDevelop/CLI to tie it together. It works across all platforms and all problem domains. But the internet is telling me that if I want to make native GUIs I have to be in the parallel universe of Qt with its own version of CMake, some magic custom build steps, its own IDE and some XML stuff that you really really should use otherwise things will get messy.

Is this just b/c Qt is old? Is there a bigger reason for the Qt-verse I'm just not seeing? And is this all a lot less of a headache than I'm imagining?

PS: Are there any clean frameworks that are tied to modern C++?

I don't know any such frameworks. Building a quality one takes a lot of work and time, I guess most of them are decades old at this point.

I've included some answers below:

* One can use Qt with CMake and for a large project probably should, because qmake can be quite limited.

* Qt Creator is not a must, but it's a good C++ IDE and was designed to work well with Qt. I think KDevelop should have pretty good Qt support too.

* The only XML I can think of are the UI designer files. If you prefer you can write the UI code by hand, but it's quite barbaric IMO :) Those files are just parsed and transformed into a ui_foo.h file which contains an inline setupUi method that one should call from their widget's constructor.

* The custom build step is running the meta-object compiler. It's necessary for signals and slots (Qt's ubiquitous subject-observer implementation) and for e.g. reflection if used. This is only really needed for classes that inherit from QObject, such as all the UI classes. If you want to be really hard-core, you can build the entire UI in code, without inheriting from the UI classes, and then I think this extra build step is not needed, but you will lose covenience and some customization possibilities. They've also added signal-to-lambda connections, so one is not obliged to use slots at all AFAIK.

All in all it's not bad at all. If one wants to have a cleanly separate Qt and pure C++ code-base it's possible with some glue code.

thanks! I guess you're right, it doesn't seem so bad. I might dig into this more next time I have a project that needs a UI.

> And is this all a lot less of a headache than I'm imagining?

It really isn't much of a headache.

One real world success story for Qt:

Andy Brice (Oryx Digital, UK) has been developing his successful desktop software product, Perfect Table Plan (a seating planner software for events), in C++ and Qt, and selling it for over 10 years. (His newer product HyperPlan may be done in that stack too.) I've been a reader of his blog from some time: successfulsoftware.net. Many good tech and more biz tips there (for the software product biz - for desktop apps). And his app is cross-platform between at least two of the big 3 consumer OS's, IIRC (or maybe all 3) - Windows, Linux and MacOS.

Edit: I had also checked out Qt (v3 or 4) and tried some of the example apps (reading, compiling and running them) and also bought and read most of a book on Qt programming by some well-known Qt developers (don't remember the book or author names right now, but they may have included some of the original Qt creators). The impression I came away with was similar to that of some of the other commenters here - Qt seemed to be a well-designed library, not too difficult to learn, and with fairly good documentation at the time. I could understand the signals and slots mechanism it uses, without much trouble. Didn't get the moc part though (was not a C++ expert, also did not look much into moc) but it may not be needed to know that well, may be enough just to be able to use it.

> moc

FWIW I never had to delve into understanding what exactly it does apart from "is invoked by build system to generate some code" in the course of many years of working with Qt.

Good to know, thanks.

Is there any Qt app for the Mac that doesn't land in the uncanny valley of UI? I've not been impressed with the apps I've tried.

I've tried Qt creator and during typing it uses ~20% of my CPU, the same visual studio code uses.

Lazarus is a cross-platform IDE for native desktop applications on Windows, Mac and Linux. It produces fast, low-memory, single executable files for easy installation and deployment. Your app can use native OS controls - you won't be gluing together different libraries from different languages like you do with some scripting languages (with all the bloated size and performance issues that entails).

Why isn't it more popular? Because it's written in FreePascal: a modern, object-oriented version of Pascal. A lot of readers will stop right here and never this give project another glance, the thought of using Pascal as simply too outdated or embarrassing.

If you do give it a try, you'll discover one of the best and most overlooked options for native desktop app development. Any downsides? A major one in my view: poor and patchy documentation (which will be a barrier and block for many).

https://www.lazarus-ide.org/

Why FreePascal..?

This is suicide.

Something a little less hyperbolic might be better, e.g. what specifically is wrong with FreePascal?

The fact that the project is not popular because of the language it's written with..?

Why is FreePascal unpopular (or what makes you say that)?

Is it lack of mindshare, lack of "hotness", some specific deficiency, or... ?

I just read what the comment said:

> Why isn't it more popular? Because it's written in FreePascal: a modern, object-oriented version of Pascal. A lot of readers will stop right here and never this give project another glance, the thought of using Pascal as simply too outdated or embarrassing.

Personally, I've never heard of the framework and FreePascal would definitely be a reason not to adopt it for me, as I'm not familiar with how to fix problems should they arise, while I would be able to troubleshoot an app written on Java or better yet NodeJS.

Free Pascal seems to have all the memory safety drawbacks of C and C++, which I stopped using seriously years ago.

+1 for Lazarus. Great cross platform development tool that creates _native_ UI. I use it occasionally and have only nice things to say.

+1 using it since ages.

Good points.

I did this a few months ago:

Digital Clock created in FreePascal / Lazarus:

https://jugad2.blogspot.in/2017/04/digital-clock-created-in-...

I'm developing a file manager [1] and asked myself the exact same question a year ago. I chose PyQt and am quite happy with it. I wrote a blog post [2] back then about your very question. If you pick PyQt, then you will also find several other articles on the blog [3] interesting. Basically, whenever I encountered a hurdle, I posted a solution.

[1]: https://fman.io

[2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...

[3]: https://fman.io/blog

Why not just have a daemon process that runs a site on HTTP or WebSocket so you can use the app in your browser?

I've seen apps that run with a double-click, stay open, and open my browser tab on 127.0.0.1:43110, with the entire app right there. It takes very little to develop, and it's lightweight because it's already using a runtime we all use most of the time (a web browser).

For the development side, this is pretty much the same experience as developing for Electron, but without the RAM/battery drainage.

I've often said that if I wanted to run a desktop application in a web browser, then I would prefer to run it in an actual web browser and thus share the framework footprint rather than running multiple instances of Electron.

Emacs.

I mean the user base and the scope is kind-of limited, but it's really easy to build thin-clients and some certain types of applications in Elisp. And against all prejudice, modern Elisp is quite a pleasurable language to write in. Furthermore, it's a joy to use that sort of "apps" in emacs and the community really likes it when those pop up. Also, there already are rather featureful apps like Gnus, Magit, EMMS and Elfeed, and the user is allowed vast customisation even without you really thinking about allowing it (advices, monkey-patching, keybindings, hooks, etc.).

P.S.: While I don't suggest this as seriously as those who suggest Qt and WxWidgets et al., if your demographic is hackers, you can consider it.

Who cares if Electron is unpopular (is it?)?

I use Electron apps daily: Atom, Spotify, and Wmail, and I'm perfectly productive with them.

Atom is definitely slower than Sublime Text, but I'm not sure it's Electron's fault (I read that it isn't). As for Spotify and Wmail, you can't even tell it's Electron, and certainly no average user cares or would ever know.

I would do what makes sense for your app and makes it easier to port it. Electron works great for that, and you can use the same code to offer a web app.

Huh i certainly can tell that it is not native. It's huge for what little it does

I've just finished writing an Electron app. If you're already in the front-end web development world, the learning curve will be mild. The hardest part had little to do with Electron and more with the rapid changes in the JS world. It's hard to keep up.

Electron certainly isn't unpopular with the people who use applications built with Electron.

I doubt more than 95% of those who have Spotify install know what Electron is.

We built Spectrum (https://www.devspectrum.com) for filtering logs and it was great to work with and plenty fast.

You should give VSCode a try. I recently switched from Sublime to VSCode, and I'm very happy with it. Startup is a little slow, but the editor is blazing fast.

We use delphi at work. It is suited to building in-house apps iOS, Android and Windows, as well as web services on Linux.

What version of Delphi are you using ?

Don't you find the lack of 3rd party library support somewhat difficult ?

We have legacy software written in Delphi7 as well as newer web facing utilities and android applications (for customs and logistics personnel) written in Delphi XE7 and later.

We get excellent third party support for oxml, secure blackbox, gnostice components, devexpress components, uniqui and many, many other libraries.

Great to hear that all of it is still alive. I was getting out my old Delphi I so enjoyed in high school but I found that while all my programs do still work on win10, the same cannot be said of the IDE (although Delphi 1 does work).

So I had to put it in virtualbox in windows xp. Great nostalgic experience I must say. Back when I truly enjoyed programming just for the sake of trying something new.

There is a free version of XE 10.2 that works on windows 10 with a lot of the features cut. You can still write 32bit windows applications just like the old days: https://www.embarcadero.com/products/delphi/starter/promotio...

Seems like they are naming the versions after cities nowadays (maybe were earlier too). E.g. 10, 10.1 and 10.2 are called Seattle, Berlin and Tokyo. Had tried out 10 Seattle and am using 10.1 Berlin some.

>although Delphi 1 does work

Ha ha, I still have an old CD of Delphi 1 somewhere.

Where do you work, that you get to use Delphi, if it's not private?

I think it depends on the type of application, and how much code you want to reuse. Assuming this a fairly large scale app and long term maintainability is a consideration:

* If some of the code is likely to be reused with an associated website I would go for Electron. Using ReactJS.

* If an associated mobile app is also possible, I would take a look at React-Native, which have some embryonic desktop technology counterparts. This option can be combined with a webview.

* Worth also looking at Xamarin, especially if there's existing investment and skills in .NET (e.g. existing Windows app being migrated).

Electron hasn't stopped Spotify from making the most widely used music client and VSCode from making the third most popular IDE.

I'd audaciously guess that it's the songs you play in it that makes the spotify app popular, not the pack of ones and zeroes that the developers thereof like better.

Speaking just for myself here... I use Spotify every day and I can guarantee that I would switch if the software experience was bad. I honestly can't think of a time the app crashed. It can switch between my mobile devices and the desktop seamlessly almost every time. The overall design is intuitive enough _and_ it happens to come in a color scheme that I love.

I used to find my music elsewhere and could do it again if I had to.

Switch to what? Everything else costs quite a bit of money (buying songs individually). Or you could pirate your music. Either way, it takes a shit ton of time to build up a halfway decent music library from scratch. Especially when the convenience of 'just search on spotify and add the entire artist to a playlist' is right there for free.

I've had the spotify app crash my computer a few times. And then there was that fiasco a while back about it writing many, many gigs of data to SSDs and shortening their lifespan. Convenience will always trump software quality, but as soon as there is a competitor with better working software at a decent price, I'm jumping ship.

I'd switch to Apple Music or Google Music. Both are services I've tried that work for me.

Ever hear of the Napster audio app? Not the p2p thing, the paid subscription app? It was just like Spotify, way before Spotify? Oh really, no, you hadn't? Could it be because the UI was terrible? Hm.

What about rdio? Back in the day, I remember noticing they had a much better music archive than Spotify in some areas like prog. Still, I never made the switch. (The way they organized music was terrible.) Apparently, neither did anyone else.

I could go on. All these Spotify competitors, all with decent libraries. How did Spotify end up winning?

I'm not saying that songs are unimportant, but if you have trash ux people are going to find an alternative.

So not electron = trash UX?

(edit: I'm an amateur musician, I do know quite a bit about the online music sphere, and I've been a paid user of both Deezer and Spotify in the past. You usually don't know who you're talking to on the internet, so better don't assume things.)

Did I make assumptions? My bad. Well, I guess I made the assumption that you were unfamiliar with the napster app, so my bad. Other that that I dunno. (I happen to be an amateur musician as well. Fun coincidence.)

Anyways, what I'm saying is that using electron is not really correlated to "bad app" and not using electron is not correlated to "good app".

Slack is built on Electron too.

And there's constant talk of them going native because of how poor the current client performs...

Let's confront "worse is better" directly: more-popular software is not the same as better software.

The Web is a race to the bottom in the quest for eyeballs. If eyeballs aren't what you desire, you can give the set of users you do have a much better experience: smoother interactions, better adaptation to system preferences, automated security and functionality updates to components via the OS distribution, better accessibility, etc.

I would make a counter-argument that software that gets used is indeed better than software that does not get used. Say what you want about the deficiencies of Electron, but it's proven to make software that people use. And like!

If you and OP want to disagree with the premise that used software is good software, and go in the opposite direction, that's fine - that's the point where we agree to disagree and go home.

I can't say I've ever used VSCode, but I like Spotify despite its UI, not because of it.

That having been said, I don't use Spotify a lot, as the UI is really cumbersome and puts me off the entire thing.

IIRC when Spotify switched to Electron there was a massive outcry from the general computing masses saying how much worse the new Spotify client was. You also have to bare in mind that Spotify is winning in it's market due to licencing (providing a range of music that other competitors haven't been able to licence). It's got naff all to do with the quality of the client.

People use spotify for their library/features - they'll put up with the client because there's no alternative clients to stream their spotify.

And thinking like this is why iTunes for Windows exists....

FLTK http://www.fltk.org/index.php dead easy and uncomplicated, an http server for business logic.

Also I use then through a scripting language https://github.com/mingodad/squilu OS X, Linux, Windows, (iOS && Android through browser/native) ...

Maybe consider Xojo, which is like a cross-platform Visual Basic. I know, that means you're programming in Basic, but it's the fastest tool I've found & the compiled binaries are relatively small (Mac version of my current app is 11 MB uncompressed). It supports Mac / Windows / Linux, but it also compiles to Raspberry Pi, iOS, Web, and Android support is in the works. Pricing is cheaper than Delphi or Qt. But if you need to collaborate, there aren't as many Xojo / REALbasic developers out there, as something like Qt:

http://www.xojo.com/

For other Windows/Mac stuff I'm working on, I use C++ for the cross-platform code, and Win32 API / Obj-C for the platform-specific interface layers.

JavaFX looks pretty good right now... especially if you use Kotlin and TornadoFX with it.

wxWidgets. More lightweight than Qt and better looking on Linux. It has improved quite a lot recently, for example it supported binding C++11 lambda functions to signals before Qt.

Also: No moc compiler and you can statically link it without paying for a commercial license.

Have you checked out [NW.js](https://nwjs.io/)? I'm not sure if it's better than Electron in terms of executable size and performance, but definitely worth a shot.

Then there's [Kivy](https://kivy.org/#home). Love that.

One of the main guy behind nwjs was actually hired by Github to create Electron.

Then I'm not sure to what extent nw.js solves the problem.

I’ve had problems in the past trying to maintain a consistent look and feel for my apps across the three major desktop platforms. I was only able to recently achieve this by creating a dotnet core web app (served by the kestrel server) that is rendered by an Electron (chromium) app. With this done, I wrote scripts to create deployment packages for Window, Mac Os and Linux (deb). I can say my life has been been made a little easier.

The fact that the dotnet core app does the heavy lifting makes the whole application relatively fast.

See an example here https://www.ccasystem.io/Resources/DownloadDesktop

HTML and JavaScript in the browser can still be done on the desktop. If you are willing to make HTTP requests to localhost then there's a number of possibilities. Golang for example cross compiles easily.

You have two options: either make the app work natively with your platforms, sharing all the code that does not directly work with platform only features, or use something that can run things on multiple platforms.

I would personally lean towards doing the last, with the target being the JVM -- that doesn't have to mean use Java, as there are many much better languages that target the JVM.

If you can, wait WebAssembly support for Web/DOM API and support from languages like Kotlin/Swift. This will be a game changer.

I hear people say this and am always incredulous that this stack would be available (let alone viable) in the next 5 years.

As people were incredulous when I said last year WebAssembly will be shortly available in the 4 major browsers, and now it is ;-)

As a user, bespoke apps (or frontends, anyway) for each platform are obviously ideal. Failing that, Electron is alright. Qt is pretty awful.

As a dev, Unity is nice, but brutal on batteries for normal apps. I wonder if there's a way to hack it to only run the various loops on event changes and thereby be more efficient...

I mentioned this yesterday on another thread but it seems relevant here. I really wish MS would make something like this for .net core. I love c#, it's performant and easy to code in. Would love to have some sort of cross platform UI to go with it.

Here's hoping some Microsoft people are reading this

Mostly Qt, but also JavaFx (formerly Swing) when having to use some popular Java library or existing code.

I believe Kotlin will eat everybody's lunch real soon. Be prepared.

Why will it do that?

Red language

Is OSX support ready?

Check out their site red-lang.org. If I'm not wrong, it features the latest posts from their blog. That should tell you if it is ready, if you monitor it. Also, there was a fairly long and interesting thread about Red some days ago here, just like the recent interesting one about the D compiler being open sourced. It's been fun and educational to read the recent spate of programming language-related blog posts, for me. Hope it continues.

Should come with 0.6.3 release ASAP

After this comment I checked it out. This language is blowing my mind and I've only just got to how file writing/reading and conditionals work in the docs.

Feel free to ask any questions on gitter chat, it's always nice to see new faces!

Still missing the whole cross-platform GUI thing though.

    $ ./red
    Compiling compression library...
    Compiling Red console...
    --== Red 0.6.2 ==-- 
    Type HELP for starting information. 
    
    >> view [text "Hello World"]
    *** Script Error: view has no value
    *** Where: catch

Indeed, OSX is almost ready for launch (0.6.3 release), while Linux branch is stalled because of main contributor disappearance. Still looks very promising ;)

Depends on what platforms.

I'd choose C

what is your language of choice? javascript, perhaps?

Adobe Air?

Javafx

Reply on news.ycombinator.com