11 ms·

VS Code is an amazing piece of technology, despite all the "Electron hate" (although changing to WebView2). I recently commented on it here: https://news.ycom

VS Code is an amazing piece of technology, despite all the "Electron hate" (although changing to WebView2). I recently commented on it here: https://news.ycombinator.com/item?id=28556588 https://news.ycombinator.com/item?id=28556588 Microsoft engineers are top-notch and this is another feature I'll be using daily. Good stuff!

TeMPOraL 5y ago
VS Code is the benchmark of what can be done with Electron - if you really, really care. But it's an extreme outlier. The hate for Electron comes from how the average Electron application works. Not only almost nobody cares as much as VS Code team does, the very choice of using Electron itself is usually an act of not caring.
- flohofwoe 5y ago
  But this is also why simply switching to OS-native APIs and compiled languages wouldn't help much for the average case. A team that doesn't care about performance in Electron also wouldn't care about peformance in native applications, and performance isn't some magic pixie dust that automatically appears when chosing a different UI framework or programming language, it needs to be actively worked towards (some YMMV of course).
  - IshKebab 5y ago
    > performance isn't some magic pixie dust that automatically appears when chosing a different UI framework or programming language That's a little misleading. If you write the same program in idiomatic C++ and Python then it's almost guaranteed that the C++ version will be much much faster even before you have done any profiling or performance optimisation. So there is some magic pixie dust.
    - goldenkey 5y ago
      C++ doesn't give you asymptotic Big(O) algorithmic superpowers. No language does.
      - r-w 5y ago
        We're talking about small, quick operations supporting a synchronous, interactive user interface here. When it comes to performance, asymptotics aren't everything.
        goldenkey 5y ago
        JS has Workers. VS Code uses them wisely. Other Electron apps? Not so much. Block the event loop in other languages and you'll also see shitty results..
        xg15 5y ago
        Have fun implementing all the overhead just communicating with those workers. That's a serialisation pass, a serialisation pass and two event queues, all just so your application doesn't lock up.
        goldenkey 5y ago
        https://developers.google.com/web/updates/2011/09/Workers-ArrayBuffer https://developers.google.com/web/updates/2011/09/Workers-Ar... For 10 years an ArrayBuffer has been able to be sent by reference but good effort on disinformation.
        int_19h 5y ago
        You still need to serialize/deserialize to put your object graph into the array, no?
        goldenkey 5y ago
        Not if you use WebAssembly. You can simply pass an Array Buffer to be worked on, you postMessage it with transferable=true. transfer Optional An optional array of Transferable objects to transfer ownership of. If the ownership of an object is transferred, it becomes unusable in the context it was sent from and becomes available only to the worker it was sent to. You can compile JS itself or pretty much any other language to WASM using Emscripten or the other LLVM toolkits. Looking at VSCode, it appears they use this technique for some of the heavy lifting. JS is very performant if you know how to use this hybrid architecture. The C++ guys above are shitting all over JS when an Electron app can simply use C++ transpiled to WASM if they really wanted to. Electron isn't really for JS as a coding language. It is much more for the awesome cross-platform UI you get with HTML, CSS, and JS. A lot has been done to optimize rendering engines. The same techniques that render snappy web pages can be used within Electron. All the griping above is really just ignorance. https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=arraybuffer https://github.com/microsoft/vscode/search?q=arraybuffer https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t... https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
    - maccard 5y ago
      For a crud style app, the difference in performance between python and C++ is going to be absolutely negligible. The Python version might use more resources, and if you profile it, it might show up with a couple hotspots, but you're still going to have a responsive desktop app if it's implemented properly. The slowdown is architectural or design based. Sending one HTTP request and not updating your UI until the request has completed fully is going to have _way_ more of an impact on the perceived performance and responsiveness of a native app.
  - drchickensalad 5y ago
    Yeah there's definitely some YMMV. An efficient baseline does continuously yield performance benefits, even if inefficiencies are layered on top.
  - jjoonathan 5y ago
    Ehh... there's more than a little YMMV: every ecosystem has common, least-effort paths with certain performance characteristics and those characteristics vary greatly depending on language.
  - darksaints 5y ago
    It absolutely would help. It's practically tautological to say that you can create bad performance in any language, but that ignores the very real fact that some languages and systems just perform better for any given coding skill level. With native apps, you have to be extremely bad at coding to get bad performance. With electron, you have to be extremely good at coding to get good performance. VSCode is the exception, not the rule. Even then, it's a pretty poor exception. The "good" performance of VSCode doesn't scale. It's a pretty barebones editor by itself, and once you load it down with extensions, it slows down quite significantly. The python extension, also written by Microsoft, is one that was bad enough to make me leave VSCode for good.
  - girvo 5y ago
    The base performance of a native app in most operating systems is higher than the base performance of your average electron app though, in my experience.
    - Cthulhu_ 5y ago
      You're not wrong, but what about feature sets? The only native IDE I can think of is xcode, the rest are either big Java ones or are lacking in features.
