It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obvious.
Why do closures make a language "serious"? To me languages are just languages. Seriousness is defined the problem you are solving. Are flight controls serious? Probably. Is yet another small scale CRUD app serious? Probably not.
There is a lot of "serious" code written in every major language. There is a huge amount of "serious" code written in C and C++, and all of this without first class functions or lexical closures.
A "serious" language is indeed partially defined by its fitness for the stated job at hand, but also for how well it handles the often unstated requirements of productivity, security, maintainability, and robustness in the face of likely future needs. Languages that have more of the above features tend to do better at these unstated requirements.
What is and isn't a "serious" language can change over time depending on what we learn is important. C was a serious language for a while, but it has not been one for a couple of decades because of its non-support of anything remotely resembling security. C is still used because of its extreme portability, but it probably should be abandoned.
Conversely, languages that support first-class functions, lexical closures, and automatic memory management are now in the serious category because those things present huge improvements in productivity, maintainability, and robustness in the face of future changes. (I'll even go out on a longer limb and say that programmers who learn to think in terms of functional composition become more productive coders in any language.) Pure O-O languages are beginning to move in the non-serious direction because they cannot be readily parallelized in an era when parallel computing is the only way forward now that Moore's law is dead.
Javascript anticipated a couple of these features before other mainstream languages, and now it's moving beyond web browsers. So yeah, with some reservations I'd call it serious.
Nowadays I'd never write major code in a language that doesn't directly support most of the "serious" features I listed above; it would be too much of a hit to my productivity. It would feel like building a house with a hammer and nails when nailguns were readily available.
If I were writing embedded apps like flight controls today, I'd use Lisp for the high-level parts and Rust and maybe a bit of assembler for the low level parts.
The "serious" professional choice for my company (an OS vendor, with a focus on certifiable systems) is currently C. The tooling we use is for C, the expertise within my company is in C, and the industry that we work with understands and expects C.
At some point, the operating systems industry will transition to more modern languages. Rust is promising, but it is a long way from being a serious consideration for FAA certifiable projects.
Same for C++.
Javas functions aren't first class, but only to the extent that there's some syntactic sugar.
I can't tell if you think JS is not a serious programming language.
I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..).
>What this means, however, is that to do JavaScript development “The Modern Way”, while adopting its new features, you simply must use a local transpiler toolchain
Surely this depends on the browsers your application is targeting? And presumably, the sort of feature you're using (can it be polyfilled or is it a syntax feature?).
>In 2018-2019, several things have changed about the JavaScript community. Development tools are no longer fledgling, but are, instead, mature. There are built-in development tools in all of Safari, Firefox, and Chrome browsers
I agree they're decent, but there are still cases where they struggle - particularly after code has been transpiled. I still run into issues these days where the browser is trying to show a source-mapped JS file instead of the actual bundle code which masks a real issue.
>And, for web frontends, it’s your only choice
https://caniuse.com/#search=webassembly
If you don't care about IE11 (or you polyfill), it's hardly your only choice. wasm is still far from perfect but there's no question you can start writing some logic in languages other than JavaScript, and interoperate.
>If you’re the kind of programmer who thinks, “I code in Python/Java/Ruby/C/whatever, and thus I have no use for JavaScript and don’t need to know anything about it”, you’re wrong, and I’ll describe why. Incidentally, you were right in 1998, you could get by without it in 2008, and you are dead wrong in 2018.
>To be a serious programmer, you’ll have to know JavaScript’s Modern and Good Parts — as well as some other server-side language, like Python, Ruby, Go, Elixir, Clojure, Java, and so on
This reads to me as downright patronising to e.g. embedded software engineers who might be writing hardware drivers in C/C++ day to day.
Perhaps this should read "to be a serious web developer with front-end responsibilities" (JavaScript is sufficient, not necessary on the back-end and - of course, subjectively - there are much better choices to use).