700万种子轮融资，Astro的正式发布给前端行业带来了什么？_0

就在上周，Astro团队发布了1.0正式版。我从年初就开始关注这个项目，但那时候只学了仓库工程建设相关的东西（changeset，自动发包等），并没有深入了解它自己的功能。趁着正式发布的机会，这几天熟悉了Astro1.0，发现了很多有意思的地方。下面将从团队背景、框架定位、核心优势等维度为大家介绍，最后推荐一些学习资料。团队背景在正式介绍Astro之前，先说说相关背景。Astro的作者是FredK.Schott。没错，他就是开发Snowpack的师兄。可以说是Unbundle构建工具的鼻祖：可惜Vite的发展势头太猛了，Snowpack在逐渐没落。他自己写的看完文章，感慨如下：文章链接：https://dev.to/fredkschott/5-more-things-i-learned-building-snowpack-to-20-000-stars-5dc9大体思路是Snowpack前途黯淡，用户越来越少，感觉要干了，而且Vite发展的很好，所以后面要开发的Astro基于Vite。现在连Snowpack官网都说弃坑了，主动给Vite引流：当然除了Snowpack，FredK.Schott的团队（叫Pika）也做了一个比较知名的产品：Skypack，这是NPM包的ESMCDN服务：不幸的是，Skypack已经很久没有维护了（超过一年）。看得出来，团队已经不想继续投入这个项目了。个人认为主要有两个原因：强大的竞争对手。竞品esm.sh不断迭代，已被Deno官方推荐。这个计划很难实施。这类ESMCDN应用到实际业务项目中还存在很多实际障碍，比如请求量大，没有treeshaking，没有本地调试等，是一个实现起来比较困难的问题。近年来，FredK.Schott团队一直专注于新项目Astro。经过16个月的打磨，Astro在全球拥有超过3万用户，被谷歌、Netlify等大公司使用。Github的star已经达到了15k+。值得一提的是，FredK.Schott为这个项目成立了一家创业公司：TheAstroTechnologyCompany，并已筹集到700万的种子轮投资，打算以开源的方式继续发展。对比一些知名开源项目的赞助收入，比如Webpack[1]22w/年，Babel[2]30w/年，Astro具有经济优势。框架定位接下来说一下Astro框架的定位。是像Vue、React这样的底层渲染框架，还是像Next.js这样的上层研发框架？这对于初学者来说其实是相当麻烦的，因为Astro不仅创建了类似于.vue和.jsx文件的.astro语法，还像Next.js一样提供了常规路由、构造优化等各种运行时能力。、SSR等。但其实它对自己的定位非常明确，那就是一个以内容为核心的应用开发框架。网站等。你可以把Astro理解为垂直场景下的Next.js，但在适用领域它可以超越所有其他竞品（如Next.js、Remix、Vuepress等）。这就是它能做什么的重要原因。接下来，我们就来看看Astro的优势吧。核心优势Astro的主要优势包括以下几点：Islandsarchitecture，解决了传统SSR/SSG框架的全水化问题，实现了尽可能少的客户端JS开销，甚至0JS。学习成本低。.astro语法与传统的.jsx和.vue非常相似，初学者更容易掌握前端。使用灵活。页面开发可以使用官方的.astro语法，也可以使用.md、.vue、.jsx语法。也就是说，你可以自由选择其他前端框架的语法进行开发，甚至可以在一个项目中同时编写Vue组件和React组件！快速构建。底层搭建系统基于Vite和Esbuild实现，项目启动非常快。IslandsArchitecture在上面提到的优势中，让我们关注Astro的Islands架构，因为这是其高性能的主要原因。Islands架构模型早在2019年就被提出，由Preact作者JsonMiller在2011年的IslnadsArchitecture[3]一文中提出，该模型主要用于SSR（包括SSG）应用。我们知道，在传统的SSR应用中，服务端会响应浏览器完整的HTML内容，并在HTML中注入完整的JS脚本来完成事件。结合是完成水合作用（注水）的过程。当注水过程完成后，页面才能真正进行交互。那么当应用的规模逐渐变大，需要在客户端执行的JS脚本越来越多，也就意味着TTI（交互时间）指标越来越高：为了解决这个问题，Islands架构将页面拆分成独立的组件，包括静态组件和交互组件，如下例所示：可以清楚的看到一个页面中只有部分组件交互，那么对于这些??交互组件，我们可以并行执行水合过程,因为组件是相互独立的。对于静态组件，也就是非交互组件，我们可以不让它们参与水化过程，直接复用服务端下发的HTML内容。可交互的组件就像整个页面中的孤岛，所以这种模式被称为孤岛架构。与传统SSR中的全量水化相比，Islands模式可以实现部分水化，从而优化JS的体积，降低网络传输成本和JS运行时的开销。在Astro中，所有组件默认都是静态组件，例如//index.astroimportMyReactComponentfrom'../components/MyReactComponent.jsx';---值得注意的是，这种写法不会添加浏览器中的任何JS代码。但是有时候我们需要在组件中绑定一些交互事件，那么这时候我们就需要激活岛组件，在Astro中如何激活呢？其实很简单，只需要在使用组件的时候添加client:load命令//index.astro---importMyReactComponentfrom'../components/MyReactComponent.jsx';---所以首先，Astro会为这个组件传输一部分JS代码给浏览器，完成后续交互的水化。对比Next.js和Remix看完这里，你可能会说，Astro相比其他行业解决方案有什么优势呢？让我们盘点一下。第一个是著名的Next.js。我们知道Next.js是一个非常经典的ReactSSR框架，它也使用了传统的SSR/SSG技术，几乎可以适用于所有的Web开发场景。但是在Astro适用的以内容为主的场景下，其性能会明显高于Next.js。下面是两个真实的迁移案例：可以看出，与Next.js相比，Astro可以大大减少JS代码的大小（90%以上），页面的运行时性能也提升了30%以上.此外，Astro不仅支持使用React框架，还支持Vue、Solid等各种前端框架，具有更高的灵活性。二是最近流行的菜鸟框架Remix，它基于react-router管理组件。通过loader和action的概念，将逻辑代码尽可能的放到服务端的bundle中，从而减少客户端JS的代码量。也提倡0JS，但是Remix还是需要全水化，不能完成部分水化。除此之外，Astro还有两大优势：除了React，它还支持很多其他的前端框架；它同时支持SSR和SSG，而Remix不支持SSG。相比React18的SelectionHydration特性，React18提供了renderToPipeableStreamAPI，真正实现了SSR场景下的SelectionHydration。主要特点如下：组件可以在完整的HTML渲染之前进行水合，无需等待HTML内容发送后，水合可以中断。例如，页面上有两个组件：Sidebar和Comment。当这部分HTML被发送到浏览器时，React打算开始对Sidebar组件进行水化：如果用户在这个过程中点击Comment组件，React会中断当前侧边栏组件的水化，从而执行的水化Comment组件：详见React18SSR架构：https://github.com/reactwg/react-18/discussions/37然后是Astro中的Islands架构，即PartialHydration，和React的IsSelectionHydrationathing?答案是否定的。两者有很大的区别：从渲染框架的角度来看，SelectionHydration是依附于特定框架的实现，而PartialHydration可以独立于框架，甚至Vue和Solid项目也可以实现PartialHydration。从客户端执行的JS总量来看，PartialHydration可以加载部分组件的JS代码，而SelectionHydration仍然需要加载执行全量的JS代码。从服务端和客户端的交互来看，SelectionHydration非常依赖流式（Streaming）渲染。服务器需要添加一个transfer-encoding:chunked响应头，而PartialHydration没有这个限制。因此，两者虽然都在Hydration上做文章，但实际上是两种完全不同的方案，PartialHydration更通用，限制更少，执行的JS更少。总结以上就是Astro的介绍和分析，以后有机会再分析内部源码实现。文中如有不当之处，欢迎大家评论指正。最后推荐一些Astro的学习资料，让大家看完文章后能学到更多：Astro官方文档：https://astro.build/。Astro实用系列教程：https://aalam.in/blog/astro-get-up-and-running。参考文献[1]Webpack：https://opencollective.com/webpack。[2]巴别塔：https://opencollective.com/babel。[3]Islnads架构：https://jasonformat.com/islands-architecture/。