JavaScript is Perl 4 with first class functions, slightly better lexicals, better implementations, and more users.
(If that hasn't offended you yet, note that that sentence doesn't include "a better type system", on purpose.)
While you can do some amazing things with modern JavaScript (see also ClubCompy, a retro-style programming environment designed for kids of all ages, for which we have a compiler and interpreter written in JavaScript), its flaws of language and ecosystem are obvious. The latter are obviously products of its environment.
Consider: you don't have anything like the CPAN for JavaScript in the browser. (Yes, I'm aware of NPM. No, it doesn't count. The point of client-side JavaScript delivered from a web page is that you don't have to have anything other than a web browser installed.)
Consider: this means you either make lots of requests for your dependent libraries (jQuery, any plugins you use, the JavaScript you've written), which is good in that if you use these libraries unmodified and load them from a public CDN, there's a chance some cache in the middle will already have them cached, but you still pay the network penalty for loading all of those libraries n at a time or you glue them all together on the server side somehow and send the client only one thing, except that it's only cached for your site.
Also, if you find a bug in a dependency, you get to regenerate that big blob of code. (If you don't find that bug, you get to live with it.)
I think about these things when I see a big lump of code stuffed into YAML.pm. Because we've left 1994 behind in the Perl world, we're able to take advantage of an amazing library distribution and dependency management system in the CPAN, where installing dependencies (and knowing they pass their tests) is so well understood that it's an exceptional condition when it doesn't work. In the past couple of years, installations have become so easy thanks to newer tools like perlbrew and cpanm that (if you're in the know) it's easier to manage code this way than to consider not.
... except for when you stuff generated code in your repository instead of as a dependency. (Test::Builder is a strange case. You want your underlying test library to be as stupidly simple as possible and not to rely on anything else so it's as unlikely to fail as possible and as impossible to interfere with what you're testing as ever.)
Now when there's a bug in the dependency in the generated code, everything which uses the dependency has to be updated too. Read carefully. You can't merely update the dependency. You have to know everything on which it depends and wait for the authors to get around to updating their generated code.)
I admit, I'll probably never understand the mindset which says "I'm distributing software for end-users to install in the worst possible way so that they won't have to install software." I understand the use of things like App::FatPacker to make one-file installations possible, but actively distributing generated code in CPAN distributions? Where CPAN has a working dependency resolution model already in place? Where your distribution is already an upstream dependency of thousands of other distributions?
I just don't understand it. I understand that the business of shipping software is the art of managing competing needs, but I can't see how optimizing for fragility helps anyone.
some generated code is good, see some of the things you can do with Dist::Zilla, and which is akin to what the Pragmatic Programmer mentions. but I agree that simply duplicating an entire distribution is not a great idea, that's not really the same distributing generated code. It's outright redistributing someone elses code, without the intent to fork and maintain for a different purpose.
Errr... what better lexicals? JavaScript has only global and function scope (and "hoisting" variables declarations).
As for lack of CPAN - it is hard to have one without include/require/use...
Global and function scope is slightly better than only global scope.
You're right about the source of the library management problem.
> I'll probably never understand
Did you, like, go and ask ingy? He's a person one can communicate with.
I remember discussing what would become Module::Install with Ingy, in my living room.
The thing is, you're writing software for people to install. If you do that, it makes no sense to me to worry that they can't or won't install software. The people who can't or won't install software won't install the software you're writing! This use case contradicts itself.