不过说实话，这篇文章写的是很不错的。概括下他对 Next.js 的批判:
- Next.js 倾向于制造新的概念和术语，将许多基础 Web API 藏的太深，在 Next.js 中学习到的知识很多是无法通用的。Kent 强调框架应尽可能让用户使用 transferrable knowledge, 认为 Remix 在这点做的更好。
- Next.js 重载了一些基础 Web API 如 fetch，这违背了软件设计的「最小惊讶原则」 (POLA)，容易使用户困惑，并对 debug 造成诸多不便；Next 的 API 多且复杂，同样体现出优秀软件设计理念的缺失。
- Next.js 脱离了 Vercel 难以很好地独立部署，方文档关于独立部署的示例只是简单地在容器里跑 next start 而已。被 Vercel vendor lock-in 存在很多风险，比如价格昂贵、前景不明朗（Vecel 尚未盈利）等等。
- Next.js 正在模糊 React 和 Next 本身的边界，尤其是在 server components 和 server actions 的问题上。Next 团队雇佣了很多 React 员工，这可能会使得 React 无法保持中立，造成与其他框架间的非正当竞争。
- Next.js 缺乏稳定性。Next.js 最新的 stable 版本 (version 13) 依赖 React 的 canary 功能，在 Kent 看来这非常离谱，并且他听到过许多对于 Next 不稳定的抱怨。
- Next.js 倾向于制造新的概念和术语，将许多基础 Web API 藏的太深，在 Next.js 中学习到的知识很多是无法通用的。Kent 强调框架应尽可能让用户使用 transferrable knowledge, 认为 Remix 在这点做的更好。
- Next.js 重载了一些基础 Web API 如 fetch，这违背了软件设计的「最小惊讶原则」 (POLA)，容易使用户困惑，并对 debug 造成诸多不便；Next 的 API 多且复杂，同样体现出优秀软件设计理念的缺失。
- Next.js 脱离了 Vercel 难以很好地独立部署，方文档关于独立部署的示例只是简单地在容器里跑 next start 而已。被 Vercel vendor lock-in 存在很多风险，比如价格昂贵、前景不明朗（Vecel 尚未盈利）等等。
- Next.js 正在模糊 React 和 Next 本身的边界，尤其是在 server components 和 server actions 的问题上。Next 团队雇佣了很多 React 员工，这可能会使得 React 无法保持中立，造成与其他框架间的非正当竞争。
- Next.js 缺乏稳定性。Next.js 最新的 stable 版本 (version 13) 依赖 React 的 canary 功能，在 Kent 看来这非常离谱，并且他听到过许多对于 Next 不稳定的抱怨。