Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.

How so? It affects load time, understandability, binary size, dependency payload...

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.

I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.

I agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.

> I'm just saying that LOC is a fairly useless metric for evaluating software.

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.