- gpderetta 5y ago
  emacs has been an usable and relatively fast editor built on top of a fairly slow interpreted language. In comparison JS and V8 should be significantly faster. As you say, the issue is usually the layers of layers of layers of sometimes gratuitous abstractions build on top of some applications.
  - trey-jones 5y ago
    emacs also has the advantage of 40 years of existence, and perhaps most importantly for performance: the ability (requirement?) to choose exactly what functionality you want to load.
  - TeMPOraL 5y ago
    > built on top of a fairly slow interpreted language Correction: built on top of a bytecode-compiled language that, few years ago, became a native-compiled language (both AOT and JIT) - initially as an experiment/optional feature, and as of ~5 months ago, this has been merged into the main repo branch.
    - gpderetta 5y ago
      Of course, I'm an happy user of native-comp as well. Still for most of its history emacs got by with a not exactly state of the art interpreter.
  - npigrounet 5y ago
    VSCode did more in a few years than emacs did in 40 years.
- dr-detroit 5y ago
  99% of use cases are for things that dont need a GUI but most devs run on auto pilot.
- UglyToad 5y ago
  > the very choice of using Electron itself is usually an act of not caring. Hmm, not sure I buy this, sure it's not as fast as going native on every platform. But let's be honest the alternative isn't 3-4 native applications built with care for each special little subgroup. It's a MacOS only app in the US market or a Windows only app everywhere else. Businesses don't have an unlimited amount of money to spend addressing every tiny market so I'd say the complainer's focus should be on building a better X-plat story if they really care rather than whinging that some application isn't built to make the most of the 0.1% of the addressable market they find themselves in.
  - sudosysgen 5y ago
    Unless you need to run on mobile, Qt is the answer.
    - finiteseries 5y ago
      That’s the dream, and it stays a dream most of the time. Business concerns pop up again when it comes to building out teams for Qt based desktop apps. Electron comes with an enormous, deep, absolutely stupid big pool of web developers. I genuinely can’t emphasize enough how big it is, and how easy it is to hire from. Montevideo, Montenegro, Monterrey, doesn’t matter. Hot, not particularly expensive developers are ready to churn out React UIs in your area!
      - a1369209993 5y ago
        > Electron comes with an enormous, deep, absolutely stupid big pool of web developers. Looks at the web. As Linus Torvalds put it, it's worth writing the whole thing in C for no other reason than to prevent those 'developers' from 'contributing' to it.
    - npigrounet 5y ago
      Qt runs like shit compared to Electron, and its license prices are way too expensive. Moreover it's C++ so a deprecated, unsafe, un-cool and uninteresting dying language no one wants to write anymore.
- dspillett 5y ago
  > The hate for Electron comes from how the average Electron application works. A lot of it, given the comments I see in relevant threads, comes from the inefficiency of every electron app having its own copies of node and chromium in memory (and on disk, and being transferred over the network when installed/updated, though those are smaller issues than run-time performance). Though that is unavoidable given how it works unless particular LTS versions can be enforced so everything is tested against those making sharing easier/possible. I'm not sure how much of an issue it really is anyway: how many people are running several instances of Electron applications at once? Also I get the impression that a fair amount of it comes from people who are parroting what appears to be a popular sentiment, without actually understanding or having skin in the game! This says something disappointing about technical communities.
  - npigrounet 5y ago
    Electron apps running at the same time: VSCode, Slack, Discord, Signal, Bitwarden, Teams... Most of the apps are made with Electron now. It's an exception when something isn't made in web technologies, nowadays.
