不是第一次在 v 站看到 next.js 的帖子了，属于是一回生二回熟，到第三回第四回的时候确实有点感觉是不是有什么我不知道的技术潮流了
于是去查了一下，说实话并未感觉到有什么有 next 要素的地方，感觉还是技术大牛自带流量的引导作用更强一些，功能性上就是集成了 SSR 的 react ，附带一些 node 的功能。。。当然因为我本身不是搞前端的，我感觉如何不重要。不过感觉上比起目前通行的工具，似乎并没有什么实质生产力提升。虽然有一个好用的 SSR 很好啦，但是问题是 SPA 这么多年不也用过来了，倒也没感觉没有 SSR 就罪恶到要枪毙。。。
另外本身架构设计上，我只是简单找了个介绍视频看了下。看的时候几个怀疑，一个是基于文件系统目录结构构建的路由被认为是设计优势，不过按照广泛编程语言的广泛实践，纵观主流语言的包管理系统，maven 、pip 、npm 、cargo 等等，似乎基于文件目录的设计在 2024 年已经被广泛地认为是逊于不依赖的设计，我不是很理解新项目搞这么一出的优势在哪里。另外一个就是，如果未来 web 生态真的（重新）拥抱静态生成的话，对大规模项目来说 next.js 方案的内存占用和路由转发性能是不是都略瓶颈。所以这个项目是被设计用来在啥场景替代啥落后生产力的

HTML files + JQuery -> SPA -> Angular/React/Vue -> 哎呀没有 SSR 来做好 delivery HTML files (e.g. for SEO)-> 新造"前端框架"来解决传统 file delivery 问题 -> Next.js (真的能解决吗? 不该自己控制 HTML files 生成和发布到 CDN 吗...?)作为后端, 你可以遇见, 这类"新的前端知识"会一直增长下去的...如果不是"面向前端主流编程", 比如要找前端工作的, 建议保持在类 HTML files + JQuery 的设计上, 相对稳定. 可以用 alpinejs.dev + HTML files

对我来说，最喜欢的应该是免费部署吧，写完了可以免费用。

可能你没有真正用过…主要不就是开箱即用，用起来不折腾，让你专注写业务吗。

五年前就开始用了，现在这货也备受指责，越来越重，上手门槛越来越高，而且改来改去，几个月前发现改成 app router 很多写法又变了，就算熟悉 react 用这个也要学不少它独有的写法。所以很多人叛逃到了 remix ，astro 这些框架上。

基于文件目录其实没什么问题，和后端包管理器不一样，前端一个路径对应一个页面对用户友好。

next.js 的价值在于快递启动光集成 react+typescript+hotreload+bundle 优化+css module+router+ssr+deploy 就够喝好几壶了使用 next.js 相当于雇了一个专业团队帮你搞定了这些事情，直接上手堆业务就行当然我也不是很喜欢 next.js 这种强绑定基建的框架，vercel 的恰饭逻辑是把你困在他们打造的场景里持续消费，所以我不建议一条道走到黑，快速实现原形后就应该想办法拆除框架

我觉得楼主可以试试 SvelteKit 。会原生 JavaScript 就会 Svelte ，几乎没有上手成本，不用操心状态管理。不过它由于起步较晚（ 2019 年），现在生态还比较匮乏。

跟 springboot 火的原因一样，提供了一整套效果还行的解决方案。

我也好几年尝试了，感觉确实很多坑今年又捡回来了， 感觉还行，这几年进步很多

＃2 已读乱回？有哪些 pages 不让部署静态资源？

很多好处只有自己用了才能感受，看一万篇帖子也 GET 不到。

好不好用我不好说，我只写了一个 oauth2 的 provider 。但是这个东西升级过快，没有 LTS 版本，组件包含的东西又多，反正生产系统里我是建议是谨慎考虑的。别因为有 breaking changes 卡住安全更新。这点跟楼上提到的 spring-boot 不一样，spring-boot 的 API 已经很稳定了。

前端这样的旅程，要考多少泪水来完整，新造的轮子。

曾经我茫然前行，前端的路上。优雅刺痛著灵魂，找不到应该的方向。 前端这样的旅程，要用多少泪水来完整。是否我能期待遥远天际，一起编程，新造的轮子😃🎸🎵🎵

因为现在很多前端都是写管理后台的拼图仔（页面仔）？都是已经在搭好基建的框架上面堆业务代码。所以感觉不到有区别，就会感觉到“为了一个不太重要的 SEO”折腾了那么多东西。所以如果只看流行，忽略了就业环境和工作环境，确实会很迷惑。

