6 ms·

Every so often for the past several years I'll go evaluate options for cross-platform desktop app development and I always come back with an enormous handful of

Every so often for the past several years I'll go evaluate options for cross-platform desktop app development and I always come back with an enormous handful of options and all of which fall short on some measure. I would really think that this "problem" would have a great solution by now. But I think most of the developer attention is on web for obvious reasons (more ease, more conducive to mistakes/novices/etc). However I think there should be way more desktop apps. I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup, etc. I also like the general speed of desktop apps (though I know the web is trying to pull on more desktop/os resources) and I like the way desktop apps can interact with the host OS (creative windowing/sidebar/docking/etc and utilization of system tray/menu bar/etc.) I would much rather see my needs addressed by suites of standalone/private desktop apps than by a bunch of URLs and Saas's. Interestingly, the HN zeitgeist seems to recently be turning its awares back to this topic (it seesm to me from recent HN threads). Is it? And if so, I wonder why? What's in the air now?

lostmsu 8y ago
You should write a blog post with comparison!
stephenhuey 8y ago
Have you tried Rubymotion? It currently deploys to iOS, Android and OSX, but Amir, the new leader, is quite passionate about expanding and just deployed a popular Rubymotion app on the Nintendo Switch, so stay tuned for more platforms!
- wellpast 8y ago
  This is exactly what I'm talking about. There are SOOOO many options and all of them fall short. This one falls short in the extreme. I.e, no Windows support & it seems mobile-focused not desktop-focused. Not trying to be harsh and I bet this project has cool plans. But what worries me is that there are 100s of options in this space and _all_ of them are short. Why can't the passionate community rally behind one effort, and fully solve this problem? A solution doesn't seem to need to be programming language-specific, either, so that doesn't seem to be a good reason to keep 'forking' this problem.
Scarbutt 8y ago
I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup, etc. How would non-tech users handle backups?
- slantyyz 8y ago
  By copying a data file to a USB flash drive?
  - saagarjha 8y ago
    Anecdotal, but I don’t think many non-tech users have used a flash drive in the last couple years.
- wellpast 8y ago
  They could choose a Saas service (Dropbox, iCloud, WinBin/whatev). Hell, I'd probably do this but encrypted where I like. In this way you'd have the data storage decoupled from the app so the choice would be there.
RandallBrown 8y ago
Cross platform desktop app development will always fall short. Not all platforms have the same user interfaces/paradigms. What is the Windows equivalent of the OSX dock? What is Linux's equivalent? Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. (By second class I mean it's not what the OS authors intended their apps to be written in.)
- RussianCow 8y ago
  > Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. Isn't this throwing the baby out with the bathwater? Only a very small portion of your code should be platform-specific (10-20%?), which is still a huge win over maintaining multiple native apps. Of course, in practice, there are many other disadvantages of using cross-platform frameworks that may outweigh the benefits, such as the inevitable impedance mismatch between languages, APIs, concepts, etc.
- saagarjha 8y ago
  Lazy cross platform development will always fall: no solution will do the work of having to think of how your software will look on other platforms. With a bit of work, though, you can minimize this duplicate effort.
