Web前端工程师会“抛弃 React、Angular”吗？

Web前端工程师会“抛弃 React、Angular”？

时至2019年，我们都已达成了一项共识：组件可以构建快速、优雅且可维护的UI。

问题在于，每个框架（例如ReactJs、AngularJS、Vue.js或其他一些较小的UI框架）在解决常见的问题时，都会使用自己的模式和解决方案。

这些框架促进了可重用性，且易于使用。 另外，我听说这些框架背后都有Google或Facebook等大公司的支持。

在本文中，我们来讨论一下，这种说法是否属实，社区是否可以做的更好，以及我们是否有更好的选择。

Web网站、Web应用程序，PWA或其他一切在浏览器中运行的代码最终都会化作HTML、CSS和JavaScript（也许还有Web Assembly）。

那么，我们的目标是应该熟练地使用这些工具。我并没有说我们就使用这些工具，不要理会任何类型的库或框架。

我们都应该使用，但如果我们的选择过多，那么会怎样？ 事实上，如今的选择确实过多！多到让你觉得有点头晕。

这些工具非但没有加快你的速度，甚至还成为了累赘，因为你 不知道应该使用哪个前端UI库。 有时，你会想：“以后我就使用ReactJS”。

这也不是不行。

ReactJS是一种非常好的解决方案，但我们还有Angular以及其他UI框架。这意味着我们无法像一个社区那样协同工作，而是需要将自己分散到这些小社区中。

尤其是当你发现其中大多数工具都缺乏我们日常使用的功能时，就会觉得更加糟糕。

ReactJS中的Router一点也不好玩。表单验证也很没劲，没人愿意做。

因此，我们需要在这些UI框架的基础上，再建立别的代码库，而且在大多数情况下，我们需要建立2-3库来执行这些操作。我们不仅需要在UI框架上花费心思，而且还要付出努力重新编写基本的代码。我们浪费了多少时间。 可能有人看到这里会想，这似乎也算一件好事啊！ 真的吗？

请搜索：“Linux 桌面系统元年”。

Linux 桌面系统也有同样的问题：Gnome、KDE、XFCE、Cinnamon、Mate、LXDE等等。

这些都在试图解决一个问题：改进Linux 桌面系统。

但他们成功了吗？ 接下来我们来谈一谈可重用性。

有人记得从Angular 1到Angular 2的跳转吗？

这两个版本就像两个完全不同的框架。

现在我们有了Angular和AngularJS，它们一点都不令人困惑。

你可能在想：“但是，ReactJS没有重大变化呀。”

虽说如此，ReactJS的两个版本之间没有如此巨大的变化！

但我问你，你敢在不使用钩子的地方发布React代码吗？相信评论中会有一半人说：“为什么不使用钩子？”

在你需要将基于类的组件重写为基于函数的组件时，也会发生同样的情况。

现在我问你一个问题，你必须如实回答，而且也不要冠冕堂皇地说：“我是编程高手，我想使用最新潮的技术”，而是让我们本着“解决实际问题并为人们提供解决方案”的态度。

我的问题是：ReactJS的这些变化真的为你的客户带来了任何价值吗？对于你的用户呢？对于你的公司呢？代码的可阅读性提高了吗？

如果如实回答，那么你可能会承认基于类的组件也很不错。仔细想一想，我们是不是被营销欺骗了？

你可能想说，这与市场营销有什么关系？请不要忘记，是谁创建了ReactJS？是Facebook！那么又是谁创建了AngularJS？是谷歌。

这两家公司最有名的是什么？

如果你想说一家是社交网络，而另一家互联网搜索，那么你又错了！

他们都是以广告和营销著称！如果你想了解一家公司真正的业绩，那就不应该看产品，而应该看他们的盈利点。

我经常听到有人说：“某某框架背后有一家大公司的支持，所以这个框架一定不错”，我觉得你应该冷静下来仔细思考。

这句话的意思是说，由于你使用的框架背后有一家拥有大量资金的公司的支持，所以这个框架不会在某一天消失。

然而，谷歌是著名的项目杀手。

人们还特意建立了一个网站来纪念被谷歌干掉的项目链接 我希望你能看到Web开发社区目前遇到的一些问题。

我们该如何解决？我个人认为，我们有现成的解决这些问题的正确方法。那就是制定正确的标准！

W3C是一个优秀的组织，应该有更多来自社区的人参与其中。但这是另一个话题了。 为什么标准可以帮助我们解决所有问题？

当一项技术成为一项标准时，所有主流浏览器都会实现并使用这项标准。对开发人员来说，这意味着不需要额外的库，也不需要考虑其他浏览器中的边缘情况。

即便有Bug或问题，也有相关责任者为所有用户修复Bug。 因此，只需由一个人出面修改一次，而不需要成千上万的开发人员独自修改。

这有助于解决社区分裂的问题。如果编写的某个组件可以同时在Vue.js、Angular和ReactJS中使用，那该多美好？

这样更多的开发人员可以改进同一个Calendar组件，并创建优秀的组件，而不是创造出20个半成品的日历组件。

如果这一切都不需要大公司的支持，只需社区和浏览器厂商支持就够了的话该多好？ 其实所有这些情况都曾经出现过，只不过我们现在忘记了！

没错，我们确实忘记了！这项技术叫做“Web组件v1”。 早在2014年，我们这个社区针对应该使用Web组件还是ReactJS的问题，发生过激烈的争论。

最后，众所周知，我们选择了ReactJS。

这在当时可能是正确的选择，因为Web组件还太年轻，而且规范还没有准备好。

因此我们称之为Web组件v0，但自2018年以来我们现在有了v1。现在，所有大公司都接受了这个规范，并开始实施——极个别情况除外。

此外，对于旧版本的浏览器还可以使用Polyfill。 至于，Web组件v1的用法，以及以及如何将它们集成到当前项目中，这个话题我们日后再谈。