Because a lot of the JS community comes from the design world, and they care about colors more than other communities.

In Python, the experience has been the opposite. We had to wait until recently to have once very good decent terminal coloring lib: rich.

It's because it's something that can be easily influential. At some point every sufficiently large CLI tool needs a terminal color library, and if you can make yours 1% better than anything else, then you can make a library that touches a lot of projects, which is great for your resume and improves your job prospects (at least that's what they hope).

There's lots of CLI tools around JavaScript itself. And many third-party developer oriented services ( Firebase, Netlify, etc.) have their CLIs in JS as well.

Thanks for the context. I do very little work with SaaS services, so I’m extraordinarily ignorant of their CLIs!

If you ever are interested, there's some cool stuff in the area like oclif framework. (from heroku) for building nice CLI tools...

Very interesting mix of JS+CLI indeed

Javascript is the opposite of a batteries-included language, so there is and has been an enormous amount of wasted effort duplicating functionality that should have been in a standard library.

We’re talking about a terminal colorization function though. Fragmentation of packages aside, are there any other languages that have terminal text colorization built into the standard library?

Every serious programming language I've ever used...

https://docs.microsoft.com/en-us/dotnet/api/system.console.f...

It's even easier on UNIX-like terminals, where ANSI escape codes should work.

Okay? You gave one example, C#, and extrapolated that to every single serious programming language you've ever used. I just took a quick look and none of Java, ruby, python, and PHP has this functionality in its standard library. Also yes ANSI codes work but it's not easy to write or read, so that's what these libraries are for. I'm not a JS apologist but it seems inaccurate to imply that its need for a terminal colorization library is a unique deficiency of the language.

Are there any movements towards creating a standard library for JavaScript (or at least server-side JS)?

There are many, many, many such movements. Which somewhat defeats the point, really.

This is why I have 107 different point-releases of lowdash and jquery in my node_modules folder

>107 different point-releases of lowdash

Would totally believe that lowdash is a lodash fork.

I don't know what you mean by "point-releases". I understand the hyperbole but pretty much every package manager will minimize different versions by installing one that's compatible with all requirements.

I’d wager a guess that bootcamps teaching JS producing lots of people. Eventually, some will want to recreate something from scratch. A law of large numbers thing. I could be wrong though.

As for where it’s going, Node based CLI programs. For example, `yarn upgrade-interactive` uses it (a chalk-like module)

Combination of so much JS programmers being

    * Young

    * Hipster

    * From bootcamps without any other serious knowledge.

    * A culture of resume padding

    * A total lack of care about security, performance or reliability.

Riddled with insecurity yet somehow lacking humility.

For both definitions of "insecure"

I think it's because they try to impress their non-technical friends with flashy colourful and matrix-like terminal windows and come off as hackers when in reality most of them don't even know what a stack overflow is.

This kind of programming elitism is a general bummer: what good does it do to gatekeep “hacker” in this way?

Even the context is absurd: we’re on a website that calls itself “Hacker News” but caters chiefly to the relatively narrow and un-hacker-like interests of a handful of overcapitalized investors.

I took it to mean a second definition describing a particular aesthetic identity, e.g. dark-mode everything, tiny and/or monospace fonts, use of the word "rice" as a verb, etc. I'm totally down for two of those so this isn't said with disdain ;)

Perhaps "hax0r" would be more appropriate.

You only need to read the linked Twitter thread to get a couple examples.

I read the thread, and it sounds like these libraries end up in what I think of (from other ecosystems) as “core” tooling: package managers, linters, &c. I definitely wasn’t expecting that: most of the other ecosystems I’ve interacted with have had a “vendor or reimplement” mentality when it comes to dependencies in common tooling.

Overwhelming majority of modern web frontend development is done with build tools written in JS. Node is a popular choice for backend and that also generates a lot of lines of terminal output.