> People build on top of existing stuff N layers deep.
Okay. You're not actually disagreeing here. This is the antipattern popular with NPM folks (and extremely reminiscent of Enterprise Java) that I identified as the problem.
> I disagree that the code written is slower than in the past. There's simply much more of it.
Even ignoring that "there is more of it" is part of the problem, you can say "I disagree", but all that gives us is a stalemate unless you're going to introduce data into the conversation.
> And the VM warmup is slower than Java because the code is distributed in a very inefficient format.
Not even the Java folks who work on Java agree with that. Warmup is one of Java's weak spots. The GraalVM team can and will tell you this. It's one of the things they bring up people when trying to get them to temper their expectations.
I recently ported a command-line utility more or less line-by-line from Java to JS, in an extremely naive way—the only concern was to make it work. When I finished, on a lark I checked how it compared against the Java version. Even with the JDK's wealth of specialized collections, compared to, say, the way that in the JS version all the places that expect a map got a general-purpose ES6 Map, the JS version running on NodeJS would beat the Java version every time. In this case, it doesn't actually matter because it wasn't performance-sensitive code, and in both cases, both processes would terminate in <1 second, but the fact remains that NodeJS was able to parse the JS program, compile it, execute, and then terminate faster than the the java process could launch, read the bytecode, verify it, and then perform the same job.
There's an interview from 2009 with Lars Bak on MSDN that you might look into, with the MS folks on the static languages side, and Lars on the other side explaining why in practice V8's performance can be comparable if not better than with "managed", bytecode-based, static languages like Java and C#.
FWIW, I'm not even a dynamic languages fanatic. Another of my big complaints about the NPM crowd is their lack of regard for making sure the "shape" of their inputs is easily decipherable. I've made money as a result of dynamic language folks thinking that using a dynamic language means you don't have to worry about types, and that attitude leading to CVE-level security problems. There are a couple Smalltalk papers I've enjoyed reading[1][2], both somewhat critical/skeptical of the promises of dynamic languages. In general, I advocate for writing code as if there is a static type system in place, even if you're in a dynamic language that doesn't require it.
Keep in mind, though, that this is all completely besides the point, because my original message was only that JS is now starting to be re-perceived as slow as a general rule because of NPM's hype-driven development, where programs are authored by which patterns are trending at the time or otherwise trying to imitate the styles of NPM tastemakers and "thoughtleaders", which leads to people creating huge messes. The entire Java versus JS issue was an aside.
1. "How (and Why) Developers Use the Dynamic Features of
Programming Languages: The Case of Smalltalk"
2. "An Overview of Modular Smalltalk" by Allen Wirfs-Brock and Brian Wilkerson. (awb was the editor of ECMA-262 version 6, FWIW.)
And on that note, here are two more of my favorite programming essays of all time:
Okay. You're not actually disagreeing here. This is the antipattern popular with NPM folks (and extremely reminiscent of Enterprise Java) that I identified as the problem.
> I disagree that the code written is slower than in the past. There's simply much more of it.
Even ignoring that "there is more of it" is part of the problem, you can say "I disagree", but all that gives us is a stalemate unless you're going to introduce data into the conversation.
> And the VM warmup is slower than Java because the code is distributed in a very inefficient format.
Not even the Java folks who work on Java agree with that. Warmup is one of Java's weak spots. The GraalVM team can and will tell you this. It's one of the things they bring up people when trying to get them to temper their expectations.
I recently ported a command-line utility more or less line-by-line from Java to JS, in an extremely naive way—the only concern was to make it work. When I finished, on a lark I checked how it compared against the Java version. Even with the JDK's wealth of specialized collections, compared to, say, the way that in the JS version all the places that expect a map got a general-purpose ES6 Map, the JS version running on NodeJS would beat the Java version every time. In this case, it doesn't actually matter because it wasn't performance-sensitive code, and in both cases, both processes would terminate in <1 second, but the fact remains that NodeJS was able to parse the JS program, compile it, execute, and then terminate faster than the the java process could launch, read the bytecode, verify it, and then perform the same job.
There's an interview from 2009 with Lars Bak on MSDN that you might look into, with the MS folks on the static languages side, and Lars on the other side explaining why in practice V8's performance can be comparable if not better than with "managed", bytecode-based, static languages like Java and C#.
FWIW, I'm not even a dynamic languages fanatic. Another of my big complaints about the NPM crowd is their lack of regard for making sure the "shape" of their inputs is easily decipherable. I've made money as a result of dynamic language folks thinking that using a dynamic language means you don't have to worry about types, and that attitude leading to CVE-level security problems. There are a couple Smalltalk papers I've enjoyed reading[1][2], both somewhat critical/skeptical of the promises of dynamic languages. In general, I advocate for writing code as if there is a static type system in place, even if you're in a dynamic language that doesn't require it.
Keep in mind, though, that this is all completely besides the point, because my original message was only that JS is now starting to be re-perceived as slow as a general rule because of NPM's hype-driven development, where programs are authored by which patterns are trending at the time or otherwise trying to imitate the styles of NPM tastemakers and "thoughtleaders", which leads to people creating huge messes. The entire Java versus JS issue was an aside.
1. "How (and Why) Developers Use the Dynamic Features of Programming Languages: The Case of Smalltalk"
2. "An Overview of Modular Smalltalk" by Allen Wirfs-Brock and Brian Wilkerson. (awb was the editor of ECMA-262 version 6, FWIW.)
And on that note, here are two more of my favorite programming essays of all time:
"Java for Everything". http://www.teamten.com/lawrence/writings/java-for-everything...
"Too DRY - The Grep Test". http://jamie-wong.com/2013/07/12/grep-test/