10 ms·

The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge. Note the word 'viable'. Those who might suggest that Qt cover

The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge. Note the word 'viable'. Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it. This is the point about Clojurescript too: yes it compiles slower and runs slower, but it allows access to what is essentially the world's largest and most complete UI framework, known as the browser. That makes apps cheaper and faster to produce, at the cost of sluggish/bloated performance. The market has indicated that this is an acceptable tradeoff. Until some other solution can match it on these axes, Electron/Javascript/React SPAs will dominate. I work with a Qt-like C++ GUI framework (JUCE), but we've seen increasing portions of our front-end work replaced with Electron/React Native. It saddens me to see binary sizes and memory consumption balloon, because native development encourages you to care about these things. But even I cannot deny the order-of-magnitude improvements in productivity from hot-reloading, a deep (if byzantine) system for styling and layout (including text), and reuse of modular components across all platforms.

devxpy 8y ago
Speaking of "a viable, efficient, native and cross-platform GUI solution", I have high hopes for flutter.
- dangoor 8y ago
  Can Flutter really be called "native", though? As I understand it, it operates like Swing: it draws all of its own widgets. They do their best to emulate the platform's widgets, but it's not using the native APIs for them.
  - devxpy 8y ago
    Yes, you are correct. I think Flutter means native in the sense that it runs at native speed, perhaps even faster in some carefully selected apps As for a look and feel thing, Flutter widgets feel alright to me..
    - kkarakk 8y ago
      i'm seeing a lot of complaints on iOS flutter apps of how the UI looks(microstutters/not frame perfect). it's only the usual small vocal minority but boy do they kill your app's reception on the programmer heavy social media
      - devxpy 8y ago
        Can you link a specific issue that wasn't immediately a result of a problem with the user code, perhaps too much work on the main thread? I have found the perf to be just fantastic on android. Especially compared to react native, which is a native offering.
        kkarakk 8y ago
        android is fine,it's the iOS side that complains
- naavis 8y ago
  AFAIK Flutter is "only" for Android and iOS, excluding desktop applications.
  - HALtheWise 8y ago
    There are people successfully running Flutter on desktops, but it isn't currently the main thrust of the project. https://medium.com/flutter-community/flutter-on-desktop-a-real-competitor-to-electron-4f049ea6b061 https://medium.com/flutter-community/flutter-on-desktop-a-re...
  - devxpy 8y ago
    The flutter team has announced that it is now working on desktop and web ports of flutter. What's interesting is that you can literally run the same app on all platforms, because flutter draws the whole ui in dart code, using the canvas. And well, dart can run basically anywhere now...
- rvanmil 8y ago
  I wish I could share this sentiment because Flutter really does look great, but I don't think it will succeed as long as it's based on Dart and not JavaScript.
  - devxpy 8y ago
    That's very bold, considering the popularity of JavaScript, an esoteric, joke of a language in earlier times (no offence). Bottom line, Its very safe to say that dart is a much better language than JS. The language of choice has never ever, really mattered in software history. And don't forget that the big G is behind this thing, which is well equipped to push it forward without the need of it being as popular as js.
    - pjmlp 8y ago
      The big G dropped the ball on Dart 1.0, which was rescued by the AdWords team. Right now Flutter/Dart looks like an ongoing political war between ChromeOS, Android and Fuchsia. By the way, Fuchsia is getting Android suport and a new language agnostic UI composition engine, Scenic, so lets see for how long Flutter stays as the Fuchsia official UI toolkit.
      - devxpy 8y ago
        Nice point about fushsia. But isn't the point of a truly cross platform framework just that? So what if fuschia has a different native toolkit. Maybe they are trying to launch a platform specific api that's more bare metal. I mean Isn't the whole point of flutter is that you take the same app and run it anywhere?
      - cube2222 8y ago
        What do you mean with "Fuchsia is getting Android support"?
        pjmlp 8y ago
        Android is being ported to work on Fuchsia as well, just like it happened with ChromeOS. https://android-review.googlesource.com/q/fuchsia https://android-review.googlesource.com/q/fuchsia
