我最近遇到一个论点，认为新的web开发不应该使用前端框架（Angular、React、Vue等），因为要跟上新版本的依赖关系，需要承担维护负担。理由是这种维护负担是不合理的，因为大多数应用程序不再需要前端框架了。
这是真的吗？让我们在一家中大型公司的典型开发车间的背景下研究一下这一说法，该公司负责许多应用程序，包括面向企业和面向消费者的应用程序。我将使用Angular作为我的框架示例。
从不需要框架
争论的关键在于，由于JavaScript、CSS和浏览器功能的进步，不再需要框架。但我认为这在一定程度上夸大了事实。做任何事情都不需要框架。前端框架提供JavaScript（JavaScript中嵌入HTML）和CSS。因此，框架从来没有做过单独使用JavaScript/CSS无法完成的事情。他们只是让这些事情变得更容易，因此速度也更快。
它与非常相似。NET框架。什么时候NET发布后，它所能做的一切都是C/C++所不能做的。这个NET框架使它更容易，因此可以更快地进行Windows开发。我还记得当时的一些反击。NET源于C/C++开发人员，他们认为你应该咬紧牙关学习C/C++。我记得一开始我觉得自己有点不如那些开发人员，因为我使用的框架的既定目的是让事情变得更容易，这感觉像是“作弊”。
但企业希望快速见效。因此，一个使开发更容易、更快的框架将流行起来，这就是发生的事情。NET。很难证明在什么时候投入时间来学习和开发C/C++是合理的。NET要容易得多，这正是公司所寻求的。
我认为前端JavaScript框架的情况过去（现在）是相似的。当然，你可以用简单的JavaScript/CSS/HTML做任何事情，但当有更容易学习和实现的替代方案，并且可以更快地提供解决方案时，很难不走这条路——至少对于那些必须用有限资源提供许多应用程序的公司来说是这样。
框架功能
诚然，JavaScript和浏览器功能已经取得了进步，其中许多都是由前端框架驱动的。ES6对类和模块的支持为我们提供了一种用纯JavaScript构建代码的方法。创建封装功能并通过自定义事件进行通信的自定义元素的能力使我们能够创建可重复使用的组件。这些进步使使用普通JavaScript的开发比过去更容易。
但我不相信，在快速构建复杂的web应用程序方面，普通JavaScript与前端框架不相上下。
例如，让我们看看计数器组件的自定义元素示例。计数器组件是您可以实现的最简单的反应组件之一，通常用于演示目的。左边是计数器组件的实现，它是一个只使用普通JavaScript的自定义HTML元素。右边是使用Angular组件（v17）的相同实现。
自定义图元和Angular构件之间的比较
Angular组件使用的行数不到自定义元素的一半。此外，Angular生成了组件的样板，因此我只需要在红框中编写代码。此外，使用Angular解决方案，我可以选择将模板移动到自己的HTML文件中，这是我非常喜欢的。如果我们看到最简单组件的实现有这么大的差异，那么复杂组件会是什么样子？
另一件需要注意的事情是，Angular在将值注入DOM之前会对其进行净化，以防范XSS漏洞。这对这个组件来说不是必要的，但对许多其他组件来说是必要的，这是团队必须以可重用的方式为自己实现的功能的一个例子。
此外，JavaScript不是一种类型安全的语言——也就是说，直到运行时才会发现类型错误，而且你几乎没有得到有用的智能感知。类型检查是否重要是一个单独的话题，但许多人认为它是重要的，这就是为什么Angular使用TypeScript来进行编译时类型检查并提供强大的智能感知。当然，您可以在不使用前端框架的情况下使用TypeScript，但您必须自己处理转换。
最后，像Angular这样的框架提供的不仅仅是一种更容易创建自定义组件的方法。它们还提供服务和其他功能。仅举一个例子，在Angular中，很容易创建一个可以用来修改所有HTTP请求的拦截器。这样的拦截器对于添加API调用的身份验证头值等操作非常有用。让我们在下一节中看看我们如何自己实现这样的东西。
依赖关系不会消失——它们只是发生了变化
让我们回到上一节中刚刚提到的HTTP拦截器的例子。如果我只是使用普通的JavaScript，我将如何实现这一点？
起初，我可能会在提出请求的任何地方重复逻辑。我很快就会意识到我违反了DRY原则，我会把这个逻辑移到一个共享模块中，然后把这个模块导入到我想使用的任何地方。但后来我会意识到，我希望我公司的其他应用程序都能使用这个功能，所以我会把它做成一个库，这样所有应用程序都可以以版本化的方式使用它。
然后我会意识到不同的应用程序有不同的用例，所以我需要对代码进行配置，以便它能在不同的场景中工作。然后我会意识到，能够对同一个请求多次执行此操作会很好，因此我会想出一种方法，将多个更改应用于同一请求，并按照开发人员确定的顺序执行。
每次我对库进行更改时，我都必须了解使用库的不同方式，并注意不要破坏现有的实现。如果本机webRequest浏览器API以某种基本的方式发生了变化，或者被其他东西取代，我将希望利用库中的这些变化。事实上，如果某些更改影响了浏览器支持，即浏览器更新将导致我的解决方案不再工作，我可能会被迫做出这些更改并迅速做出。
但我可能无法以100%向后兼容的方式做到这一点。因此，在这种情况下，我将不得不保留向后兼容的实现，同时还要实现一个新的解决方案，并找出迁移库的使用者的方法。所有这些都是在没有任何第三方依赖关系的情况下进行的。但现在我所在组织中的应用程序依赖于这个库，我必须自己维护它。显然，这只是共享功能的一个例子，当然还有很多其他例子。
接受开放标准是好事
但我确实认为，如果我们能够做一些得到本土支持的事情，我们就应该尝试本土做。我相信Angular同意这一点，随着JavaScript、CSS和浏览器的发展，他们会定期放弃自己的自定义实现。
例如，一旦不再需要自定义解决方案，他们就不赞成使用自定义的flex box解决方案，而赞成使用纯CSS。他们还介绍了一种配置HttpClient以使用本机fetch API的方法。Angular也不再使用自己的模块，因为ES6支持这些模块。
结论
我们是使用别人提供的解决方案，还是推出自己的解决方案？这不是一个新问题。一般来说，我认为公司选择使用其他公司提供的解决方案来加快开发，因为他们没有资源（在技能或数量方面，或者两者兼有）来实施自己的解决方案。
然而，这确实带来了一种权衡，即您必须跟上引入的依赖关系。但我认为，对于许多实现企业应用程序的公司来说，平衡仍然有利于使用前端框架。
- 登录 发表评论