4 ms·

I think this is great, especially for the electron ecosystem as github engineers are directly involved in making production apps on the stack(other than atom)

I think this is great, especially for the electron ecosystem as github engineers are directly involved in making production apps on the stack(other than atom) The cross platform advantage(time & maintenance effort) that electron gives is immense. The overhead is very minimal and we can build some great apps like vscode and the likes have shown.

devwastaken 9y ago
>The overhead is very minimal You're still using JS, unless you're compiling modules for node.js.
- murukesh_s 9y ago
  I find node.js pretty fast. The V8 engine does compile it to native during the run time using a JIT compiler. While it is not quite up to the level of java, it is comparable. The major lacking is no thread support, but it is a boon in many cases as tracking down runtime bugs in multi threaded environments is sometimes very tough. Threads can be simulated using child processes to some extend, but its the only major drawback as far as i have encountered.
  - GRiMe2D 9y ago
    While nodejs is fast enough, Electron and apps built on it aren't fast. Electron is a mix of Chromium and nodejs. Chromium's rendering isn't meant to be used as desktop app. Especially for laptops. I have a MacBook pro mid 2010 with two GPUs. Integrated GPU uses less battery energy than discrete one. And every Chromium app switches GPU to discrete one and causes battery drain.
    - dragonwriter 9y ago
      > Chromium's rendering isn't meant to be used as desktop app. Yes, it is. That was pretty much the entire point of Google making Chrome (to make web apps have acceptable parity with desktop apps), and the entire premise of them building on Chrome with ChromeOS. Now, it may not satisfy you in that role, but it absolutely is meant for it.
      - murukesh_s 9y ago
        Good point. People are bashing Electron and chromium in general. But they do forget JVM based IDEs had the same problem. Rather than bashing Electron, if we can figure out to make it more leaner and faster, it would be much better.
        LeoNatan25 9y ago
        "We"? You mean people that know C++ and low level native APIs, right? Which is decidedly not you. You are building a "hackable" "node.js" "npm" "app". The problem is, people who are indeed capable of making some improvements, including people on the V8 and WebKit teams themselves, do not believe in what these tools attempt to accomplish. (Listen to Don Melton's interviews on the subject, for example.) I say "some improvements, as the problem cannot be solved completely; you'd understand why if you understood the underlying technology.
stephenr 9y ago
> The overhead is very minimal Compared to what exactly? Because compared to an app built using the platform SDK's, Electron is never "minimal" in anything, except perhaps "integration" or "accessibility".
- gjjrfcbugxbhf 9y ago
  Minimal regard for the users' system resources? Minimal chance of being used because the user notices their laptop grinds to a halt and then runs out of power when the app is opened?
  - stephenr 9y ago
    Well played.
- murukesh_s 9y ago
  Don't want to create a flame war, but let's look at real world stats, at least for me, the overhead is very minimal. Look at the screenshot of my macbook pro 2013. I am running vscode for 100% of my development time. In the graph, I have sorted the processes by CPU Time (Not just CPU). That is the average amount of CPU used by each process over time. I have also included memory usage. While the total memory comes to around 400mb, it's still lesser than some Java based IDEs. For an app that I use as my main IDE, the resource usage (CPU) is very minimal. cpu usage https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 memory usage https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0 https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0
  - stephenr 9y ago
    > it's still lesser than some Java based IDEs Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix, you can't really call editors like VSCode/Atom/etc an IDE. The functionality is nowhere near the same. I don't like relying on a Java tool. IDEA Ultimate uses a lot of memory. But it has a lot of functionality too, which is why I accept the JVM overhead. If someone produced a fully featured IDE (or even plugins e.g. for Xcode) for macOS that was a true native app, I'd use that. But that doesn't exist. The options for me are: true native editors (Coda, TextMate, CotEdit, etc), web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a NetBeans/etc setup).

devwastaken 9y ago

>The overhead is very minimal You're still using JS, unless you're compiling modules for node.js.

murukesh_s 9y ago
I find node.js pretty fast. The V8 engine does compile it to native during the run time using a JIT compiler. While it is not quite up to the level of java, it is comparable. The major lacking is no thread support, but it is a boon in many cases as tracking down runtime bugs in multi threaded environments is sometimes very tough. Threads can be simulated using child processes to some extend, but its the only major drawback as far as i have encountered.
- GRiMe2D 9y ago
  While nodejs is fast enough, Electron and apps built on it aren't fast. Electron is a mix of Chromium and nodejs. Chromium's rendering isn't meant to be used as desktop app. Especially for laptops. I have a MacBook pro mid 2010 with two GPUs. Integrated GPU uses less battery energy than discrete one. And every Chromium app switches GPU to discrete one and causes battery drain.
  - dragonwriter 9y ago
    > Chromium's rendering isn't meant to be used as desktop app. Yes, it is. That was pretty much the entire point of Google making Chrome (to make web apps have acceptable parity with desktop apps), and the entire premise of them building on Chrome with ChromeOS. Now, it may not satisfy you in that role, but it absolutely is meant for it.
    - murukesh_s 9y ago
      Good point. People are bashing Electron and chromium in general. But they do forget JVM based IDEs had the same problem. Rather than bashing Electron, if we can figure out to make it more leaner and faster, it would be much better.
      - LeoNatan25 9y ago
        "We"? You mean people that know C++ and low level native APIs, right? Which is decidedly not you. You are building a "hackable" "node.js" "npm" "app". The problem is, people who are indeed capable of making some improvements, including people on the V8 and WebKit teams themselves, do not believe in what these tools attempt to accomplish. (Listen to Don Melton's interviews on the subject, for example.) I say "some improvements, as the problem cannot be solved completely; you'd understand why if you understood the underlying technology.

stephenr 9y ago

> The overhead is very minimal Compared to what exactly? Because compared to an app built using the platform SDK's, Electron is never "minimal" in anything, except perhaps "integration" or "accessibility".

gjjrfcbugxbhf 9y ago
Minimal regard for the users' system resources? Minimal chance of being used because the user notices their laptop grinds to a halt and then runs out of power when the app is opened?
- stephenr 9y ago
  Well played.
murukesh_s 9y ago
Don't want to create a flame war, but let's look at real world stats, at least for me, the overhead is very minimal. Look at the screenshot of my macbook pro 2013. I am running vscode for 100% of my development time. In the graph, I have sorted the processes by CPU Time (Not just CPU). That is the average amount of CPU used by each process over time. I have also included memory usage. While the total memory comes to around 400mb, it's still lesser than some Java based IDEs. For an app that I use as my main IDE, the resource usage (CPU) is very minimal. cpu usage https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0 memory usage https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0 https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0
- stephenr 9y ago
  > it's still lesser than some Java based IDEs Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix, you can't really call editors like VSCode/Atom/etc an IDE. The functionality is nowhere near the same. I don't like relying on a Java tool. IDEA Ultimate uses a lot of memory. But it has a lot of functionality too, which is why I accept the JVM overhead. If someone produced a fully featured IDE (or even plugins e.g. for Xcode) for macOS that was a true native app, I'd use that. But that doesn't exist. The options for me are: true native editors (Coda, TextMate, CotEdit, etc), web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a NetBeans/etc setup).