当你开始你的最后一个软件项目时，你是否先写了你自己的编程语言？你是否从头开始建立你的计算机？当然不是。这将是可笑的。这将是一种时间的浪费（在可持续发展的业务中这意味着金钱）。这不是你的核心竞争力。这不是你的价值主张。你会在完成之前耗尽金钱。
当你开始在你的应用程序的用户偏好页面上工作时（或者不管你实现的最新功能是什么），你是否只是从架子上拿了一些东西？你所选择的数据库很可能有一个预制的UI界面，用于简单的CRUD操作。你为什么不直接使用它呢？可能是因为你的客户期望在整个应用中拥有专业的、现代的、一致的设计和体验，而那个预置的用户界面不能为你的客户做到这一点。
这些都是软件业务中构建与购买的极端例子。在这两种思路之间会有一个中间地带，这对你的项目（和你的职业/业务）的成功是最好的。
开源世界充满了惊人的库和框架，可以帮助我们快速构建软件并交付给用户。像ReachUI、MaterialUI，甚至一些公司建立的组件库，如Adobe的React Spectrum，都是成熟的、经过战斗考验的（更重要的是：经过无障碍测试）。令人鼓舞的是，在用户界面领域，甚至有一些付费的选择正在出现（例如TailwindUI和Remix）。对于许多你会发现自己作为一个UI开发者所从事的事情，你将面临的问题都有现成的解决方案。
我喜欢这一点的原因是，这意味着我不得不花时间去做那些不是我作为一个开发者的核心竞争力的事情了。就像我建立自己的编程语言是可笑的一样，在已经有这么好的模式存在的情况下，我建立自己的模式实现也是同样愚蠢的。
我可以听到你们中的一些人已经在抱怨了，所以让我来谈谈房间里的大象。有时你会发现，你只是不喜欢一个组件的实现方式，而你要弯下腰来把你的用例纳入他们的API。我建议，当你所面对的是一个成熟的、为你试图建立的那种用户界面所建立的解决方案时，你应该暂停一下。考虑一下你所困扰的实现方式是否真的是一个合理的问题（例如性能和/或可访问性问题），或者是否只是一个熟悉的问题。通常情况下，我们会对不同于我们习惯的API产生膝跳反应，如果让这些第一印象控制我们是否接受新的东西，那将是一个错误（我想到了React + JSX）。
请记住，我不是说你永远不应该为你的公司建立一个组件库。大多数公司应该这样做（嘿嘿，你认为大多数现有的解决方案是从哪里来的？）但看在上帝的份上，如果你想建立自己的手风琴、标签或组合框，请重新考虑。这些都是不容易做好的。我个人把这个问题归咎于网络平台（这些常见组件的风格化版本应该被嵌入到平台中），但这与本次讨论没有关系。找到一个成熟的、经过战斗考验的这类低级组件的版本，然后用它来代替。你的公司并不像你想的那样，是一片独特的雪花。
应该包含在你公司的组件库中的组件种类是那些为你的应用程序中的常见用例包裹低级原始组件的组件。不，我并不是说。我不是说："做一个包装器，然后你就可以换掉实现"（这在实践中很少奏效）。我想说的是，你利用你所选择的组件的能力，并限制人们可以做的事情，以促进你的用户界面和代码库的一致性，只要是实用的。此外，在你的应用程序中，可能有一些UI元素对你的应用程序来说是非常独特的，但却是由其他几个低级别的组件组成的。这些也是建立你自己的组件库的好人选。
所以，你当然可以有一个组件库，包括像按钮、布局、排版、表单元素等。但你不需要从头开始建立每一个这样的东西。有一天，我看到一个有几千行代码的按钮组件。我的意思是，如果你允许的话，这些东西可以变得出奇的复杂，但看在上帝的份上，请你只关注你的业务。
我知道，自己建立所有的东西可能会有很多乐趣。当我在PayPal的时候，我在一个React组件库工作，我从头开始建立按钮（但我也为其他组件包装了一些开源的东西）。所以我一直在那里。但并不是所有的公司都有足够的资源来专门抽出一两个工程师来构建UI组件。在某些时候，你必须把这些组件变成对支付账单的人有用的东西。而那些人不会为你的内部组件库文档的网站买单（即使它确实有可运行的浏览器代码示例）。
我真的不想让人觉得拥有某种组件库是在浪费时间。它并不浪费时间。但你只是要平衡你对建立一个完美的抽象 的兴奋与你的业务的可持续性的实用性。牢记你的业务的核心能力，不要因为这是一个有趣的技术挑战而选择 "构建"，而是因为它对你的业务的成功实际上是必要的。
无论你选择哪种构建和购买的组合，我都希望你能有好运气。👍
