Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.
Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code.
EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse.
When you're moving fast and in your flow, it gets to be really annoying.
That's just not true.
Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.)
Rate of change is another very useful metric.
git clone git://git.suckless.org/st
cloc --quiet st
http://cloc.sourceforge.net v 1.60
T=0.09s
(45.8 files/s, 56588.2 lines/s)
------------------------------------
Language files blank comment code
------------------------------------
C 1 497 253 3654
C/C++ Header 2 40 124 313
make 1 13 2 45
------------------------------------
SUM: 4 550 379 4012
------------------------------------
apt-get source sakura
(cloc sakura)
OpenJDK: 6.8 million
.NET: 10.5 million
Source: https://www.openhub.net/
Edit: @michaelmior I think you know what I mean.