Next.js 真的是越来越难用了，什么狗屁 use client，不如 Astro 一根，有什么话跟我的岛屿说去吧

不懂就问，岛屿是什么

@webwlx astro 的架构的中译吧

@webwlx https://docs.astro.build/zh-cn/concepts/islands/#%E5%AE%A2%E6%88%B7%E7%AB%AF%E7%BE%A4%E5%B2%9B
https://docs.astro.build/zh-cn/guides/framework-components/#%E6%B7%B7%E5%90%88%E6%A1%86%E6%9E%B6
https://docs.astro.build/zh-cn/guides/framework-components/#%E6%BF%80%E6%B4%BB%E7%BB%84%E4%BB%B6

你可以选择任何你喜欢的 UI 框架（ React 、Vue 等等），并且你无需做任何额外操作，Astro 默认将为你自动移除组件的所有 JavaScript 并渲染静态 HTML （你也可以按需使用 SSR 方案动态渲染数据，且支持流式渲染）。默认你网站的 Lighthouse 一定是 100 分，可以让你完全按需加载组件，比如设置 client:visible ，只有当该组件在可视范围内才会加载该组件的 JS 进行交互。一些非常简单的交互你甚至完全不需要 client 指令加载 JS ，直接使用原生 JS 操作一下 DOM 属性或 class 即可实现。实际上大部分交互实际上都可以通过纯 CSS 实现，或只需要额外添加一个属性实现切换效果，只有交互相对复杂，比较重的组件才需要加载框架 JS 进行交互。你不需要像 Next.js 一样愚蠢的在每个文件添加 'use client;' 指令，Astro 会自动为你完成所有工作，你也不用再担心随着网站功能越堆越多导致整个网站的 JS 越来越大，使用起来不再有心智负担。Astro 使用起来非常简单，没有复杂的“Next.js 专属特性”，一些没有办法实现的功能或选项不用再看 Vercel 的脸色，你可以完全掌控你的网站。

我用 Astro 专门搞 SSG 的网站. 功能组件也是加的 React 扩展.
目前还没搞 SSR, 打算后期用 Next 搞 SSR.

Next.js 真的是很愚蠢。不只是有的地方要用 'use client'，有的地方还莫名其妙变成客户端渲染的时候还得手动加 'use server'。人为地搞得很复杂，导致我觉得自己愚蠢。要不是看到别人抱怨，我还以为是我不配呢。

之前没认真看过 Astro ，多谢分享。它这种架构还挺棒的。

@importmeta Astro 也可以 SSR 呀，用 Next 准备后悔吧
https://docs.astro.build/zh-cn/guides/on-demand-rendering/

@twig #5 对，愚蠢至极，我一开始以为服务器组件会参考 Astro 的实现，谁知道他拉了一坨大的😅
而且每个大版本都有一些破坏性改动，一些特殊需求还需要用 Hack 的方式实现，Vercel 团队又固执又傲慢，你必须按照他们的方式来做，烦都烦死

React 目前已经和 Next.js 半捆绑了，这才是最烦的。

@twig 啥时候莫名其妙会变成客户端渲染，默认不都是服务端渲染嘛

cal.com 这种级别的 oss 也是最近几个月才搞明白。除了坚定地抄他们的 pattern ， 别无他法。X 上大家都苦 Nextjs 久矣。 能用就用吧. 不行就换，tanstack-start 现在用的人也越来越多了。

试试 Tanstack Start

Astro 也要服务器有 node.js 环境吧，不喜欢 next.js 就是因为不想在服务器装 node.js

@andrew2558 为啥不想装呢？

@andrew2558
Astro 是可以写纯前端项目的

已经用 Astro 把自己的博客重构了，感觉就是两个字，自由。

@Plumbiu 你问我，我就装糊涂。啊不，我是真糊涂。Next.js 让我很困扰就对了。

Tanstack Start 表示很好用

虽然喜欢不喜欢 next.js 是个人观点，其次楼上的各种说法其实都有些事实错误。

首先你只需要在顶层的组件中开启 use client ，所有子组件也会判断为 client side component 。你们遇到这个问题绝对是每次创建新 page.tsx 的时候没有写 use client ，当然你也可以说“在每个文件”……

其次我个人觉得“选择任何 UI 框架，Astro 给你自动做静态渲染”这个看起来很牛逼的 propaganda 实际上会出很明显的 edge case ，你无法保证所有你写的组件或者你用的依赖都是面向静态的，我认为这会造成很多未预料的事情……当然写博客这种写一次用一辈子的项目可能并不需要考虑这些事情，但我觉得这个事情本身和 Next.js 默认 server side 本质上没有任何区别。

混合框架会很明显的导致整个客户端包体积显著上升，当然你全写的是静态那是另说，但另外我觉得如果一个项目能混用这么多 web 框架，那这个项目本身其实就有点炫技的成分在里面，哪有真产品一下子什么框架都有。

不过 选择性水合（ partial hydration ）这个事情我倒是很赞同，我目前在一个 react framework 里面也推进了这个特性，不过我觉得群岛概念这个属于新瓶装旧酒，没什么新奇的，你只不过是本来多套一层组件变成了 props 里的保留关键字。

另外我仔细阅读这个文档的时候发现了一个逻辑错误，https://docs.astro.build/zh-cn/guides/server-islands/#%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%BE%A4%E5%B2%9B%E7%BB%84%E4%BB%B6
这里头像回退 GenericAvatar 的 slot fallback 虽然没有写放在哪里，但是我假定是 Avatar 的一个 children ，但是问题来了，如果做到不运行 Avatar 里面的请求代码的同时把 GenericAvatar 插进去。

不是一样要标 client：*吗？和 use client 区别在哪？编译器还能帮你检查使用了 hooks 的组件有没有标 use client 。