从后端角度看 SSR 确实很微妙……感觉就像在看人把一个早就存在的东西换了个角度重新发明出来。

1. 后台系统用 react 的脚手架，例如 antd pro 。网站（门户、官网、工具站、博客、FAQ 、论坛）用 nextjs ，可以无缝实现 SEO 的强支持，完美解决了 SPA 在 SEO 的方面弱项（面试必问的问题）2. 用 Next.js 写页面，可以平替 PHP ，React 的语言结构真没的说，jsx 用起来哔 Vue 灵活太多了

next 的优势不仅仅在于框架自身，还在于和 vercel 搭配，上手试试就知道了

前端就喜欢瞎几把改瞎几把造轮子，用多了 Vue 、React 之类的框架，最终还是回归了 Laravel(ThinkPHP)+代码模板一把梭，稳定性、SEO 、响应速度都提成了不止一点点。

Next.js 的价值在于可以在 Edge 进行计算，怎样自己私有化部署就不现实了，就要用现成的云平台，如 Vercel ，这样想快乐地使用开源软件的全部能力就很难了。React 的开发团队直接在文档里推这种方式，不能说没有一点利益关系。

Next.js 的香来自于 Vercel 这个平台，不在于技术本身。你要知道，CI/CD 、环境隔离、日志监控、HTTPS 证书、域名一套全部解决了，这是多么省事儿！

解决了什么问题，你没有高强度的去使用，说也说明白只会引来争论。如果感兴趣就去看看我做的 Saasfly ，解决同样问题付出的代价是什么，有没有更优雅的解决方案，相信你就心里有数了。

不懂就问有哪些公司在使用?不是玩具一个吗?

动不动就大改,骂声一片

Next.js Nuxt.js 等框架深度融合了渲染引擎，辅以各种功能改善 DX 以及渲染引擎的缺陷。熟悉后真正做到了“只关注业务”的目标

作为一个多年前端切图仔，我很共鸣题主一句话：没感觉没有 SSR 就罪恶到要枪毙。nextjs 我也简单搞了几个生产项目了，使用 spa 的生态很多开发环境或者是生产环境或多或少都有些 bug 。我的理解也是带 ssr 的 react, 所以我也一直在期待 react 的 ssr 到底是个怎么样的设计和体验，基于 ssr 的原理考虑，react 是不是破坏性很大。自我感觉基于系统文件目录构建的路由真的难用切难以控制，有不少心智负担，没有自己定义路由那样舒服。最大的感受就是，next.js 项目大了调试是真卡啊，和大点的 vue2 老项目一样真痛苦，最新的 vite 开发 spa 那调试体验那不是嘎嘎香，而且 vite 中文文档也超香啊，真的写的很详细，很多刁钻用法，google 都搜不到，仔细读文档却能够找到。还有就是说全栈体验的，在中国全栈主要看啥，看生态和招人，我承认 nextjs + trpc + prism 搞不好也能快速 crud, 但是中国很少有人这样写啊, demo ？ nestjs 都起不来？其实真正做全栈的，又做的代码可维护性好的、效率又高的，nestjs + react + ts + vite ，比什么 java + vue2 ，python + vue2 来的好吧，我敢说一个 ts 全栈绝对比以上组合写 crud 快，还快不少，因为语言模型一样，npm 包很多也可以复用，没有语言切换负担，当然这也只是早中期全栈体验对比以上只是鄙人一点粗略的认知

就是个 ssr 为了解决 seo 的问题,基于运行时 node 渲染页面而已,仅仅是 view 层的东西,理论上还是前端,与服务端框架没啥关系,服务端框架就是 koa/expressjs/nest 这些,不要搞混了

新时代 PHP

前端娱乐圈，很多东西都是在轮回。

你说的太客气了

Fullstack + 成熟的 ssr 吧。已经取得了广泛的成功，OpenAI ，Anthropic 这些都在用。Vercel 部署也是核心的优势之一。

我怎么又被代表了？如果你觉得我写的 Saasfly 是 demo 欢迎指出哪里有问题。有什么证据能说 nestjs 一定快呢？而且你拿 nestjs 去比 Java 、Python 。难道不是去比较 Spring 、Quarkus 还有 Fastapi ？没有什么绝对的事情，你连业务都不清楚就打包票不觉得有些好笑吗？

