Add FAQ to readme
This commit is contained in:
parent
77126fba13
commit
4a10354857
1 changed files with 23 additions and 2 deletions
25
readme.md
25
readme.md
|
|
@ -15,6 +15,11 @@
|
|||
|
||||

|
||||
|
||||
## Info
|
||||
|
||||
- [Why not switch to a smaller coloring package?](https://github.com/chalk/chalk?tab=readme-ov-file#why-not-switch-to-a-smaller-coloring-package)
|
||||
- See [yoctocolors](https://github.com/sindresorhus/yoctocolors) for a smaller alternative
|
||||
|
||||
## Highlights
|
||||
|
||||
- Expressive API
|
||||
|
|
@ -246,9 +251,25 @@ Since Chrome 69, ANSI escape codes are natively supported in the developer conso
|
|||
|
||||
If you're on Windows, do yourself a favor and use [Windows Terminal](https://github.com/microsoft/terminal) instead of `cmd.exe`.
|
||||
|
||||
## Origin story
|
||||
## FAQ
|
||||
|
||||
[colors.js](https://github.com/Marak/colors.js) used to be the most popular string styling module, but it has serious deficiencies like extending `String.prototype` which causes all kinds of [problems](https://github.com/yeoman/yo/issues/68) and the package is unmaintained. Although there are other packages, they either do too much or not enough. Chalk is a clean and focused alternative.
|
||||
### Why not switch to a smaller coloring package?
|
||||
|
||||
Chalk may be larger, but there is a reason for that. It offers a more user-friendly API, well-documented types, supports millions of colors, and covers edge cases that smaller alternatives miss. Chalk is mature, reliable, and built to last.
|
||||
|
||||
But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't become malicious over time.
|
||||
|
||||
Chalk is also likely already in your dependency tree (since 100K+ packages depend on it), so switching won’t save space—in fact, it might increase it. npm deduplicates dependencies, so multiple Chalk instances turn into one, but adding another package alongside it will increase your overall size.
|
||||
|
||||
If the goal is to clean up the ecosystem, switching away from Chalk won’t even make a dent. The real problem lies with packages that have very deep dependency trees (for example, those including a lot of polyfills). Chalk has no dependencies. It's better to focus on impactful changes rather than minor optimizations.
|
||||
|
||||
If absolute package size is important to you, I also maintain [yoctocolors](https://github.com/sindresorhus/yoctocolors), one of the smallest color packages out there.
|
||||
|
||||
*\- [Sindre](https://github.com/sindresorhus)*
|
||||
|
||||
### But the smaller coloring package has benchmarks showing it is faster
|
||||
|
||||
[Micro-benchmarks are flawed](https://sindresorhus.com/blog/micro-benchmark-fallacy) because they measure performance in unrealistic, isolated scenarios, often giving a distorted view of real-world performance. Don't believe marketing fluff. All the coloring packages are more than fast enough.
|
||||
|
||||
## Related
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue