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

将我们对launchdark的使用转移到服务器端，这样我们就可以加载更少的JS并降低整体成本。
通过后端路由代理我们的Sentry请求，这样我们就可以捕捉错误，否则将由于广告拦截器导致没有被报告。
而这仅仅是冰山一角。这种模式真的有很多很酷的地方，其中最大的一点是它如何重振渐进式增强的理念，利用服务器和客户端的组合特性，允许客户端在用户禁用JavaScript的情况下回退到基本的HTML+HTTP 。当我开始从事SPA工作时，我已经完全放弃了这种做法，认为它们只是未来的趋势，但我们有可能看到它再次回归的景象，这真的很酷。
从经验上看，根据这些新功能，我把这些框架归类为新一代的框架。以前难以解决或不可能解决的问题现在变得微不足道，只是改变了一点点响应处理逻辑。不需要任何额外的配置的情况下，可靠的性能和用户体验是信手拈来的。我们不需要建立整个新的服务，而是能够根据需要添加一些额外的端点或中间件。这已经改变了生活。
我认为这一代框架也解决了第一代和第二代框架及其用户之间的一些主要矛盾点。它始于向零配置术语的转变，但我认为它最终是由第二代框架周围的衍生的系统所驱动的，并逐渐变得成熟和稳定。第三代框架现在又开始尝试成为一体化的解决方案，试图解决我们作为前端开发者需要解决的所有基本问题，而不仅仅是渲染问题。
现在比以往任何时候都更感觉到社区在解决困扰SPA的所有问题上是一致的，而且重要的是，他们在一起解决这些问题。
我们下一步该怎么走？
总的来说，我认为JavaScript社区正朝着正确的方向发展。
当下的开发者们正在专注研究从头开始构建完整应用程序的成熟解决方案，这些解决方案并不局限于"一个视图层" 。同时，我们终于开始与原生应用的SDK在同一起跑线上竞争，提供一个开箱即用的完整工具包。
接下来，我们仍有很多工作要做。在SPA领域，可访问性是一个长期需要解决的问题；在GraphQL之外，我仍然认为数据可以被用来实现一些功能（不管你喜欢与否，大部分的网络仍然运行在REST上）。但趋势是正确的，如果我们继续朝着共享解决方案的方向发展，我认为我们可以用比以前更好的方式解决这些问题。
我还对将这些模式更进一步带到网络平台本身背后的潜力感到兴奋。 Web组件仍在悄悄地迭代，致力于解决SSR和摆脱全局注册等问题，这将使它们与这些第三代框架更加兼容。在另一个方向， WebAssembly可以以一种令人难以置信的方式迭代这种模式。想象一下，能够用任何语言编写一个全栈框架。同类型的Rust、Python、Swift、Java等语言最终可以将前端和后端之间的障碍减少到几乎为零，只是在你的系统边缘有一点HTML模板（讽刺的是，尽管有了更好的用户体验，但这使我们几乎绕了一圈）。
如果我们能够让开发者在默认情况下就能用上合适的工具，也许网站的运行状况会变得更好，用户体验会变得更流畅。虽然框架的好坏并不能解决网站的所有问题，但是这将为网站往良好的方向发展奠定一个基础，也能让每个开发人员都有更多的时间专注于其他事情。
【JavaScript框架发展的四个时代，你经历过其中几个阶段?】END