4 ms·

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

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

stephenr 9y ago
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
- murukesh_s 9y ago
  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.
  - stephenr 9y ago
    > 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.

stephenr 9y ago

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

murukesh_s 9y ago
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.
- stephenr 9y ago
  > 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.