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

ES模块被标准化，使我们最终能够开始围绕它们构建现代的构建工具，如Rollup、Webpack和Parcel 。基于导入的捆绑慢慢成为规范，即使是样式和图片等非JS资产也是如此，这极大地简化了构建工具的配置，使它们变得更精简、更快速，总体上更上一层楼。
随着越来越多的API被标准化， Node和Web标准之间的差距也慢慢缩小。 SSR开始成为一种真正的可能性，随后变成每个标准的应用程序都在做的事情，但每次都是某种程度上的定制化设置。
边缘计算的发布，使基于JavaScript的服务器应用程序在分发/响应时间方面获得了SPA的好处（SPA由于是CDN上的静态文件，所以以前一般可以更快地开始加载，即使最后完全加载和渲染需要更长时间）。
到这个时代结束时，仍然存在一些问题。即使我们有了比以前更好的模式，但状态管理和反应性至今都是棘手的问题。性能情况也正在改善，可仍然存在许多臃肿的SPA 。可访问性的情况也经常是许多开发团队事后的想法。但这些变化为下一代框架铺平了道路。而我想说，我们刚刚进入下一个框架时代。
全栈式框架
就我个人而言，最后一个框架时代真的悄悄来到了我们身边。我想这是因为我花了4年左右的时间深入到Ember渲染层的内部，试图清理前面提到的，仍然影响它作为第一代框架的技术债务。但这也是因为它更加微妙，因为所有这些第三代框架都是围绕上一代的视图层框架构建的。著名的框架包括：
Next.js(React)
Nuxt.js(Vue)
Remix(React)
SvelteKit(Svelte)
Gatsby(React)
Astro(Any)
这些框架随着视图层的成熟和固化而出现。既然我们都同意组件是构建框架的核心基础，那么就有必要开始标准化应用程序的其他部分——路由器、构建系统、文件夹结构等等。慢慢地，这些元框架开始构建第一代一体化解决方案所能提供的相同功能，从各组件内部中选择最佳的模式，并随着它们的成熟而将它们合并，随后再更进一步发展。
到目前为止， SPA一直专注于客户端。 SSR是每个框架都渴望解决的问题，但只是作为一种优化，一种渲染的方式，最终会在JS加载完成后被替换。第一代框架中只有一个敢于做得更大，那就是Meteor.js ，但它的“同构JS”理念从未真正实现。
但随着应用程序的规模和复杂性的增长，这个想法被重新审视。我们注意到，将后端和前端组合在一起是非常有用的，这样你就可以为某些请求隐藏API秘密、在页面返回时修改header、代理API请求。随着Node和Deno实现越来越多的web标准，服务器端JS和客户端JS之间的差距每年都在缩小，这似乎不再是一个疯狂的想法。将它与边缘计算和令人惊叹的工具相结合，你就有了不可思议的潜力。
最新一代的框架充分利用了这一潜力，将客户端和服务器无缝地融合在一起，我无法强调这是多么令人惊叹的感觉。在过去的9个月里，我和SvelteKit一起工作，坐下来的并感叹:“我们应该一直这样做。 ”的次数多得数不清了。
以下是我最近完成的一些任务，通过这个设置，它们变得非常容易:
添加服务器端OAuth到我们的应用程序，这样authToken永远不会离开服务器，同时还有一个API代理，每当一个请求发送到我们的API时添加Token 。
将某些路由直接代理到我们的CDN ，这样我们就可以托管内置在任何其他框架中的静态HTML页面，允许用户制作他们自己的定制页面(这是我们为一些客户提供的服务) 。
当我们需要使用需要密钥的外部服务时，添加几个不同的一次性API路由(不需要添加一个全新的路由到我们的API并与后端人员协调) 。