主要还是 fullstack ，最低用工成本最大化利用前端开发资源

服务端渲染（ SSR 有助于 SEO ）、静态导出（ SSG 提高性能）、热模块替换（ HMR ）、自动代码拆分（使页面更快）、文件系统路由、API 理由、CSS 模块化、错误处理、高度可定制化、良好的社区和支持生态等等； next.js 开箱即用，用起来不折腾，相当于雇了一个专业团队帮你搞定了这些事情，直接上手堆业务就行。我使用它开源了全栈项目，它解决了我非常多的问题，对我来说是福音； c-shopping 开源地址： github.com/huanghanzhilian/c-shopping 、 github.com/huanghanzhilian/c-shopping-rn 、 github.com/huanghanzhilian/c-shopping-weapp

一夜梦回 asp3.0 php jsp ，挺好用的

跟 PHP 一样方便，又不会像 PHP 那样挨骂

最新版本的 nextjs 可以在服务端组件写 sql 语句，跟 php 一样

都是技术人不要这么这么针对，我整个言论都表达了谦虚的笔法第一：我没有说你写的 Saasfly 是 demo第二：我是看到了很多前端大 V 在 nextjs 上的 trpc 浅尝，所以说大 V 用 nextjs + trpc 写 demo 介绍文比较多，企业生产大家还是用的少第三：我也不是 nextjs 黑，我也用它，单纯谈一点自己视野+使用的感受

next.js 又是什么鬼，前端还学的完吗？

哈哈，学不完了。这个没学完，下个又出来了

＃38 我没有想针对你，可能语气冲了些，先给你道个歉。大 V 他又不写代码，你可以看下 Saasfly ，生产用的少的原因是 next.js14 以及 trpc release 没多久，以及 next.js 喜欢 break changes ，还有就是 web 在国内基本属于废弃的状态。关于文件路由的点其实是想解决起名难的问题，国外现在主流倾向于这么做。SSR 对于 C 端的 SEO 非常重要,所以 React19 一直没有 release 也是这个原因，新的特性基本上就是给 next.js 在做。卡也确实存在的，基本需要顶配的电脑。针对你的几个问题，不知道我回复的能不能解决你的一些疑惑？

＃38 主要是我觉得关于技术这块还是需要严谨些。再次抱歉

好的，下次发言会在严谨一些

您解答的这些疑惑我是知道答案的，可能我的表达能力确实差了一些，还有你可能忽略了我说的背景：国内，其实现在 nodejs 全栈在国外很流行了，国内却。。。，在未来，中国的软件开发者肯定也都是往全栈发展，降本增效是主要原因，还有不说刚 release, 就算我觉得再过 3 年，可能国内还是很难找到企业大面积使用 nextjs 全栈，不知道您理解我表达的意思了吗

没啥，核心思想就是数据绑定。。。更利于前后端分离,火就是国外对界面和代码越简单越好，不和或内一样。然后这东西出来早，占位早。

＃44 我能理解。国内现在大面积使用 jdk8 ,而且很有可能也不会升级。国内为什么不使用 Next.js 的核心原因我再来分享一下。1：边缘计算本身就是为了做 global 市场 2 、SEO 对于国内价值不大 3 、全栈在国内也是外包的代名词。跟时间没有关系，和国情有关。Next.js 的优点在国内就不具备大规模使用的条件。Next.js 天然方便做 SaaS 应用，国内也没有这个需求。希望我们的讨论能给别人带来一点帮助和启发。再次感谢您的回复
你要了解人家的商业模块。这个框架是 vercel 的，他的特点就是配合 vercel 的托管服务，可以快速实现一个网站。开发者只需要会 js 就可以了。同时 ssr 对于初创公司可以方便的获得谷歌的流量。这个框架在硅谷很流行。因为吃了中小公司这一群体。ssr 对于国内和一些大公司内部、app 项目是很好。但是假如只有几个人，那 nextjs 就提供了一套完整的解决方案，而且还 seo 友好。实际上网上 ssr 有大量的场景，spa 用的多只不过多用在 web 开发的增量上。至于你说大规模项目，规模大了，就来新的人重构了。而大部分项目根本规模不可能大

react 是库，nextjs 是框架。nextjs 提供了一整套方案，开箱即用。

