> IMO its generally the JS hype producing these monstrosities.

If you use "the JS hype" as a synonym for what are considered best practices
by the folks in the NodeJS/NPM ecosystem, then you're right. (I.e., the fault
lies in the "hype" half, not in the "JS" half.) It was 10–15 years ago that
you could routinely hear one of the most prevalent criticisms in the
programming world about the bloat of Java.

I think that, where JS is concerned, for some reason we're seeing a regression where it's becoming
"conventional wisdom" that JS itself is slow, against the evidence to
the contrary. I've seen straightfaced comments here on HN in the last few
months, for example, that complain about the slowness of JS as a general rule.
But the reality is that the JS runtimes have billions of dollars of
engineering from top-tier teams invested in them, and today's JS engines are
by-and-large pretty fast. V8, in fact, shares parts of its implementation
with Java's HotSpot—specifically the parts that were developed by the folks
who made the StrongTalk VM and who were acquired by Sun, thus leading to that
work being incorporated into HotSpot in the first place.

So what is that reason?

There has been a noticeable shift in performance degradation that corresponds
to the rise of, for lack of a better term, "the NPM way of programming". As
with the case of Enterprise™ Java®, the problem lies in the way people in
those circles are writing their programs and what passes for an "idiomatic"
coding style. The NPM style used heavily in many Electron apps is relatively
recent, with respect to JS's lifetime. Even before JS engines were JITted, Firefox itself had hundreds of
thousands (millions?) of lines of JS doing a lot of the work both in what you
see on the screen when you're poking at your browser as well as behind the
scenes. Notably, the JS in those cases is not of the NPM style. There's
nothing in principle that means the "Emacs-like" application architecture
(compiled core, dynamic shell) needs to be slow, particularly on today's hardware.

As I've mentioned before[1], in the early days of Firefox, I used to use 1.0 and 1.5 on an 800 MHz
PIII with 128 MB of RAM. (For folks looking to leap in here with what they'd
like to consider a well-timed "well, actually…": yes, I'm acutely aware that
even that number is on the order of 100× or more beyond what is necessary to
get real work done with a computer—but the point is that it's nothing compared
to, say, stock 2015-era Chromebooks with 8GB of RAM, or a comparable quantity
in today's phones, for that matter.) Browser extensions are written in JS, and
my laptop now is several times over better than the laptop I used 10 years
ago—and yet... if I install any arbitrary extension today, there's a good
chance that I will encounter perceptible bloat there, too. A recent example
(within the last year) that I know of, is the WorldBrain Memex add-on, which
upon immediate use has the telltale mark of influence from the world of modern
"frontend" webdev, and the performance to match. This wasn't the case when
add-ons were authored in the sui generis style of yesteryear, before the NPM
practices leaked over and began influencing everything related to JS—and
tainting people's perceptions.

So I find the attempt to draw a contrast between JS and Java a little misplaced. Even ignoring the
common history (in both culture and provenance), there's the fact that Java
IDEs themselves have always been the poster children of bloat—second only (or somewhere in the running) along with Visual Studio proper. I know people
like to point to VSCode as an example of a "snappy" Electron app, and the
inevitable retort about just how lean it really is. (On my system, I don't
think it's possible to run VSCode without making sure that there's at least
350 MB of main memory to spare before launching it. Compare to the old joke
about Emacs's "bloat": that it was supposed to stand for "Eight Megabytes And
Constantly Swapping".) On the other hand, I have to recognize that the folks
calling VSCode snappy really are on to something. The previous statements
notwithstanding, the fact is that VSCode is still snappier than anything
I've ever experienced using one of the mainstream Java IDEs. If I were a
naive person, I could point to that and conclude that the problem lies with
Java-the-language. And yet every day I used my phone with large parts written
in Java—which, to be fair, does impart some impression of bloat and
sluggishness, so it's prudent for me to keep in mind earlier versions of
Android on older, more limited hardware that did have a fairly snappy feel.
And those observations lead us back to the root problem, which is if you
judged only by much the code being written today, programmers seem to have
forgotten (or simply never learned?) how not to write code that's bloated and
slow.

1. https://news.ycombinator.com/item?id=23183770