Yeah, they just don't get it, they have stayed for so long in the enterprise java world that they can't comprehend that everybody else moved on from those bloated IDEs. On my case if I had a choice even between Notepad++ and IntelliJ (to pick an extreme example), I would still use Notepad++.
VScode is a very nice middle ground where the defaults make sense and you can get powerful extensions for everything else you want, there's a reason it's so popular.
Am I the only one who finds it a little bit ironic to call IntelliJ bloated, and then recommend VS Code, which may not be that "bloated" feature-wise, but is based on a browser engine, so also not really light on resources? A VS Code-like product using the Sublime Text engine would be the ideal development tool for me. As long as that's not available, I'm using PHPStorm at work (my company is paying for it) and VS Code for my private projects in Go - still haven't tried out Goland, IntelliJ's Go IDE, but so far I'm happy with VS Code.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does under similar circumstances because I've never tried to measure it, but I know that I regularly see Electron apps using less than 70MB, so we can estimate an upper bound on Electron's typical contribution to bloat as being no more than ~30% of Java's.
For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB. I doubt that much of that difference is actually attributable to using a browser rendering engine for GUI layout. In fact, I'm guessing that Chromium's net impact on the situation falls below the noise threshold of this comparison. So, yeah, not worried about it. FWIW, vscode also started up quite a bit faster, and I experience less keyboard lag when using it.
And, if we're looking for mature and full-featred cross-platform GUI toolkits, that's about it for your options. Yes, there's QT, but, with a sticker price of $4000/developer/year, it's hard to criticize people for not choosing it. And there's GTK+, which is fine, I suppose, but not exactly everyone's cup of tea.
Long story short: This Electron-flaming meme is getting old. If you don't like JavaScript, just come out and say it. If you don't like how Chromium is eating the world, that's a fair point, too. But stop scapegoating Electron for things like how Slack's desktop app used to leak memory at an astonishing rate. That was always the app developer's fault, not Electron's.
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing.
This is much lower in newer jdk's [0].
> For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB
I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram.
I that you're right that it's just IntelliJ doing too much. Similar to how the Slack app's formerly astonishing memory consumption was because it was trying to retain all of Giphy in memory for all time.
Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.
IntelliJ has more features than even the best language service I’ve used, C#’s. The language server tools are catching up but for integration and polish you still can’t beat JetBrains.
On the subject of the (lack of) snappiness in Visual Studio + ReSharper, Jetbrains Rider comes with the ReSharper functionality built in and feels a lot snappier.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing
Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap.
You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course.
I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.
That's already happening with modern JDKs and GCs; as of JDK 12, G1 uncommits unused heap eagerly (see https://openjdk.java.net/jeps/346), and the parallel GCs Shenandoah and ZGC do the same.
Considering how avid Electron user tell others how files should not be even bigger than few hundred lines considering electron croaks on that. Or without irony they tell how fast Electron is on 6-core/32GB machines and that everyone should upgrade. They should be last person to talk anything about performance.
> Long story short: This Electron-flaming meme is getting old.
No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.
I think this is a great comaprison of the wrong things - i do not believe RAM used is what matters, not if it's under 4 Gb.
I think it's CPU, and VS code consistently takes more CPU to achoeve the same job, and for longer.
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing.
Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.
Yes. So the absolute worst case scenario is one our 128mb heap apps that uses direct memory byte buffers for off-heap object caching. It's resident set size is roughly 387m, which up to 196m of that is byte buffers. I can tell using JPS the heap is full allocated, and the application has been running for several weeks so I imagine the cache is full. That leaves an overhead of 64m.
For funzies, I looked at one our ActiveMQ Message brokers, which are ran on 1g machines with a 640m heap. The heaps are fully allocated and the resident set size is ~658m. Linux reports it has 66M of free memory and 95M of available ram. 440m of swap is being used and is only lightly being paged out under light load of 400 msgs/s. This same setup can push 2000msg/s before GC thrashing becomes an issue and we need more heap.
So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.
Slack's bloat may be the developer's fault, but the same could be said about Atom, and Discord, and Evernote, and Skype. And even if you can't say it about VSCode itself, you can certainly say it once you introduce a handful of extensions.
Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.
You'll have to post more about the OS and how you measured memory consumption. If you're just looking at something like htop, it can be pretty misleading.
I dread the day Siemens inevitably buys Qt (it will happen) and the license structure changes to $65k/per-seat buy-in to the “base” toolkit which includes QObject and nothing else. Also, a $7k/year per-seat maintenance fee for “base”.
If you want the QtGui module, look north of $100k buy-in.
I'm well aware that VSCode as a tech product is also full of bloat internally, the difference is that this bloat is mostly hidden to the user. What they have going for them is that it's a well designed text editor with sensible defaults in the first place, it "just works" and it's simple, that's also why it's so popular. You can add as much (or as little) as you want on top of it.
The UI is also a lot cleaner. There are only a couple of icons and each of them does something I use regularly. Jetbrains products have 300 icons and I use about 5 of them. Once I worked out I could do everything I use rubymine for in vscode with plugins I stopped paying that license fee.
> VS Code ... is based on a browser engine, so also not really light on resources?
You say that, but IntelliJ is not exactly slouching on resource usage. I see far lower memory usage in VS Code than I do IntelliJ opening the same projects.
I see this critisism of VSCode a lot - but the job of a browser engine is to render text really fast! Rendering text is something you want to do in a text-editor is it not? Why not use the best tool for the job?
You're probably right that something like Sublime Text is faster - but that's a massive undertaking that would take a lot of engineering to get right.
The job of a browser is to render a wide range of UI specifications reliably and support a collection of broken but grandfathered web languages, not to render them quickly. Speed is nice, but it comes after those concerns.
The point of Electron is to allow people to develop UIs quickly, leveraging their experience with the web. Electron is extremely bloated & slow. To some degree it has to be.
If browsers were about speed, they wouldn't interpret Javascript. I'd argue they'd probably force the UI to be specified in a form that explicitly disallows inefficiencies and probably isn't turing complete. I'd argue a domain-specific solution for rendering highlighted code specifically could be a lot faster than a browser, like multiple orders of magnitude. We know that's the case by virtue of the fact we could even do it at all in the 80s.
VScode is a very nice middle ground where the defaults make sense and you can get powerful extensions for everything else you want, there's a reason it's so popular.