- sidcool 5y ago
  What did Microsoft specifically do in case of VS Code to make it so well even with Electron?
  - inDigiNeous 5y ago
    Even with Electron ? They put a lot of thought into it like you should when designing any application for any platform. They also have a team of very competent senior developers who have previous experience with developing IDEs like Eclipse.
  - Jensson 5y ago
    They use the WASM runtime instead of just running Javascript.
- Waterluvian 5y ago
  Perhaps it’s because Electron opens the door to a ton of applications that wouldn’t have existed before, so the average skews. A lot of people complaining that Electron makes people choose an “act of not caring” but nobody actually does anything about it. Last I checked Electron didn’t make other UI kits go away. I’m not without criticism for Electron. But I begin from a position of good faith on the subject, and appreciate that a lot of these apps simply wouldn’t have existed otherwise.
  - npigrounet 5y ago
    Electron is a gift from the gods. Finally, an almost perfect, fast, lightweight cross-platform UI framework exists and we should be glad.
- int_19h 5y ago
  And even VSCode had issues like https://github.com/microsoft/vscode/issues/22900 https://github.com/microsoft/vscode/issues/22900
doodpants 5y ago
I don't use VS Code, but I like having it installed; I'll occasionally launch it just to watch it update itself and/or its extensions, and enjoy the dopamine hit that comes from the satisfaction of getting my software up-to-date.
- lpcvoid 5y ago
  This is the most hacker-news comment I have ever seen.
robertoandred 5y ago
And yet Electron still doesn't have native file functionality on macOS titlebars.
dstaley 5y ago
Wait, is the hate transitioning to WebView2 or is VS Code? If the latter, do you have a source? WebView2 is a Windows-only API, so I don't think it'd be a good match for VS Code.
- ripley12 5y ago
  WebView2 will be coming to macOS then Linux in the not-so-distant future: https://github.com/MicrosoftEdge/WebView2Feedback/issues/645#issuecomment-731474506 https://github.com/MicrosoftEdge/WebView2Feedback/issues/645... I'm not aware of any public plans to move VS Code to WebView2, but I would be surprised if it doesn't happen eventually.

TeMPOraL 5y ago

VS Code is the benchmark of what can be done with Electron - if you really, really care. But it's an extreme outlier. The hate for Electron comes from how the average Electron application works. Not only almost nobody cares as much as VS Code team does, the very choice of using Electron itself is usually an act of not caring.

flohofwoe 5y ago
But this is also why simply switching to OS-native APIs and compiled languages wouldn't help much for the average case. A team that doesn't care about performance in Electron also wouldn't care about peformance in native applications, and performance isn't some magic pixie dust that automatically appears when chosing a different UI framework or programming language, it needs to be actively worked towards (some YMMV of course).
- IshKebab 5y ago
  > performance isn't some magic pixie dust that automatically appears when chosing a different UI framework or programming language That's a little misleading. If you write the same program in idiomatic C++ and Python then it's almost guaranteed that the C++ version will be much much faster even before you have done any profiling or performance optimisation. So there is some magic pixie dust.
  - goldenkey 5y ago
    C++ doesn't give you asymptotic Big(O) algorithmic superpowers. No language does.
    - r-w 5y ago
      We're talking about small, quick operations supporting a synchronous, interactive user interface here. When it comes to performance, asymptotics aren't everything.
      - goldenkey 5y ago
        JS has Workers. VS Code uses them wisely. Other Electron apps? Not so much. Block the event loop in other languages and you'll also see shitty results..
        xg15 5y ago
        Have fun implementing all the overhead just communicating with those workers. That's a serialisation pass, a serialisation pass and two event queues, all just so your application doesn't lock up.
        goldenkey 5y ago
        https://developers.google.com/web/updates/2011/09/Workers-ArrayBuffer https://developers.google.com/web/updates/2011/09/Workers-Ar... For 10 years an ArrayBuffer has been able to be sent by reference but good effort on disinformation.
        int_19h 5y ago
        You still need to serialize/deserialize to put your object graph into the array, no?
        goldenkey 5y ago
        Not if you use WebAssembly. You can simply pass an Array Buffer to be worked on, you postMessage it with transferable=true. transfer Optional An optional array of Transferable objects to transfer ownership of. If the ownership of an object is transferred, it becomes unusable in the context it was sent from and becomes available only to the worker it was sent to. You can compile JS itself or pretty much any other language to WASM using Emscripten or the other LLVM toolkits. Looking at VSCode, it appears they use this technique for some of the heavy lifting. JS is very performant if you know how to use this hybrid architecture. The C++ guys above are shitting all over JS when an Electron app can simply use C++ transpiled to WASM if they really wanted to. Electron isn't really for JS as a coding language. It is much more for the awesome cross-platform UI you get with HTML, CSS, and JS. A lot has been done to optimize rendering engines. The same techniques that render snappy web pages can be used within Electron. All the griping above is really just ignorance. https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=wasm https://github.com/microsoft/vscode/search?q=arraybuffer https://github.com/microsoft/vscode/search?q=arraybuffer https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t... https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
  - maccard 5y ago
    For a crud style app, the difference in performance between python and C++ is going to be absolutely negligible. The Python version might use more resources, and if you profile it, it might show up with a couple hotspots, but you're still going to have a responsive desktop app if it's implemented properly. The slowdown is architectural or design based. Sending one HTTP request and not updating your UI until the request has completed fully is going to have _way_ more of an impact on the perceived performance and responsiveness of a native app.
