全文共2949字，预计学习时长9分钟
照片由乔纳·皮特里奇拍摄，来源Unsplas
几个月前，我为一家技术公司做了一次关于Web组件的报告，当时大多数与会者都没有使用过Web组件。这次报告非常有趣，广受欢迎，最后观众提了一连串问题，提问环节持续了半个多小时。
接近尾声时，有人问我：你展示了原始的DOM操作代码，这是否意味着我们将回到使用“像jQuery那样的面条式代码”的时代？我看到一在场些人点头表示同意，这使我陷入思考。
显然，那些不属于某个框架或库，而只是我们所说的“Vanilla JavaScript”的代码，它们会被认为是糟糕的“面条式代码”。
这没什么好奇怪的。
整整一代的开发人员开始时都是使用框架和入门套件，这些框架和套件附带了一大堆现成的依赖项。只需运行 npm install ，并根据需要调整代码模板即可。
虽然这可能是一个很好的起点，但我们确实需要认识到，编程不仅仅是将第三方的库粘合在一起。
不反对依赖项
首先澄清一下，我并不反对使用依赖项。事实上，本人有很多次使用多个前端框架的经验。
但是，我希望读者在考虑使用哪个依赖项之前，先问问自己，是否真的需要这些依赖项来完成下一个项目。
这是一个非常重要的问题。我认为，思考这个问题的人还远远不够。
“不要重新发明轮子”的谬论
读者可能已经听过很多次，作为一个开发人员，你不应该“重新发明轮子”，相反，你使用的库应该已经能供你做想要构建的东西。
例如，当需要使用数据库ORM时，这句话就是一个好建议。因为现在已经有完备的ORM可供使用，从头编写毫无意义。
问题是:决定自己编写代码以及决定何时使用第三方依赖项，这两者之间，我们应该在哪里划定界限?
2016年，由于法律因素，left-pad的开发者决定从NPM删除所有的包，这个做法几乎使互联网瘫痪。这足以说明人们对第三方软件的依赖有多么疯狂。
left-pad的唯一作用是用0或空格填充字符串的左侧部分。这个包只包含几行代码，初级开发人员也可以用几行代码编写它。实际上，left-pad已经被弃用，取而代之的是标准的String.prototype.padStart()，然而仍有成千上万的项目依赖于left-pad。
而现在情况变得更糟。isarray只包含四行代码，它的作用是检查给定的参数是否为数组。当然，这是针对不支持本地Array.isArray()方法的旧浏览器而言的，但是任何开发人员都可以在一行代码中编写它。
自己编写这些包的代码并不是“重新发明轮子”。完全没有必要在项目中把这些包作为依赖项。
不知道自己在用什么
尽管如此，有人仍然认为最好使用现成的第三方模块——即使它们非常小——因为这些第三方模块经过了“实战测试”，是“经过验证的解决方案”。
问题是:你确定事实如此吗?
你是否真的知道这个依赖项是经过测试和验证的解决方案，还是仅仅假设它是如此?
你真的知道node_modules文件夹里的所有东西吗?
我不知道，也许没人知道。坦白地说，你也不必知道。但你至少应该想想要安装什么依赖项，自己要编写什么代码。
每个现代游览器都已包含fetch，这时你还需要一个庞大的库来进行简单的HTTP调用吗？你自己用几行代码就能编写，而且编写的程序只会执行你真正需要的操作，你还需要这样的大型数据解析库吗？
似乎整整一代的开发人员都过于缺乏安全感，不愿编写和使用自己的代码。反之，他们将各种库粘合在一起，并假定这些库已经通过了测试，没有bug出现。
但这种安全感只是错觉。
图源：pexels
我们为何会变得如此没有安全感?
为什么这些开发人员如此不敢信任自己的代码，而宁愿使用自认为更好、更安全的他人编写的代码呢?
毕竟这些在Github上发布开源代码的人也是开发者，就像我们一样。他们也不是完美的，他们编写的代码可能也有bug。然而，我们却选择相信他们，而不是自己。
我理解读者不愿自己编写像RxJS或者React这样的库。这些大型库已存在多年，有许多贡献者，并且通过了测试。除非想从中学习，否则我不建议大家重新执行这些库。
但是对于较小的、可以轻松编写，并使其完全适应自己需求的功能，我建议读者自行编写代码。这样至少可以在有需要时轻松修改和修复这些功能。
我猜想开发人员对于自己编写代码的不安全感来自于多年使用的库和框架，这些库和框架对我们隐藏了最初的JavaScript平台。这种情况始于jQuery的出现，而且随着Angular和React等框架的出现，这一情况变得更加严重。
这些框架都是抽象概念，人们认为它们本质复杂。正因如此，开发人员往往将这些作为黑盒使用。
重申，我不反对使用框架，因为我确实看到了其所带来的价值。但是现在，似乎整整一代的开发人员，他们只知道如何使用框架进行编程，而对底层平台几乎一无所知。他们不知道如何使用原始DOM，因为他们几乎从未接触过它。
我曾参与过几个evergreen项目，其中的首要问题就是我们应该使用哪个框架，而非我们是否应该使用框架。项目默认的假设就是需要一个框架，而主要论点是框架能提供我们需要的一切，我们不应该重新发明“轮子”。
讽刺的是，这些人中许多都没有扎实的本地平台知识，无法判断所选框架首先是否是一个好选择。
这些框架的复杂性令人生畏，这可以理解，特别是对于初学者来说。他们倾向于将这些框架作为黑盒使用，而不去了解它们的内部工作原理。
框架也不鼓励了解内部工作原理这种行为，因为它们的工作是通过隐藏底层细节和应用编程接口来简化编程。
这就造成了人们对框架的依赖，反过来，也无法给开发人员自己编写代码带来信心。
图源：pexels
使用依赖项就是将业务外包
在应用中使用依赖项时，基本上就是将这一部分外包给其他开发者，所以你最好确保那个开发者做得很好。
倘若你有一家公司，而你把客户服务外包给其他公司，这时如果他们把服务搞砸了，你将面临大麻烦。如果他们对什么是好的客户服务有不同见解呢?
你可能不会让这种情况发生，那么你应该以同样的方式对待应用程序中的依赖项。这并不意味着你需要审阅所有依赖项的源代码，但至少应该切实理解其工作原理。
理解基础原理
但是要做到理解其工作原理，你首先应该切实了解Vanilla JavaScript编程，因为这是一切的基础。
前端框架肯定会带来价值，但也意味着复杂的工作和不菲的运营费用。我经历过学习和执行框架的痛苦，我可以告诉你，你需要确保这些努力是值得的。
使用本地平台很有必要，看看它如今的功能，你会感到震惊。
不要人云亦云地说不应该重新发明“轮子”。首先应该学习基础知识，然后决定是否真的需要这个库或框架。
如此一来，你会成为一名更优秀的开发者。
留言 点赞 关注
我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”
（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）