13 ms·

Qt may not 'look' native, but it has native performance, whereas Electron really doesn't.

thawaway1837 6y ago
Isn’t that more of an Electron issue? I mean, is anyone clamouring for VS Code, for example, to be rewritten in native toolkits?
outside1234 6y ago
VSCode is indistinguishable from native, so not sure its Electron that's at fault here.
- eyegor 6y ago
  If I recall correctly, Microsoft forked their own version of electron to make vs code feel more snappy. Because normal electron runs like slack.
  - RMPR 6y ago
    I don't think so, Microsoft wanted to fork electron in the past to replace Chromium with edgeHTML, but it didn't happen. VSCode is powered by Monaco Editor github.com/microsoft/monaco-editor, and VSCode feels snappier than let's say Atom, probably because of Typescript.
- andai 6y ago
  If your native apps are indistinguishable from VSCode, they're doing something wrong.
- AlchemistCamp 6y ago
  No. I like VS Code but it's a hog. I still use Macvim or even Sublime Text a lot for speed reasons, especially on large files.
- voltagex_ 6y ago
  Start Notepad++ or https://github.com/rxi/lite https://github.com/rxi/lite and then compare the startup speed with VSCode.
- drngdds 6y ago
  I use VS Code daily (because it seems to be the only full-featured editor that Just Works(TM) with WSL), but it can get pretty sluggish, especially with the Vim plugin.
- keb_ 6y ago
  This gets said a lot, and granted VSCode is certainly one of the best performing Electron apps, but it definitely is not indistinguishable from native apps. Sublime, Notepad++, or TextAdept all fly compared to VSCode in terms of performance and RAM efficiency.
- fiddlerwoaroof 6y ago
  On Mac, VSCode does a better job than many apps at emulating the Cocoa text input systems but, like every electron app, it misses some of the obscure corners of cocoa text input system that I use frequently. If we’re going to use JavaScript to write native apps, I’d really like to see things like React Native take off: with a good set of components implemented, it would be a first class environment.
- meritt 6y ago
  Try opening a moderately large (even 2MB) .json file in VSCode, and then do the same in sublime. VSCode very quickly freezes because it cannot handle a file that size. Sublime not only opens it but syntax highlights immediately.
  - inapis 6y ago
    This is something with your configuration. OOB VSCode will immediately show you the file but disable tokenization and certain other features. I regularly open JSON files upto 10 MB in size without any problem. You probably have plugins which impede this process.
    - deleted 6y ago
      [deleted]
- dep_b 6y ago
  Try to use AppleScript or Accessibility. It's like VS Code doesn't even exists.
madeofpalk 6y ago
I would argue that the web platform is one of the most optimised and performant platforms for apps.
- wolco 6y ago
  When you say web platform do you mean a browser? Using a browser is the mosted optimised and performant over installing an application on your desktop? Curious what desktop do you run your browser under? I would give you an example of a simple video split application. A web platform requires uploading, downloading and slow processing. A local app would be hours quicker as the data is local.
  - cglong 6y ago
    No reason a video splitting app couldn't be written with client-side JS.
    - saagarjha 6y ago
      That sounds like it’d probably be slow.
- boomlinde 6y ago
  So please do.
userbinator 6y ago
The difference between "Qt native" and "native native" (e.g. Win32 or Cocoa) is still noticeable if you pay attention, although it's not quite as obvious as between Electron and the former. (Likewise, applications using the JVM may also look very convincingly like native ones, but you will feel it as soon as you start interacting with them.)
- nv-vn 6y ago
  Is it really even worth highlighting though? I use Telegram Desktop (Qt) daily and it is always, 100% of the time completely responsive. It launches basically instantly the second I click the icon and the UI never hangs or lags behind input to a noticeable degree. If we transitioned to a world where everyone was writing Qt instead of Electron apps we would already have a huge win.
- catblast 6y ago
  If you're using KDE, Qt is "native native". You're fundamentally mistaken about where Qt sits in the stack - it effectively sits in the same place as USER32/WinForms in Windows or NS/Cocoa GUI widgets of OSX. It is reasonable to think of it as an alternative native GUI library in that sense. If it is slower, it's because an implementation of something is slower, not because of where it lives or an abstraction cost. Qt pretty much draws using low-level drawing APIs on the respective platform. And although Qt itself is not written in the most performance sensitive C++, it is still orders of magnitude faster than most (and it's not like Chrome doesn't pay overhead) - people rag on vtable dispatch speed but jeez its still orders of magnitude faster than something like ObjC which served Apple quite well for years. The performance of a Qt app is more likely a function of the app itself and how the app developers wrote it. But no, you're not noticing any micro-seconds differences in C++ overhead for Qt over "native native" - and you're basically comparing the GUI code of the platform - since Qt does it's own rendering. Win32 is mostly pretty good, NS is a mixed bag, and Gtk+ is basically a slug. In all cases there is some kind of dynamic dispatch going on, because that is a fundamental pattern of most GUI libraries. But dynamic dispatch is almost never a factor in GUI render performance. Things like recalculating sizes for 1 million items in a table on every repaint are the things that get people into trouble, and that is regardless of GUI library.