- drchickensalad 5y ago
  Yeah there's definitely some YMMV. An efficient baseline does continuously yield performance benefits, even if inefficiencies are layered on top.
- jjoonathan 5y ago
  Ehh... there's more than a little YMMV: every ecosystem has common, least-effort paths with certain performance characteristics and those characteristics vary greatly depending on language.
- darksaints 5y ago
  It absolutely would help. It's practically tautological to say that you can create bad performance in any language, but that ignores the very real fact that some languages and systems just perform better for any given coding skill level. With native apps, you have to be extremely bad at coding to get bad performance. With electron, you have to be extremely good at coding to get good performance. VSCode is the exception, not the rule. Even then, it's a pretty poor exception. The "good" performance of VSCode doesn't scale. It's a pretty barebones editor by itself, and once you load it down with extensions, it slows down quite significantly. The python extension, also written by Microsoft, is one that was bad enough to make me leave VSCode for good.
- girvo 5y ago
  The base performance of a native app in most operating systems is higher than the base performance of your average electron app though, in my experience.
  - Cthulhu_ 5y ago
    You're not wrong, but what about feature sets? The only native IDE I can think of is xcode, the rest are either big Java ones or are lacking in features.
gpderetta 5y ago
emacs has been an usable and relatively fast editor built on top of a fairly slow interpreted language. In comparison JS and V8 should be significantly faster. As you say, the issue is usually the layers of layers of layers of sometimes gratuitous abstractions build on top of some applications.
- trey-jones 5y ago
  emacs also has the advantage of 40 years of existence, and perhaps most importantly for performance: the ability (requirement?) to choose exactly what functionality you want to load.
- TeMPOraL 5y ago
  > built on top of a fairly slow interpreted language Correction: built on top of a bytecode-compiled language that, few years ago, became a native-compiled language (both AOT and JIT) - initially as an experiment/optional feature, and as of ~5 months ago, this has been merged into the main repo branch.
  - gpderetta 5y ago
    Of course, I'm an happy user of native-comp as well. Still for most of its history emacs got by with a not exactly state of the art interpreter.
- npigrounet 5y ago
  VSCode did more in a few years than emacs did in 40 years.
