Hacker News Reader

Comment by murukesh_s | Hacker News Reader

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.

View on HN

> 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".

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?

Well played.

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

memory usage https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0

> 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).

> But it has a lot of functionality too, which is why I accept the JVM overhead

This is something that can be replicated with additional plugins. To be honest, I have used Eclipse and Netbeans extensively. They do have additional features, but not a lot.

If I am not wrong, VSCode ships with a debugger and syntax highlighter built-in. There are tons of other plugins to add the extra functionality like GIT integration, built-in terminal, more syntax highlighting etc (Nowadays, you name it you have it). Even if you add 10 such plugins you are noway near a JVM based IDE on memory consumption. Also Netbeaans is very very slow, atleast in perception. Eclipse feels snappy, due to the use of SWT, but its a memory hog.

I'm talking about stuff like:

- Static analysis of code

  - Find calls to methods

  - Find usage of Classes/Interfaces/Variables

  - Alert when classes don't properly implement interfaces/abstract methods

  - Detect language-level syntax/feature changes/compatibility

- Code refactoring

  - Rename variables/classes/interfaces

  - Change method signatures

  - Pull/push methods to parent/child classes

Most of the above features dont need constant monitoring, so adding a plugin for that purpose won't add any large overhead. And many plugins do similar tasks in Atom/VSCode with minimal overhead. Even for continuous monitoring of filesystem, node.js is very fast(there are many native plugins).

Disclaimer: I am developing an IDE using electron for a visual programming language. I have worked on JRE based IDE toolkits before (SWT/Swing). Both the runtime performance and developer experience appear better to me. You can of course get better performance if you directly write in the platforms native stack, but my point is that JRE is only as good as a properly architected Electron stack.

> Most of the above features don't need constant monitoring

The above features flat out aren't available in the Electron based editors people like to call IDE's now.

Im not talking about how possible it is to implement them - I'm explaining why I accept the overhead of a JVM based IDE, but won't accept an Electron one: the JVM one (JetBrains IDEA) has those features, none of the other options on macOS have them.

VS Code has less features then the main Visual Studio and Intellij IDEs, also I don't think the problem is the language but Electron. About memory uisage, garbage collected languages will show a larger memory usage because they will not start cleanup when an object is freed, it waits until it needs free memory and then it starts the GC and in Java I think you can specify options to control this,CPU usage is more important since that uses battery/enrgy

JVM has the same problem, isn't it?. In fact VSCode even after extending it with lots of plugin to make it a full-fledged IDE, feels more responsive and relatively lean on memory usage compared to full-fledged (JVM based) IDEs.

If you think VS Code with all plugins is an IDE at the level of Intellij or the main Vs then why VS still exists? Maybe you did not used this large IDEs so you don't know what the features or speed is, maybe your projects work good enough with VS Code or a plain text editor(not all projects need a big IDE). My opinion is that Electron needs more optimizations, and the developers that use it need better tools and need to also care more about the CPU usage. Even if you would use c and compile to web assembly to run n electron the problems would still be there so not the Language is at fault but the implementation.

>The overhead is very minimal

You're still using JS, unless you're compiling modules for node.js.

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.

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.

> 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.

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.

"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.

Reply on news.ycombinator.com