mamcx 8y ago
> The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge FreePascal have one. TCL, before. The bigger problem, I think, is the language tie-in. For get the amazing Delphi/FreePascal UI you need to work with pascal. To get TCL-UI, you need to work with TCL. This mean anybody that not want to code on that not even consider the option. And how integrate your language of choice? You need to pass by C. C sucks. SUCKS SUCKS SUCKS. Is so bad that is the glue for native development. In the other hand, Elector/React Native is tied-in with JS. If C sucks, JS sucks even more, BUT, you DO NOT HAVE A CHOICE. Is Js or the highway by proxy of the browser. So, even if you code in other language, you MUST (not everyone, but enough) soon or later to accept this fate. And interface with JS is not as bad as with C.
- zozbot123 8y ago
  > The bigger problem, I think, is the language tie-in. Same issue with WxWidgets, which is otherwise great - AIUI, it was started as a C++98-ish library with support for lots of pre-standard compilers, and a lot of its deep weirdness is a direct consequence of that. OTOH, at least it has good bindings for other languages like wxPython.
  - zakius 8y ago
    looking at available bindings I guess c++ is still the least terrible choice this or JS one yeah, I know, there are some py lovers but I can't stand this thing
- pinum 8y ago
  >C sucks. SUCKS SUCKS SUCKS. The more of my project I can write in C, the happier I am.
  - fouric 8y ago
    People sometimes irrationally like sucky things. C's memory model, type system, and feature set are sorely lacking by modern standards.
