This attitude fails to recognize the point I was making in my comment, and so it ends up fundamentally getting something wrong. It happens here in this sentence:
> The fact that you can write fast JS doesn't mean that the language itself or popular frameworks encourage you to do so
One half of this sentence is bang-on, and the other half is not. That is, it conflates what is encouraged by the language with what is encouraged by the modern JS crowd, and suggests something in that vein—as if they're one tightly interconnected bundle—but in fact, they are two distinct things, and I made several remarks in my original comment alluding to this.
To successfully argue the point you're making now, you have to argue that "the NPM way" that is now prevalent is the inevitable result of merely setting out to write a program in JS. But, in fact, it's not. As I mentioned, the JS that made up a huge proportion of Firefox's codebase was written in a style that doesn't resemble the style now popular with NodeJS and NPM, but there was no big, conscious effort to do that by, say, avoiding pitfalls of the language and the things that might make it slow—it was purely a result of the lack of opportunity for being tainted by bad examples from the NodeJS/NPM world, since that world didn't exist then. The main influence on programmers writing JS for Firefox was the influence of Objective-C, C++, and Java.
You certainly can "optimize" your JS to make it faster, just like you can with any program, but that's not to say have to—you can leave the optimization to the engine itself most of the time. All that's really needed, on average, to make sure that JS is fast, is to avoid tainting yourself with mindworms that have proliferated in the NodeJS+NPM ecosystem, that is: just don't do the things that you would have never thought of doing were it not for having seen others doing it somewhere else on GitHub or in the packages hosted on npmjs.com.
In other words, if you want to write JS that avoids being slow, then you don't have to take any special effort. Generally, you can start by opting for writing the dumbest, most boring code possible. (Indeed, I routinely come across "clever" code by self-styled NodeJS aficionados exhibiting elaborate contortions to fight against the language, when it would be far better to just do the simplest possible thing and then move on. Refactoring to eliminate these contortions can even make the code more performant and more concise.)
For example, let's say you have something written in Java, or something with an analogue in C++ or Go, and your team has some motivation to either recreate it in or migrate it to JS. That's perfect—before you ever think about handing the task over to a professional NodeJS programmer, you really should give some heavy consideration to doing your best to copy the architecture from the existing, non-JS implementation, down to class names and code organization, and doing a straightforward, procedure-for-procedure port to JS. (Although, if in the case of migrating from Java, maybe also consider eliminating any unnecessary abstractions along the way—or don't.) There's a good chance that this will have satisfactory results that challenge your assumptions. Even if you're creating something from scratch rather than porting an existing solution, once again, all you have to do is to not worry about being fashionable and trendy, and just do the most straightforward thing possible.
There's a recent comment here on HN that's extremely relevant and really hints at what's going on with all these slow, bloated, and messy projects from the world of modern webdev:
> The fact that you can write fast JS doesn't mean that the language itself or popular frameworks encourage you to do so
One half of this sentence is bang-on, and the other half is not. That is, it conflates what is encouraged by the language with what is encouraged by the modern JS crowd, and suggests something in that vein—as if they're one tightly interconnected bundle—but in fact, they are two distinct things, and I made several remarks in my original comment alluding to this.
To successfully argue the point you're making now, you have to argue that "the NPM way" that is now prevalent is the inevitable result of merely setting out to write a program in JS. But, in fact, it's not. As I mentioned, the JS that made up a huge proportion of Firefox's codebase was written in a style that doesn't resemble the style now popular with NodeJS and NPM, but there was no big, conscious effort to do that by, say, avoiding pitfalls of the language and the things that might make it slow—it was purely a result of the lack of opportunity for being tainted by bad examples from the NodeJS/NPM world, since that world didn't exist then. The main influence on programmers writing JS for Firefox was the influence of Objective-C, C++, and Java.
You certainly can "optimize" your JS to make it faster, just like you can with any program, but that's not to say have to—you can leave the optimization to the engine itself most of the time. All that's really needed, on average, to make sure that JS is fast, is to avoid tainting yourself with mindworms that have proliferated in the NodeJS+NPM ecosystem, that is: just don't do the things that you would have never thought of doing were it not for having seen others doing it somewhere else on GitHub or in the packages hosted on npmjs.com.
In other words, if you want to write JS that avoids being slow, then you don't have to take any special effort. Generally, you can start by opting for writing the dumbest, most boring code possible. (Indeed, I routinely come across "clever" code by self-styled NodeJS aficionados exhibiting elaborate contortions to fight against the language, when it would be far better to just do the simplest possible thing and then move on. Refactoring to eliminate these contortions can even make the code more performant and more concise.)
For example, let's say you have something written in Java, or something with an analogue in C++ or Go, and your team has some motivation to either recreate it in or migrate it to JS. That's perfect—before you ever think about handing the task over to a professional NodeJS programmer, you really should give some heavy consideration to doing your best to copy the architecture from the existing, non-JS implementation, down to class names and code organization, and doing a straightforward, procedure-for-procedure port to JS. (Although, if in the case of migrating from Java, maybe also consider eliminating any unnecessary abstractions along the way—or don't.) There's a good chance that this will have satisfactory results that challenge your assumptions. Even if you're creating something from scratch rather than porting an existing solution, once again, all you have to do is to not worry about being fashionable and trendy, and just do the most straightforward thing possible.
There's a recent comment here on HN that's extremely relevant and really hints at what's going on with all these slow, bloated, and messy projects from the world of modern webdev:
https://news.ycombinator.com/item?id=23869393