Isn’t that more of an Electron issue? I mean, is anyone clamouring for VS Code, for example, to be rewritten in native toolkits?

outside1234 6y ago

VSCode is indistinguishable from native, so not sure its Electron that's at fault here.

eyegor 6y ago
If I recall correctly, Microsoft forked their own version of electron to make vs code feel more snappy. Because normal electron runs like slack.
- RMPR 6y ago
  I don't think so, Microsoft wanted to fork electron in the past to replace Chromium with edgeHTML, but it didn't happen. VSCode is powered by Monaco Editor github.com/microsoft/monaco-editor, and VSCode feels snappier than let's say Atom, probably because of Typescript.
andai 6y ago
If your native apps are indistinguishable from VSCode, they're doing something wrong.
AlchemistCamp 6y ago
No. I like VS Code but it's a hog. I still use Macvim or even Sublime Text a lot for speed reasons, especially on large files.
voltagex_ 6y ago
Start Notepad++ or https://github.com/rxi/lite https://github.com/rxi/lite and then compare the startup speed with VSCode.
drngdds 6y ago
I use VS Code daily (because it seems to be the only full-featured editor that Just Works(TM) with WSL), but it can get pretty sluggish, especially with the Vim plugin.
keb_ 6y ago
This gets said a lot, and granted VSCode is certainly one of the best performing Electron apps, but it definitely is not indistinguishable from native apps. Sublime, Notepad++, or TextAdept all fly compared to VSCode in terms of performance and RAM efficiency.
fiddlerwoaroof 6y ago
On Mac, VSCode does a better job than many apps at emulating the Cocoa text input systems but, like every electron app, it misses some of the obscure corners of cocoa text input system that I use frequently. If we’re going to use JavaScript to write native apps, I’d really like to see things like React Native take off: with a good set of components implemented, it would be a first class environment.
meritt 6y ago
Try opening a moderately large (even 2MB) .json file in VSCode, and then do the same in sublime. VSCode very quickly freezes because it cannot handle a file that size. Sublime not only opens it but syntax highlights immediately.
- inapis 6y ago
  This is something with your configuration. OOB VSCode will immediately show you the file but disable tokenization and certain other features. I regularly open JSON files upto 10 MB in size without any problem. You probably have plugins which impede this process.
  - deleted 6y ago
    [deleted]
dep_b 6y ago
Try to use AppleScript or Accessibility. It's like VS Code doesn't even exists.

madeofpalk 6y ago

I would argue that the web platform is one of the most optimised and performant platforms for apps.

wolco 6y ago
When you say web platform do you mean a browser? Using a browser is the mosted optimised and performant over installing an application on your desktop? Curious what desktop do you run your browser under? I would give you an example of a simple video split application. A web platform requires uploading, downloading and slow processing. A local app would be hours quicker as the data is local.
- cglong 6y ago
  No reason a video splitting app couldn't be written with client-side JS.
  - saagarjha 6y ago
    That sounds like it’d probably be slow.
boomlinde 6y ago
So please do.

userbinator 6y ago

The difference between "Qt native" and "native native" (e.g. Win32 or Cocoa) is still noticeable if you pay attention, although it's not quite as obvious as between Electron and the former. (Likewise, applications using the JVM may also look very convincingly like native ones, but you will feel it as soon as you start interacting with them.)

nv-vn 6y ago
Is it really even worth highlighting though? I use Telegram Desktop (Qt) daily and it is always, 100% of the time completely responsive. It launches basically instantly the second I click the icon and the UI never hangs or lags behind input to a noticeable degree. If we transitioned to a world where everyone was writing Qt instead of Electron apps we would already have a huge win.
catblast 6y ago
If you're using KDE, Qt is "native native". You're fundamentally mistaken about where Qt sits in the stack - it effectively sits in the same place as USER32/WinForms in Windows or NS/Cocoa GUI widgets of OSX. It is reasonable to think of it as an alternative native GUI library in that sense. If it is slower, it's because an implementation of something is slower, not because of where it lives or an abstraction cost. Qt pretty much draws using low-level drawing APIs on the respective platform. And although Qt itself is not written in the most performance sensitive C++, it is still orders of magnitude faster than most (and it's not like Chrome doesn't pay overhead) - people rag on vtable dispatch speed but jeez its still orders of magnitude faster than something like ObjC which served Apple quite well for years. The performance of a Qt app is more likely a function of the app itself and how the app developers wrote it. But no, you're not noticing any micro-seconds differences in C++ overhead for Qt over "native native" - and you're basically comparing the GUI code of the platform - since Qt does it's own rendering. Win32 is mostly pretty good, NS is a mixed bag, and Gtk+ is basically a slug. In all cases there is some kind of dynamic dispatch going on, because that is a fundamental pattern of most GUI libraries. But dynamic dispatch is almost never a factor in GUI render performance. Things like recalculating sizes for 1 million items in a table on every repaint are the things that get people into trouble, and that is regardless of GUI library.