JavaScript框架发展的四个时代，你经历过其中几个阶段?( 四 ) 【CSDN编者按】从1995年JavaScri

它极大地缩小了范围。这些框架的核心不是试图解决前端所有问题，而是专注于渲染，关于实现其他功能的许多不同的想法和方向可以在更广泛的系统中探索。尽管有很多糟糕的解决方案，但也有好的解决方案，这也为下一代从精英中挑选最好的创意铺平了道路。
这让开发人员更容易接受。采用一个完整的框架来接管你的整个网页，意味着你需要重写大部分应用程序，这对于现有的服务器端来说是不可能的。使用像React和Vue这样的框架，你可以把它们中的一小部分放到一个现有的应用程序中，每次只迁移一个小部件或组件，允许开发人员逐步迁移他们现有的代码。
这两个因素导致第二代框架迅速发展，使第一代框架黯然失色。从长远看来，这一切似乎很有意义，是一种合理的演变。但对于当时身处其中的我来说，是一段令人相当沮丧的经历。

文章图片
首先，在工作中关于框架选择的争论，不会是我们应该使用哪种框架来开发，或者我们是否应该重写我们的应用程序。相反，经常是"它更快！"或"它更小！"或"它是你需要的一切！" 。还有关于函数式编程和面向对象编程的辩论，很多人把FP作为我们所有问题的解决方案。平心而论，这些事情都是真的。仅有视图层的框架起初更小、更快，而且是你所需要的全部（如果你自己建立或缝合了很多东西）。当然，函数式编程模式解决了大量困扰JavaScript的问题，而且我认为总体来说， JS因为它们而变得更好。
然而现实是，根本就没有什么灵丹妙药。应用程序仍然变得庞大、臃肿和复杂，状态仍然难以管理，路由和SSR等基本问题仍然需要解决。对于我们很多人来说，似乎人们想要的是抛弃试图解决所有这些问题的解决方案，而把这个问题留给读者。在我的经验里，开发团队中普遍会很高兴地接受这种想法，以便快速发布一个新产品或新功能。然而他们却没有足够的时间来充分开发所有额外的功能。
结果，根据我的经验，开发更多的时候是围绕这些视图层建立的自制框架，这些框架本身就很臃肿、复杂，而且非常难以操作。我认为人们在SPA上遇到的许多问题都来自于这个支离破碎的框架系统，而这个框架系统恰好出现在SPA使用量激增的时候。我仍然经常遇到一个新网站不能很好地处理路由或其他小细节，这绝对是令人沮丧的。
但另一方面，现有的全服务第一代框架也不能很好地解决这些问题。部分原因在于依然有大量的科技债务负担。第一代框架是在ES6之前，同时也在模块以及Babel和Webpack之前，是在我们弄清楚许多事情之前建立的。迭代进化是非常困难的（作为前Ember核心团队成员，我对此深有体会），而且完全重写它们，就像Angular对Angular2所做的那样，扼杀了他们的发展势头。因此，当涉及到JavaScript框架时，开发人员处于两难境地——要么选择一个过时的一体化解决方案，要么选择自由发挥，并DIY一半的框架，以此希望得到最好的结果。
就像我说的，当时这让人非常沮丧，可到最后还是涌现了大量的创新。随着找出这些框架的最佳实践， JavaScript的整个系统都发展得非常快，还发生了一些其他的关键变化：
像Babel这样的转译器成为常态，并有助于使语言现代化。与其等待数年才能实现功能的标准化，不如今天就能使用，而且语言本身也开始以更快、更多的迭代速度增加功能。