jcelerier 8y ago
> I work with a Qt-like C++ GUI framework (JUCE), but we've seen increasing portions of our front-end work replaced with Electron/React Native. working on Max/MSP by any chance ? > Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it. But someone built Telegram with it, which is of fairly equivalent complexity (https://aozoeky4dglp5sh0-zippykid.netdna-ssl.com/wp-content/uploads/2017/05/telegram-calls-desktop.jpg https://aozoeky4dglp5sh0-zippykid.netdna-ssl.com/wp-content/...). Besides, I'd say that there are enough quality Qt apps in the KDE ecosystem to not need $ELECTRON app :-) just yesterday Krita was making the highlights for instance. Likewise, I doubt people being used to the power and speed of KDevelop or QtCreator would feel the need to switch to VSCode. Even going outside of the "libre" ecosystem, there are many many many nice-looking recent apps written with it... take a look at substance painter (https://www.allegorithmic.com/sites/default/files/DML_1.jpg https://www.allegorithmic.com/sites/default/files/DML_1.jpg), the Blizzard launcher (https://i.kinja-img.com/gawker-media/image/upload/s--zbfvud8U--/c_fill,fl_progressive,g_center,h_900,q_80,w_1600/px2wqtkhkhhzsrhi7ppi.jpg https://i.kinja-img.com/gawker-media/image/upload/s--zbfvud8...), Native Access (https://support.native-instruments.com/hc/article_attachments/115011032025/K11U_EM.png https://support.native-instruments.com/hc/article_attachment...)...
- wlesieutre 8y ago
  I haven't used Allegorithmic's stuff recently, but my previous experience was that it's neigh unusable on a Mac laptop. Much worse than anything I've experienced in electron. Substance Designer is a giant graph editor that should be perfect for multitouch trackpad pan/zoom gestures, but it doesn't support them. To zoom in and out you scroll up and down as if you're using a mouse wheel, but moving your fingers about 1mm will zip you instantly past where you were trying to get. And IIRC it expects a middle mouse button that you can drag to pan; on a laptop you get to two-finger-drag while holding down Option. Electron, being based on a web browser, is probably easier to set up for various input types beyond keyboard and mouse. EDIT: Here's an old video I recorded of the trackpad zoom. If you look very very very closely you might see my fingers move. https://gfycat.com/FlippantBonyHusky https://gfycat.com/FlippantBonyHusky TLDR cross platform UIs still take work
devwastaken 8y ago
I think a lot of it is that browsers are far superior in creating the design you want. You may have to work around things, but you don't have to learn completely new things that are only for your application. If you learn to make great looking and functional websites then you can make that into electron. Add to the fact that many services want to have a desktop and web application, it just makes a lot more sense to design its core in Js in a browser environment As for the obligatory "qt can do that" qt uses chromium to do browser related tasks. The alternative is webviews which are unreliable in any full sized application.
- fiddlerwoaroof 8y ago
  To some degree I think the desire to have “any design you want” is anti-user: I really don’t want to use apps that have the design their developer picked for me, I want to use apps that respect the conventions of my system and the preferences I have set (e.g. on Mac, I want the accent color to be the one _I_ picked in System Preferences. On Linux, I want the apps to fit in with my choice of gtk or qt theme.) These days Qt is fairly close to this ideal, even on Mac: apps like calibre look a bit weird but their menus are in the right place and their coloring roughly matches my os settings. Electron apps are all over the place: vscode, slack, etc. all pick their own design styles and ruin the visual consistency of my desktop.
  - mercer 8y ago
    Comparing Calibre favorably to VSCode and Slack highlights how different perhaps audiences are: while I love what Calibre does, I really dislike its interface and vastly prefer VSCode and Slack.
    - fiddlerwoaroof 8y ago
      I actually agree with that overall. The point was more that Qt has come a long way towards integrating with OS X. For an apples-to-apples comparison, I’d rather use Slack through something like Adium that puts me in control of the ui. And VSCode would be nicer if it looked more like textmate.
bytematic 8y ago
Not to mention a huge pool of talent for JavaScript devs
pjmlp 8y ago
> Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it. Because those are companies dominated by webdevs that can't be bothered to learn anything else. Even VSCode is probably a side effect of Microsoft trying to be cool and cattering to the new generations that don't know anything else. For me, it just made me buy a Sublime Text license instead.
- 21 8y ago
  The Visual Studio Installer was rewritten from a native app to an Electron one. They had a native app. They decided to throw it all away.
  - pragmatic 8y ago
    Can you elaborate on that?
    - pjmlp 8y ago
      The JavaScript camp inside WinDev managed to get Electron to replace the WPF installer for VS 2017.
  - zakius 8y ago
    it's amusing how they managed to make the new installer as bad as old one was
- devxpy 8y ago
  > Because those are companies dominated by webdevs that can't be bothered to learn anything else. Tell me about it!
- bunderbunder 8y ago
  VSCode grew out of a project to make a browser-based IDE. So, when they decided to make a desktop-like user experience instead, Electron was the natural choice, as a way to make it a port rather than a complete rewrite. You could argue that it's a similar story for things like Slack - for business reasons, they more-or-less needed to have a web-based UI. If you're already committed to that, then it makes sense to use Electron in order to maximize your code reuse. I can't speak to Discord or Atom. Those ones make less sense to me, but there might be a reason there, too. Speaking completely personally, Qt has never felt like a viable option for a commercial project to me. It does have some bindings for other languages, but, at least last I checked, they're all community supported. When you're talking about language binding libraries, it's reasonable to think of "community" as a polite way of saying "poorly". That can quite justifiably influence a person's willingness to rely on them for non-hobby projects. I don't like JavaScript much better than I like C++, but at least I can more easily think of business cases for why I might accept being locked into JavaScript. The ones up above, for example.
disishhsha 8y ago
To be more specific about the value here: Maintaining parity between two applications running on different GUI platforms is very expensive - much more than twice the effort of maintaining a single codebase.
- pseudalopex 8y ago
  Not at all. Core logic can be shared. Single-platform frameworks usually have large libraries of well-tested controls. You can often get good performance, OS integration, and accessibility without really trying.
ken 8y ago
"Emerge" is a very interesting choice of word. Why do we think that a property like "interoperability" could be emergent? Has it ever been? Web browser developers have shown by example that you can come up with a sophisticated standard, including executable code, have everybody implement it on their platform, beat them into compliance with cool validation tests, and even starting with one of the worst possible architectures for performance (sending raw JavaScript code over the wire!) make it perform far better than anyone might have reasonably expected. Meanwhile, operating system vendors are doubling down on proprietary APIs. These days you practically need to use the right programming language for your OS, too. A whole lot of groups seem to have completely missed the web's lesson. Instead of "standardization is great", they heard "HTML/CSS/JS is the ideal substrate for writing applications".

devxpy 8y ago

Speaking of "a viable, efficient, native and cross-platform GUI solution", I have high hopes for flutter.

dangoor 8y ago
Can Flutter really be called "native", though? As I understand it, it operates like Swing: it draws all of its own widgets. They do their best to emulate the platform's widgets, but it's not using the native APIs for them.
- devxpy 8y ago
  Yes, you are correct. I think Flutter means native in the sense that it runs at native speed, perhaps even faster in some carefully selected apps As for a look and feel thing, Flutter widgets feel alright to me..
  - kkarakk 8y ago
    i'm seeing a lot of complaints on iOS flutter apps of how the UI looks(microstutters/not frame perfect). it's only the usual small vocal minority but boy do they kill your app's reception on the programmer heavy social media
    - devxpy 8y ago
      Can you link a specific issue that wasn't immediately a result of a problem with the user code, perhaps too much work on the main thread? I have found the perf to be just fantastic on android. Especially compared to react native, which is a native offering.
      - kkarakk 8y ago
        android is fine,it's the iOS side that complains
naavis 8y ago
AFAIK Flutter is "only" for Android and iOS, excluding desktop applications.
- HALtheWise 8y ago
  There are people successfully running Flutter on desktops, but it isn't currently the main thrust of the project. https://medium.com/flutter-community/flutter-on-desktop-a-real-competitor-to-electron-4f049ea6b061 https://medium.com/flutter-community/flutter-on-desktop-a-re...
- devxpy 8y ago
  The flutter team has announced that it is now working on desktop and web ports of flutter. What's interesting is that you can literally run the same app on all platforms, because flutter draws the whole ui in dart code, using the canvas. And well, dart can run basically anywhere now...
rvanmil 8y ago
I wish I could share this sentiment because Flutter really does look great, but I don't think it will succeed as long as it's based on Dart and not JavaScript.
- devxpy 8y ago
  That's very bold, considering the popularity of JavaScript, an esoteric, joke of a language in earlier times (no offence). Bottom line, Its very safe to say that dart is a much better language than JS. The language of choice has never ever, really mattered in software history. And don't forget that the big G is behind this thing, which is well equipped to push it forward without the need of it being as popular as js.
  - pjmlp 8y ago
    The big G dropped the ball on Dart 1.0, which was rescued by the AdWords team. Right now Flutter/Dart looks like an ongoing political war between ChromeOS, Android and Fuchsia. By the way, Fuchsia is getting Android suport and a new language agnostic UI composition engine, Scenic, so lets see for how long Flutter stays as the Fuchsia official UI toolkit.
    - devxpy 8y ago
      Nice point about fushsia. But isn't the point of a truly cross platform framework just that? So what if fuschia has a different native toolkit. Maybe they are trying to launch a platform specific api that's more bare metal. I mean Isn't the whole point of flutter is that you take the same app and run it anywhere?
    - cube2222 8y ago
      What do you mean with "Fuchsia is getting Android support"?
      - pjmlp 8y ago
        Android is being ported to work on Fuchsia as well, just like it happened with ChromeOS. https://android-review.googlesource.com/q/fuchsia https://android-review.googlesource.com/q/fuchsia

mamcx 8y ago

> The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge FreePascal have one. TCL, before. The bigger problem, I think, is the language tie-in. For get the amazing Delphi/FreePascal UI you need to work with pascal. To get TCL-UI, you need to work with TCL. This mean anybody that not want to code on that not even consider the option. And how integrate your language of choice? You need to pass by C. C sucks. SUCKS SUCKS SUCKS. Is so bad that is the glue for native development. In the other hand, Elector/React Native is tied-in with JS. If C sucks, JS sucks even more, BUT, you DO NOT HAVE A CHOICE. Is Js or the highway by proxy of the browser. So, even if you code in other language, you MUST (not everyone, but enough) soon or later to accept this fate. And interface with JS is not as bad as with C.

zozbot123 8y ago
> The bigger problem, I think, is the language tie-in. Same issue with WxWidgets, which is otherwise great - AIUI, it was started as a C++98-ish library with support for lots of pre-standard compilers, and a lot of its deep weirdness is a direct consequence of that. OTOH, at least it has good bindings for other languages like wxPython.
- zakius 8y ago
  looking at available bindings I guess c++ is still the least terrible choice this or JS one yeah, I know, there are some py lovers but I can't stand this thing
pinum 8y ago
>C sucks. SUCKS SUCKS SUCKS. The more of my project I can write in C, the happier I am.
- fouric 8y ago
  People sometimes irrationally like sucky things. C's memory model, type system, and feature set are sorely lacking by modern standards.

jcelerier 8y ago

> I work with a Qt-like C++ GUI framework (JUCE), but we've seen increasing portions of our front-end work replaced with Electron/React Native. working on Max/MSP by any chance ? > Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it. But someone built Telegram with it, which is of fairly equivalent complexity (https://aozoeky4dglp5sh0-zippykid.netdna-ssl.com/wp-content/uploads/2017/05/telegram-calls-desktop.jpg https://aozoeky4dglp5sh0-zippykid.netdna-ssl.com/wp-content/...). Besides, I'd say that there are enough quality Qt apps in the KDE ecosystem to not need $ELECTRON app :-) just yesterday Krita was making the highlights for instance. Likewise, I doubt people being used to the power and speed of KDevelop or QtCreator would feel the need to switch to VSCode. Even going outside of the "libre" ecosystem, there are many many many nice-looking recent apps written with it... take a look at substance painter (https://www.allegorithmic.com/sites/default/files/DML_1.jpg https://www.allegorithmic.com/sites/default/files/DML_1.jpg), the Blizzard launcher (https://i.kinja-img.com/gawker-media/image/upload/s--zbfvud8U--/c_fill,fl_progressive,g_center,h_900,q_80,w_1600/px2wqtkhkhhzsrhi7ppi.jpg https://i.kinja-img.com/gawker-media/image/upload/s--zbfvud8...), Native Access (https://support.native-instruments.com/hc/article_attachments/115011032025/K11U_EM.png https://support.native-instruments.com/hc/article_attachment...)...

wlesieutre 8y ago
I haven't used Allegorithmic's stuff recently, but my previous experience was that it's neigh unusable on a Mac laptop. Much worse than anything I've experienced in electron. Substance Designer is a giant graph editor that should be perfect for multitouch trackpad pan/zoom gestures, but it doesn't support them. To zoom in and out you scroll up and down as if you're using a mouse wheel, but moving your fingers about 1mm will zip you instantly past where you were trying to get. And IIRC it expects a middle mouse button that you can drag to pan; on a laptop you get to two-finger-drag while holding down Option. Electron, being based on a web browser, is probably easier to set up for various input types beyond keyboard and mouse. EDIT: Here's an old video I recorded of the trackpad zoom. If you look very very very closely you might see my fingers move. https://gfycat.com/FlippantBonyHusky https://gfycat.com/FlippantBonyHusky TLDR cross platform UIs still take work

devwastaken 8y ago

I think a lot of it is that browsers are far superior in creating the design you want. You may have to work around things, but you don't have to learn completely new things that are only for your application. If you learn to make great looking and functional websites then you can make that into electron. Add to the fact that many services want to have a desktop and web application, it just makes a lot more sense to design its core in Js in a browser environment As for the obligatory "qt can do that" qt uses chromium to do browser related tasks. The alternative is webviews which are unreliable in any full sized application.

fiddlerwoaroof 8y ago
To some degree I think the desire to have “any design you want” is anti-user: I really don’t want to use apps that have the design their developer picked for me, I want to use apps that respect the conventions of my system and the preferences I have set (e.g. on Mac, I want the accent color to be the one _I_ picked in System Preferences. On Linux, I want the apps to fit in with my choice of gtk or qt theme.) These days Qt is fairly close to this ideal, even on Mac: apps like calibre look a bit weird but their menus are in the right place and their coloring roughly matches my os settings. Electron apps are all over the place: vscode, slack, etc. all pick their own design styles and ruin the visual consistency of my desktop.
- mercer 8y ago
  Comparing Calibre favorably to VSCode and Slack highlights how different perhaps audiences are: while I love what Calibre does, I really dislike its interface and vastly prefer VSCode and Slack.
  - fiddlerwoaroof 8y ago
    I actually agree with that overall. The point was more that Qt has come a long way towards integrating with OS X. For an apples-to-apples comparison, I’d rather use Slack through something like Adium that puts me in control of the ui. And VSCode would be nicer if it looked more like textmate.

bytematic 8y ago

Not to mention a huge pool of talent for JavaScript devs

pjmlp 8y ago

> Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it. Because those are companies dominated by webdevs that can't be bothered to learn anything else. Even VSCode is probably a side effect of Microsoft trying to be cool and cattering to the new generations that don't know anything else. For me, it just made me buy a Sublime Text license instead.

21 8y ago
The Visual Studio Installer was rewritten from a native app to an Electron one. They had a native app. They decided to throw it all away.
- pragmatic 8y ago
  Can you elaborate on that?
  - pjmlp 8y ago
    The JavaScript camp inside WinDev managed to get Electron to replace the WPF installer for VS 2017.
- zakius 8y ago
  it's amusing how they managed to make the new installer as bad as old one was
devxpy 8y ago
> Because those are companies dominated by webdevs that can't be bothered to learn anything else. Tell me about it!
bunderbunder 8y ago
VSCode grew out of a project to make a browser-based IDE. So, when they decided to make a desktop-like user experience instead, Electron was the natural choice, as a way to make it a port rather than a complete rewrite. You could argue that it's a similar story for things like Slack - for business reasons, they more-or-less needed to have a web-based UI. If you're already committed to that, then it makes sense to use Electron in order to maximize your code reuse. I can't speak to Discord or Atom. Those ones make less sense to me, but there might be a reason there, too. Speaking completely personally, Qt has never felt like a viable option for a commercial project to me. It does have some bindings for other languages, but, at least last I checked, they're all community supported. When you're talking about language binding libraries, it's reasonable to think of "community" as a polite way of saying "poorly". That can quite justifiably influence a person's willingness to rely on them for non-hobby projects. I don't like JavaScript much better than I like C++, but at least I can more easily think of business cases for why I might accept being locked into JavaScript. The ones up above, for example.

disishhsha 8y ago

To be more specific about the value here: Maintaining parity between two applications running on different GUI platforms is very expensive - much more than twice the effort of maintaining a single codebase.

pseudalopex 8y ago
Not at all. Core logic can be shared. Single-platform frameworks usually have large libraries of well-tested controls. You can often get good performance, OS integration, and accessibility without really trying.

ken 8y ago

"Emerge" is a very interesting choice of word. Why do we think that a property like "interoperability" could be emergent? Has it ever been? Web browser developers have shown by example that you can come up with a sophisticated standard, including executable code, have everybody implement it on their platform, beat them into compliance with cool validation tests, and even starting with one of the worst possible architectures for performance (sending raw JavaScript code over the wire!) make it perform far better than anyone might have reasonably expected. Meanwhile, operating system vendors are doubling down on proprietary APIs. These days you practically need to use the right programming language for your OS, too. A whole lot of groups seem to have completely missed the web's lesson. Instead of "standardization is great", they heard "HTML/CSS/JS is the ideal substrate for writing applications".