6 ms·

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

allover 10y ago
If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.
- simplyinfinity 10y ago
  js community is filled with 20-somethings with ADHD (i'm 26) that reinvent the wheel every 2 weeks instead of helping polish other projects.
- stock_toaster 10y ago
  "If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants." Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.
  - abiox 10y ago
    > Use the right tools for the job i wonder if this expression constitutes a thought-terminating cliché.
    - KirinDave 10y ago
      It does, inasmuch as objective metrics for "correctness" don't exist in our field. The best we can do is show "incorrectness." It's absurd to say, "My tool is correct and therefore should be used," when all we really can demonstrate is, "My tool lacks these specific deficiencies I can identify in another choice." This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incorrect tools
      - deleted 10y ago
        [deleted]
    - Qwertious 10y ago
      It sounds a bit like one, but I think the point is that while the web can be used for everything, that doesn't mean it should. Like if we built XML into filesystems directly, instead of doing it just in the layers above.
  - allover 10y ago
    > Trying to shoehorn everything into "the web" 'Trying to shoehorn' is just your opinion. > Use the right tools for the job. What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies. Or should I use Qt, with it's tiny support community? Also why is React/React-Native not 'the right tool'? > [...] just as shitty as the web. Again your opinion. In my opinion the web is a joy to work on compared to the cesspool that is native app development.
    - KirinDave 10y ago
      It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable. "Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to invalidate the project. By the way, if you'd like to really throw a stick into Qt proponents spokes, ask them what sort of accessibility story QT has for custom rendering components. Ask, "How can I support a colorblind or legally blind person with this component?" Qt's developer story here is not nonexistent, but it throws into sharp contrast how _complete_ the web is from the perspective of accessibility for people who need auditory assistance or do not use conventional input devices.
      - deleted 10y ago
        [deleted]
      - allover 10y ago
        Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.
        allover 10y ago
        If you disagree, tell me what I should use instead of Electron, that is feasible to use for a small team to have a wide platform reach, and with a community comparable to even just the 'React' part of web dev. The drive-by downvotes really just prove my point.
- reitanqild 10y ago
  As someone who maintain other peoples code I really don't look forward to deal with js a few years from now: What build system did they use? Where is that package? Does it even exist anymore. Etc. Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.
  - mvindahl 10y ago
    Typically in Javascript, you would use npm's package.json for building, or you would use npm to install some well defined version of some build system, like you do for other packages. Like Maven builds, it works smoothly and predictably.
  - KirinDave 10y ago
    It's true, but there is an interesting mitigating effect here. If at some point you come across an old project that appears to be a product of herculean effort, note that these days its a matter of a few days effort. The platform that JS is based upon moves incredibly fast.
- problems 10y ago
  If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, are generally slow, massive to distribute, don't integrate well with other applications and generally have weird non-native-app-like behavior. Like Discord I can resize and have the minimize/maximize/close buttons overlap the window. Atom and VS Code still can't do DPI scaling right. I wouldn't say you can build good desktop apps with them. Just crappy little ones. Maybe that's necessary to interact with one library or another, but that's a tradeoff. And a big and important one to recognize. Maybe React Native will work on desktop and fix all this eventually, but IMO React Native is just not there yet, it doesn't even feel native on mobile. I say this as someone who writes both an app with both an Electron/React portion (in order mainly to interact with a specific JS library) and a Qt portion. I really do like the way React does a lot of things and npm seems like the exact right way to do package management in a programming language - but the JS ecosystem is a mess. While I'll agree the wealth of developers on it has had many good results, it's also created a horrible moving target. There are half at least 5 different and fairly popular module systems, module loaders, etc. There are constant attempts to use language features which aren't official yet or even at a final spec via babel. The build and packing systems are a mess, everyone has their own different series they prefer and getting working integration between a few can be problematic.
  - KirinDave 10y ago
    > If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing hours people spend are already mitigated by their web browser of choice, and that seems to not really cause any substantial problems. Electron is a flawed framework for building an app, sure, but you could argue Cocoa or Windows Universal are equally flawed in many ways. They also require a lot more code to get equivalent layouts, are almost never very good at reactively resizing (you may say it doesn't matter, I say I unplug in an external monitor and expect to have something sane happen). The fact that a bug exist causing repeated simple draws to be more expensive than expected is normal for text editors. You can find issues caused by similar problems in Sublime, Emacs, and even Notepad++.
skc 10y ago
Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane. That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.
- flukus 10y ago
  It also suffers similar problems to the one posted here (or at least used to), an idle app will consume quite a bit of CPU.
  - skc 10y ago
    A WPF app is just a .Net app. I can't recall the problem described ever having been an issue.
- rpeden 10y ago
  Avalonia is a decently nice cross platform C# + XAML GUI toolkit. It doesn't cover every use case WPF does, of course, but I've still found it pleasant to use.
Razengan 10y ago
AppKit/Cocoa is very good too, if not cross-platform. Consistent, dynamic, extensible, and there's so much your apps get for free, and new features often become retroactively available for past apps, like when NSDocument got autosaving, and now tabs for multi-document apps, the wide-gamut-aware color pickers and so on.
flukus 10y ago
A project I've been keeping my eye on is libui (https://github.com/andlabs/libui https://github.com/andlabs/libui), it's basically a thin wrapper around the native libraries (very SWT like) that can be used in a number of languages.
KirinDave 10y ago
I have done both and I am not at all a fan of QT.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

allover 10y ago

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.

simplyinfinity 10y ago
js community is filled with 20-somethings with ADHD (i'm 26) that reinvent the wheel every 2 weeks instead of helping polish other projects.
stock_toaster 10y ago
"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants." Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.
- abiox 10y ago
  > Use the right tools for the job i wonder if this expression constitutes a thought-terminating cliché.
  - KirinDave 10y ago
    It does, inasmuch as objective metrics for "correctness" don't exist in our field. The best we can do is show "incorrectness." It's absurd to say, "My tool is correct and therefore should be used," when all we really can demonstrate is, "My tool lacks these specific deficiencies I can identify in another choice." This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incorrect tools
    - deleted 10y ago
      [deleted]
  - Qwertious 10y ago
    It sounds a bit like one, but I think the point is that while the web can be used for everything, that doesn't mean it should. Like if we built XML into filesystems directly, instead of doing it just in the layers above.
- allover 10y ago
  > Trying to shoehorn everything into "the web" 'Trying to shoehorn' is just your opinion. > Use the right tools for the job. What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies. Or should I use Qt, with it's tiny support community? Also why is React/React-Native not 'the right tool'? > [...] just as shitty as the web. Again your opinion. In my opinion the web is a joy to work on compared to the cesspool that is native app development.
  - KirinDave 10y ago
    It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable. "Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to invalidate the project. By the way, if you'd like to really throw a stick into Qt proponents spokes, ask them what sort of accessibility story QT has for custom rendering components. Ask, "How can I support a colorblind or legally blind person with this component?" Qt's developer story here is not nonexistent, but it throws into sharp contrast how _complete_ the web is from the perspective of accessibility for people who need auditory assistance or do not use conventional input devices.
    - deleted 10y ago
      [deleted]
    - allover 10y ago
      Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.
      - allover 10y ago
        If you disagree, tell me what I should use instead of Electron, that is feasible to use for a small team to have a wide platform reach, and with a community comparable to even just the 'React' part of web dev. The drive-by downvotes really just prove my point.
reitanqild 10y ago
As someone who maintain other peoples code I really don't look forward to deal with js a few years from now: What build system did they use? Where is that package? Does it even exist anymore. Etc. Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.
- mvindahl 10y ago
  Typically in Javascript, you would use npm's package.json for building, or you would use npm to install some well defined version of some build system, like you do for other packages. Like Maven builds, it works smoothly and predictably.
- KirinDave 10y ago
  It's true, but there is an interesting mitigating effect here. If at some point you come across an old project that appears to be a product of herculean effort, note that these days its a matter of a few days effort. The platform that JS is based upon moves incredibly fast.
problems 10y ago
If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, are generally slow, massive to distribute, don't integrate well with other applications and generally have weird non-native-app-like behavior. Like Discord I can resize and have the minimize/maximize/close buttons overlap the window. Atom and VS Code still can't do DPI scaling right. I wouldn't say you can build good desktop apps with them. Just crappy little ones. Maybe that's necessary to interact with one library or another, but that's a tradeoff. And a big and important one to recognize. Maybe React Native will work on desktop and fix all this eventually, but IMO React Native is just not there yet, it doesn't even feel native on mobile. I say this as someone who writes both an app with both an Electron/React portion (in order mainly to interact with a specific JS library) and a Qt portion. I really do like the way React does a lot of things and npm seems like the exact right way to do package management in a programming language - but the JS ecosystem is a mess. While I'll agree the wealth of developers on it has had many good results, it's also created a horrible moving target. There are half at least 5 different and fairly popular module systems, module loaders, etc. There are constant attempts to use language features which aren't official yet or even at a final spec via babel. The build and packing systems are a mess, everyone has their own different series they prefer and getting working integration between a few can be problematic.
- KirinDave 10y ago
  > If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing hours people spend are already mitigated by their web browser of choice, and that seems to not really cause any substantial problems. Electron is a flawed framework for building an app, sure, but you could argue Cocoa or Windows Universal are equally flawed in many ways. They also require a lot more code to get equivalent layouts, are almost never very good at reactively resizing (you may say it doesn't matter, I say I unplug in an external monitor and expect to have something sane happen). The fact that a bug exist causing repeated simple draws to be more expensive than expected is normal for text editors. You can find issues caused by similar problems in Sublime, Emacs, and even Notepad++.

skc 10y ago

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane. That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

flukus 10y ago
It also suffers similar problems to the one posted here (or at least used to), an idle app will consume quite a bit of CPU.
- skc 10y ago
  A WPF app is just a .Net app. I can't recall the problem described ever having been an issue.
rpeden 10y ago
Avalonia is a decently nice cross platform C# + XAML GUI toolkit. It doesn't cover every use case WPF does, of course, but I've still found it pleasant to use.

Razengan 10y ago

AppKit/Cocoa is very good too, if not cross-platform. Consistent, dynamic, extensible, and there's so much your apps get for free, and new features often become retroactively available for past apps, like when NSDocument got autosaving, and now tabs for multi-document apps, the wide-gamut-aware color pickers and so on.

flukus 10y ago

A project I've been keeping my eye on is libui (https://github.com/andlabs/libui https://github.com/andlabs/libui), it's basically a thin wrapper around the native libraries (very SWT like) that can be used in a number of languages.

KirinDave 10y ago

I have done both and I am not at all a fan of QT.