kllrnohj 8y ago
There's aspects of Flutter I don't like, but the cross-platform seems to strike a fairly compelling middle ground vs. what you've probably had experience with. It's almost like the C approach. There's the common stuff abstracted that's not particularly platform-specific (here's how you draw a red box, here's how you load a jpeg, etc...), and then all the really platform-specific things, like theming, is handled by just a handful of basically #ifdefs So much so that you literally have platform-specific widget implementations to go along with the platform-specific themes. Which sounds worse than it is, but defining new widgets is super easy. Not a write-once-run-everywhere but more like a write-1.2x-to-support-2-platforms type of thing. It risks being uncanny-valley at times, and implementation can drift from platform needing re-alignment, but it should let you do those really platform-specific stuff in sane enough ways.
s_y_n_t_a_x 8y ago
Copied from another comment on of mine so you see it: ReactXP (https://microsoft.github.io/reactxp/ https://microsoft.github.io/reactxp/) uses TypeScript and targets mobile and desktop platforms using native controls, not emulated controls. While Flutter doesn't work yet for desktop or web, ReactXP already works for these environments, and is used in the new Skype for Web. Windows support is done and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper.
mamcx 8y ago
As I write in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_what_a_good_gui_system_would_need/e51o6mw/ https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit. So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say: Form when(toolkit=UIKit) Field(UILabel="UserName", UiTextBox(PlaceHolder="Write your user") Field(Label="UserName", Edit(PlaceHolder="Write your user") to specialize per specific platform.
- pier25 8y ago
  So controllers and views?
  - mamcx 8y ago
    Yes, the "novel" idea is the split in the actual binaries/languages: Do the core on rust/c and the render on swift/kotlin/.net...
- yellowapple 8y ago
  Sounds like what Scenic's trying to do for Erlang/Elixir GUI programming, albeit at a lower level. Also sounds like what wxWidgets already does.
- ec109685 8y ago
  That’s what ReactNative does
  - mamcx 8y ago
    No. Almost. You must buy the whole Package with react and others. You don't code normal UI on Swift and still be part of the react world. Think is like build a JSON API. My idea is that. This mean that on the client, is full native (with some minimal coupling to the how transfer data).
csells 8y ago
I'm the PM for the Flutter developer experience. I'm currently digging into the next steps for our desktop experiment with Flutter and I'm very interested to hear how your xplat desktop app dev options fall short. What do you need from an xplay desktop app dev framework and toolchain? Chris Sells csells@google.com
- alasano 8y ago
  Unrelated question, when did you decide not to pursue a career in sales?
  - lone_haxx0r 8y ago
    He must have heard the same "joke" his entire life.
  - csells 8y ago
    I have heard variations of that most of my life. I always wanted to get into the Unix shell business on the coast so that the following would be true: "Chris Sells sells C-shells by the sea shore." Alas, another dream unrealized...
    - yellowapple 8y ago
      It's never too late :)
- deleted 8y ago
  [deleted]
- wellpast 8y ago
  Hi Chris, that's awesome! My (perhaps idiosyncratic?) priorities in order: - a ui programming model that is thoroughly thought-through. to be honest i think javafx fits this bill, it took long- hard-learned lessons from Swing but rebuilt things up from that learning. the scene graph api model imo is so ideal and then the way they build the widget/controls on top of that...creates a lot of flexibility yet remains simple - actually works reliably (ie, is production-quality) on all platforms * this is probably where 100s of these xplat desktop frameworks fall down. many are just so far from reliability - full support for building binaries (+ installers would make you really stand out! +, heck, streamlined app store deployment would be wow) for all major systems (mac, win, linux) ... ideally producing these all from one same build machine/os - solid set of optimized core widgets (all the stuff you'd expect in any widget toolkit...and performant...eg, the table widget should be optimized for unlimited records etc.. again javafx seemed to get it right w/ their tableview) - polyglot (again java/fx ... you can build in clojure, jruby, kotlin, etc etc) Where I depart from perhaps the majority is that I don't care about native LaF... and I suspect striving for native LaF is sort of at odds anyway with the xplat goal. So in my mind, I'm okay w/ non-native.. of course I do want ability to pixel push and have things look nice and I want things generally fast. (javafx again is doing something cool w/ its ability to style things in its 'css' support...) I can think of a lot of apps that don't use the native OS LaF and yet look great.. Spotify, for one, and there are many productivity-oriented apps in this list... Another.. I use Jetbrains IDE for developing in Java, Clojure, Ruby, Elm, Javascript, etc... and that app - afaik - is Swing-based and yet they have made a killer user-experience across the board imo.. I guess I just talked myself in to using JavaFX
AnIdiotOnTheNet 8y ago
> I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup Ah, but you see, the current crop of developers loves these things because you can make a lot of money when people have to pay you rent. They might talk a good game about open source and empowerment, but they're behavior says they'd rather make money.

lostmsu 8y ago

You should write a blog post with comparison!

stephenhuey 8y ago

Have you tried Rubymotion? It currently deploys to iOS, Android and OSX, but Amir, the new leader, is quite passionate about expanding and just deployed a popular Rubymotion app on the Nintendo Switch, so stay tuned for more platforms!

wellpast 8y ago
This is exactly what I'm talking about. There are SOOOO many options and all of them fall short. This one falls short in the extreme. I.e, no Windows support & it seems mobile-focused not desktop-focused. Not trying to be harsh and I bet this project has cool plans. But what worries me is that there are 100s of options in this space and _all_ of them are short. Why can't the passionate community rally behind one effort, and fully solve this problem? A solution doesn't seem to need to be programming language-specific, either, so that doesn't seem to be a good reason to keep 'forking' this problem.

Scarbutt 8y ago

I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup, etc. How would non-tech users handle backups?

slantyyz 8y ago
By copying a data file to a USB flash drive?
- saagarjha 8y ago
  Anecdotal, but I don’t think many non-tech users have used a flash drive in the last couple years.
wellpast 8y ago
They could choose a Saas service (Dropbox, iCloud, WinBin/whatev). Hell, I'd probably do this but encrypted where I like. In this way you'd have the data storage decoupled from the app so the choice would be there.

RandallBrown 8y ago

Cross platform desktop app development will always fall short. Not all platforms have the same user interfaces/paradigms. What is the Windows equivalent of the OSX dock? What is Linux's equivalent? Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. (By second class I mean it's not what the OS authors intended their apps to be written in.)

RussianCow 8y ago
> Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. Isn't this throwing the baby out with the bathwater? Only a very small portion of your code should be platform-specific (10-20%?), which is still a huge win over maintaining multiple native apps. Of course, in practice, there are many other disadvantages of using cross-platform frameworks that may outweigh the benefits, such as the inevitable impedance mismatch between languages, APIs, concepts, etc.
saagarjha 8y ago
Lazy cross platform development will always fall: no solution will do the work of having to think of how your software will look on other platforms. With a bit of work, though, you can minimize this duplicate effort.

kllrnohj 8y ago

There's aspects of Flutter I don't like, but the cross-platform seems to strike a fairly compelling middle ground vs. what you've probably had experience with. It's almost like the C approach. There's the common stuff abstracted that's not particularly platform-specific (here's how you draw a red box, here's how you load a jpeg, etc...), and then all the really platform-specific things, like theming, is handled by just a handful of basically #ifdefs So much so that you literally have platform-specific widget implementations to go along with the platform-specific themes. Which sounds worse than it is, but defining new widgets is super easy. Not a write-once-run-everywhere but more like a write-1.2x-to-support-2-platforms type of thing. It risks being uncanny-valley at times, and implementation can drift from platform needing re-alignment, but it should let you do those really platform-specific stuff in sane enough ways.

s_y_n_t_a_x 8y ago

Copied from another comment on of mine so you see it: ReactXP (https://microsoft.github.io/reactxp/ https://microsoft.github.io/reactxp/) uses TypeScript and targets mobile and desktop platforms using native controls, not emulated controls. While Flutter doesn't work yet for desktop or web, ReactXP already works for these environments, and is used in the new Skype for Web. Windows support is done and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper.

mamcx 8y ago

As I write in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_what_a_good_gui_system_would_need/e51o6mw/ https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit. So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say: Form when(toolkit=UIKit) Field(UILabel="UserName", UiTextBox(PlaceHolder="Write your user") Field(Label="UserName", Edit(PlaceHolder="Write your user") to specialize per specific platform.

pier25 8y ago
So controllers and views?
- mamcx 8y ago
  Yes, the "novel" idea is the split in the actual binaries/languages: Do the core on rust/c and the render on swift/kotlin/.net...
yellowapple 8y ago
Sounds like what Scenic's trying to do for Erlang/Elixir GUI programming, albeit at a lower level. Also sounds like what wxWidgets already does.
ec109685 8y ago
That’s what ReactNative does
- mamcx 8y ago
  No. Almost. You must buy the whole Package with react and others. You don't code normal UI on Swift and still be part of the react world. Think is like build a JSON API. My idea is that. This mean that on the client, is full native (with some minimal coupling to the how transfer data).

csells 8y ago

I'm the PM for the Flutter developer experience. I'm currently digging into the next steps for our desktop experiment with Flutter and I'm very interested to hear how your xplat desktop app dev options fall short. What do you need from an xplay desktop app dev framework and toolchain? Chris Sells csells@google.com

alasano 8y ago
Unrelated question, when did you decide not to pursue a career in sales?
- lone_haxx0r 8y ago
  He must have heard the same "joke" his entire life.
- csells 8y ago
  I have heard variations of that most of my life. I always wanted to get into the Unix shell business on the coast so that the following would be true: "Chris Sells sells C-shells by the sea shore." Alas, another dream unrealized...
  - yellowapple 8y ago
    It's never too late :)
deleted 8y ago
[deleted]
wellpast 8y ago
Hi Chris, that's awesome! My (perhaps idiosyncratic?) priorities in order: - a ui programming model that is thoroughly thought-through. to be honest i think javafx fits this bill, it took long- hard-learned lessons from Swing but rebuilt things up from that learning. the scene graph api model imo is so ideal and then the way they build the widget/controls on top of that...creates a lot of flexibility yet remains simple - actually works reliably (ie, is production-quality) on all platforms * this is probably where 100s of these xplat desktop frameworks fall down. many are just so far from reliability - full support for building binaries (+ installers would make you really stand out! +, heck, streamlined app store deployment would be wow) for all major systems (mac, win, linux) ... ideally producing these all from one same build machine/os - solid set of optimized core widgets (all the stuff you'd expect in any widget toolkit...and performant...eg, the table widget should be optimized for unlimited records etc.. again javafx seemed to get it right w/ their tableview) - polyglot (again java/fx ... you can build in clojure, jruby, kotlin, etc etc) Where I depart from perhaps the majority is that I don't care about native LaF... and I suspect striving for native LaF is sort of at odds anyway with the xplat goal. So in my mind, I'm okay w/ non-native.. of course I do want ability to pixel push and have things look nice and I want things generally fast. (javafx again is doing something cool w/ its ability to style things in its 'css' support...) I can think of a lot of apps that don't use the native OS LaF and yet look great.. Spotify, for one, and there are many productivity-oriented apps in this list... Another.. I use Jetbrains IDE for developing in Java, Clojure, Ruby, Elm, Javascript, etc... and that app - afaik - is Swing-based and yet they have made a killer user-experience across the board imo.. I guess I just talked myself in to using JavaFX

AnIdiotOnTheNet 8y ago

> I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup Ah, but you see, the current crop of developers loves these things because you can make a lot of money when people have to pay you rent. They might talk a good game about open source and empowerment, but they're behavior says they'd rather make money.