dr-detroit 5y ago
99% of use cases are for things that dont need a GUI but most devs run on auto pilot.
UglyToad 5y ago
> the very choice of using Electron itself is usually an act of not caring. Hmm, not sure I buy this, sure it's not as fast as going native on every platform. But let's be honest the alternative isn't 3-4 native applications built with care for each special little subgroup. It's a MacOS only app in the US market or a Windows only app everywhere else. Businesses don't have an unlimited amount of money to spend addressing every tiny market so I'd say the complainer's focus should be on building a better X-plat story if they really care rather than whinging that some application isn't built to make the most of the 0.1% of the addressable market they find themselves in.
- sudosysgen 5y ago
  Unless you need to run on mobile, Qt is the answer.
  - finiteseries 5y ago
    That’s the dream, and it stays a dream most of the time. Business concerns pop up again when it comes to building out teams for Qt based desktop apps. Electron comes with an enormous, deep, absolutely stupid big pool of web developers. I genuinely can’t emphasize enough how big it is, and how easy it is to hire from. Montevideo, Montenegro, Monterrey, doesn’t matter. Hot, not particularly expensive developers are ready to churn out React UIs in your area!
    - a1369209993 5y ago
      > Electron comes with an enormous, deep, absolutely stupid big pool of web developers. Looks at the web. As Linus Torvalds put it, it's worth writing the whole thing in C for no other reason than to prevent those 'developers' from 'contributing' to it.
  - npigrounet 5y ago
    Qt runs like shit compared to Electron, and its license prices are way too expensive. Moreover it's C++ so a deprecated, unsafe, un-cool and uninteresting dying language no one wants to write anymore.
dspillett 5y ago
> The hate for Electron comes from how the average Electron application works. A lot of it, given the comments I see in relevant threads, comes from the inefficiency of every electron app having its own copies of node and chromium in memory (and on disk, and being transferred over the network when installed/updated, though those are smaller issues than run-time performance). Though that is unavoidable given how it works unless particular LTS versions can be enforced so everything is tested against those making sharing easier/possible. I'm not sure how much of an issue it really is anyway: how many people are running several instances of Electron applications at once? Also I get the impression that a fair amount of it comes from people who are parroting what appears to be a popular sentiment, without actually understanding or having skin in the game! This says something disappointing about technical communities.
- npigrounet 5y ago
  Electron apps running at the same time: VSCode, Slack, Discord, Signal, Bitwarden, Teams... Most of the apps are made with Electron now. It's an exception when something isn't made in web technologies, nowadays.
sidcool 5y ago
What did Microsoft specifically do in case of VS Code to make it so well even with Electron?
- inDigiNeous 5y ago
  Even with Electron ? They put a lot of thought into it like you should when designing any application for any platform. They also have a team of very competent senior developers who have previous experience with developing IDEs like Eclipse.
- Jensson 5y ago
  They use the WASM runtime instead of just running Javascript.
Waterluvian 5y ago
Perhaps it’s because Electron opens the door to a ton of applications that wouldn’t have existed before, so the average skews. A lot of people complaining that Electron makes people choose an “act of not caring” but nobody actually does anything about it. Last I checked Electron didn’t make other UI kits go away. I’m not without criticism for Electron. But I begin from a position of good faith on the subject, and appreciate that a lot of these apps simply wouldn’t have existed otherwise.
- npigrounet 5y ago
  Electron is a gift from the gods. Finally, an almost perfect, fast, lightweight cross-platform UI framework exists and we should be glad.
int_19h 5y ago
And even VSCode had issues like https://github.com/microsoft/vscode/issues/22900 https://github.com/microsoft/vscode/issues/22900

doodpants 5y ago

I don't use VS Code, but I like having it installed; I'll occasionally launch it just to watch it update itself and/or its extensions, and enjoy the dopamine hit that comes from the satisfaction of getting my software up-to-date.

lpcvoid 5y ago
This is the most hacker-news comment I have ever seen.

robertoandred 5y ago

And yet Electron still doesn't have native file functionality on macOS titlebars.

dstaley 5y ago

Wait, is the hate transitioning to WebView2 or is VS Code? If the latter, do you have a source? WebView2 is a Windows-only API, so I don't think it'd be a good match for VS Code.

ripley12 5y ago
WebView2 will be coming to macOS then Linux in the not-so-distant future: https://github.com/MicrosoftEdge/WebView2Feedback/issues/645#issuecomment-731474506 https://github.com/MicrosoftEdge/WebView2Feedback/issues/645... I'm not aware of any public plans to move VS Code to WebView2, but I would be surprised if it doesn't happen eventually.