用到就看看，这么多年，学废的东西太多了，用不到就先不用管。从把 ie6 常见 bug 作为前端面试基础的时候开始，yui ，extjs 起来，然后 jquery ，再然后一堆 mvvm 框架，包括最爱的 avalonjs ，兼容 ie6+,基本一个没落，甚至好多源码都分析过，结果呢，真正算作知识留在脑子的 10%都不到，ie6 死翘翘了，ietester 没用了。后面伴随着项目前端越来越重，出现了很多工程化的工具，出一个学一个，也都学废了。grunt ，gulp,webpack 我的天啊，新项目一个换一套方案，要是能有个活了 5 年的，维护都要绑死个人。后端做几个月，回来再看前端，熟悉的东西又变了，头发越来越少，没用的产出越来越多。现在是，能解决问题就行，需要什么学什么。不深究的话，尽量别提前学，需要用的时候，不知道淘汰多少年了。额，前段时间把 nextjs nuxtjs nextjs 大概看了下，一言难尽，能不能别互相蹭啊 :( 等 nextnextnext jsjsjsjs 再学了

解决了以前要搭一个 React 的全栈项目稍微有点费劲的问题。比如说有一个叫 T3 还是什么的一个项目就是一套全栈的脚手架，拿了巨多星，主要就是因为一个明星开发者提供了一套开箱可用且全面的全栈模板，算是解决了前端生态稍微有点混乱选择太多配置比较割裂的问题，因为他是明星开发者所以被更多人看到，虽然他的选择有很大的倾向性，但是确实解决了问题。Next.js 就是一套更加完善，整合的更成功的解决方案。虽然它并不是唯一的选择，但是它有一些先发优势，又得到了 vercel 的大力支持从而和 React 团队搭上了线，从而一跃变成了天选之子。另外它也确实做的很不错，在获得了 React 的原生支持之外，提供了一些未必是原创但是很优秀的解决方案，比如通常比较烦人的 SEO 、图片优化等，另外从开发者角度投入了非常大的精力做优化比如文件路由、文件目录层级优化等。不过这玩意比 React 激进太多了，从我自己使用的过程和体验来说，感觉 vercel 还是把它当成一个孵化中的项目，并没有真正的稳定下来。

已读乱回？说的是服务的部署，和静态资源是一个概念吗

目前国内外 80%以上的互联网创业团队 sass 公司 如果技术栈是 react 首选做企业网站(官网/营销) 首选都是 next 1. vercel 背书 本身就是优先为商业场景考虑/优化 背后有商业驱动也不需要担心维护积极性2. SSR/SSG/RSC 本身适合场景都是企业官网/营销场景 一样是这个场景下的刚需3. react 本身就是这个场景下的技术栈首选, SEO, og image 之类的也是营销官网的痛点3. vercel 的一键部署 日志 可以降低小团队的启动门槛 减少在这些方面的投入; next 也提供了非常完善的 standalone 部署支持, 可以一键编译成自部署的输出, 可以直接用于编译到 docker不要拿国内 react 生态的后台应用或者玩具静态页去考虑 next, next 更多考虑的还是商业需求. 如果你觉得不合理, 说明你不是目标客户 不需要硬套一定要用用完又来喷

＃51 ？已读乱回？免费可以部署的服务多了去了，你找一个仅支持部署 next.js 的不支持其他框架的服务出来？

从 next 的功能趋势看 各方面他们考虑的其实都是商业场景的使用 sass/电商/企业官网(营销)

SPA 会所

基于文件夹的路由还挺好用，不用新学什么东西，不过最新版本好像改的更复杂了。。。

寻一个 nextjs 新手，一起学。每天督促你学习

有的人说 next.js 好用是因为 SSR 完整解决方案有的人说 next.js 好用是因为 Vercel没有人说 next.js 好用是因为其中一块功能比别的选择更好。6+6+6=21 ，9+3+0=12 ，综合得分高，所以好用。

＃58 6+6+6=18 ，写成 21 是想说 7+7+7😅

解决了前端太容易写也太容易乱的问题？

很好的主题，作为一个后端程序员，同样好奇

因为我本身不是搞前端的所以 这个前端框架和你有啥关系

解决了在新时代时期，如何使用 JavaScript 取代落后的 PHP 问题（直接用 Node.js 写页面过于底层直接用前端渲染，失去了后端渲染的各种特性（基本上就是基于各种条件，提前决定页面的内容，页面加载，鉴权 / 方便 SEO ）

没感觉有啥优势，我感觉也就 swr 好用点。

＃53 哈哈，你一开始说的是服务还是静态资源？真能杠啊 block 了

前段时间跟着官方的互动教程做了下项目，概念是真的多，现在已经忘光了

解决的都是些已经被解决的老问题，也没见解决的更好，同时也解决了一些无关痛痒的新问题，也未必有解决的必要。但却引入了一些恶心人的新问题，画蛇添足。只能说，前端就是这样，瞎 jb 折腾。

因为他爹是 Vercel

ssr 挺好用的，页面直出+路由组件化等等都一次性给你弄好了，不需要再自己造轮子或者陪这陪那

可以一把梭了 要取代世界第一语言了

我觉得，它的出现肯定是为了解决一些人的痛点。而如果还流行起来了，那说明好多人和他的痛点相同。

it doesnt slove any problem that havent sloved.it just give an another option (maybe better).

ssr 对我来说挺好用啊,整体将 react 的组件树扁平化服务器渲染的内容可以在 react.js 下载之前就显示出来,server action 可以在 js 加载之前就能向服务器提交操作服务端组件和客户端组件的搭配,可以让服务器只将必要的序列化的数据传给客户端组件,昂贵的计算逻辑也可以交给客户端组件来做我觉得 nextjs+react 提供了一个清晰明了的网络边界,这是我最喜欢的部分它指示了什么内容应该在服务器上渲染,什么内容应该在客户端上渲染,和 spa 的目标是不一样的nextjs 更适合被称为同构渲染框架而不是 ssr,它是包括 csr+ssr 的我觉得是一种合理的进化当然这些概念十几年前就有了,如何将它和现代前端框架融合才是工作的重点.技术是螺旋上升的,如果从俯视的角度来看,确实是个圈,但不能否认这个圈越来越大了

服务端渲染客户端渲染客户端服务端混合渲染前端基本也就这几种基础模式了，剩下就是在框架和生态上不断演进。

我也来说一点：开发一个小项目不用启动两个工程了，在一个工程里同时写 react 和 nodejs ，非常适合全栈开发。

可以不用。等 18 个月，你发现也就不用学了。 又换了一茬。

我感觉其一是展现他们自己对框架的熟练使用程度来证明价值，第二就是偷懒，如下图对比
ssr 和全栈开发挺方便吧，不过没需求确实可以不用，还有是因为个人开发写的一些小项目能部署到 vercel 或其他托管平台上，不用额外找个地方部署后端。

全栈吧，作为一个前端，可以直接写后端，又没有学习额外语言的成本。

遇事不决 "use client"

可以在 Vercel 免费部署

Vercel 服务器成本低 再加上都是 js 前端 无痛转全栈

DX 好

一起？我没学过 react.

Nextjs 爆火也就是最近一两年的事情抛开功能原因，我觉得能火的关键要素是，Vercel 摘了 Meta 的桃子。这几年正值 Meta 降本增效，react team 在 Meta 内越来越边缘化。Vercel 趁机挖了很多 react team 的人，废了 create-react-app ，重构了 react 官网并借此把 Nextjs 放在头号位置（导致现在新人入门 React 几乎必须从 Nextjs 开始），并几乎控制了 react 未来方向。React 18 稳定版停更一年多，而 React 19 新功能明眼人都看出来是给 Nextjs 量身定做的。就像楼主说的，“倒也没感觉没有 SSR 就罪恶到要枪毙”，React 痛点那么多，react team 偏偏把主要精力放在了 SSR 。到头来 React 19 真正的亮点 - React Compiler ，还得是出自 Meta 团队。

＃46 要不你们结拜吧

我也不明白，nodejs 刚出的时候我就看过一眼，当时就觉得不行，直到现在偶尔工作需要跨界研究一些音视频相关 nodejs 项目还是各种难受，一点也不想用，但真的避不开，太火了，

＃23 国外很多公司都在用啊，chatgpt 的前端就是 nextjs 写的

React 19 的新点是 Server Component ， 和 SSR 没有半毛钱关系的

我这种古董老站长，连 Git 都不熟练，只会老古董的 lmap

挨骂是什么意思？我记得 17 年左右很多 PHPer 的

＃84 怎么加你

难道就不能用 nuxtjs 吗

＃86 甜起来了

天下之势，分久必合，合久必分，jsp,php -> html,jquery -> react,vue -> typescript,next js

可以带入独立开发者的视角去看，想快速全栈做一个 Web 应用，尽早推向市场，Nextjs 可能是最好的选择了

梦回 jsp

一 ssr 搜索引擎收录，二静态页面导出，避免直接写 html

这些相对于开发都不是什么事情