个人认为不是一个简单的对错问题
在项目的不同阶段、不同规模、不同成本的条件下各有优劣

强烈认同的你说法

以前是对的，资本大发展，现在要省钱呀

看项目呀，如果不分青红皂白，直接微服务、云原生、BFF、前后端分离搞起来，那肯定不对，因为没有银弹，没有需求硬去追求新技术会导致项目失控的。

但如果说你真的，重前端、客户端，甚至要做多平台，API 复用，那分离开确实是必要的。

这不是能促进就业？

我老早就看过一个回答 这不是一个技术问题 这是个工程问题

就小规模来说，前后端分离可能还算好，但微服务化就显得很没必要了

求助，发不了贴，所以来求助大佬 是这样的，我开网店直播带货的，主要做台湾生意，但是找不到靠谱的网络，网络都不怎么好。 所以想在香港哥哥家自己做个服务器自用，这想法可行吗？网络会不会更好？主要是都找不到教程，不知道属于什么技术、要什么条件？ 希望大佬能指导一下，电脑配置、额外硬件、软件、教程什么的？

跟规模其实没关系，得看业务的具体需求，前端交互复杂的产品肯定得分离的。

我搞了多年的前端开发，现在用 Ruby on rails, 其实挺反感前后端分离的，要与后端沟通，增加时间和效率成本。但是分不分离，还是要看公司各方面，比如人力成本，业务需求，比如要多平台开发复用 api 调用还得分离，开发手机端的小程序，app 等， PC 端从技术上看我是觉得： 1：现在前端有成熟的 UI 库，直接拿来搞很复杂的页面交互，比如 antd 开发复杂的后端管理系统，用 ROR 能实现感觉要写好多的 UI 业务组件、CSS 这些。虽然 现在 hotwire 也日益好用，纯样式组件用 tailwind，但是总感觉还是要写好多东西。 2：前端状态管理以及组件复用像 react，vue 这些框架，在客户端维护状态，您要浪费了多少时间来担心模型验证、陈旧数据和 DOM 准备情况，生命周期的理解，异步请求和数据渲染的问题搞得头都大。

如果是纯 Web 项目，非常确定以后不会有接口调用的需求（小程序、App 等），那就不用分离了。否则还是得再维护一套接口，不如一开始就分离了。

现在还有几个纯 Web 项目，会有纯小程序，纯 App 项目，纯 Web，恐怕是没有了。所以有什么好考虑前后端分离的事情？

纯 Web 项目，流量都没有，死绝了。

其实小程序，app（安卓/ios）这样的接口也应该分离，合在一起真心没啥好处，好多优化都不能做。也不灵活。

多写点代码真的无所谓，但是改了一个小程序的接口，导致 app 挂了乐子却很大。

前后端不分离你多个客户端怎么办？更精细的分工肯定是发展的趋势

纯 web 已经没前途了，虽然现在其它方向没什么前景

确实，看大厂的 web 端，都万年不更新了。 单纯靠 web 端吃饭，估计饿死了。

都 NLUI 了，前后端分离是啥

我也是情愿多写点代码

解耦的开发挺好的。单纯后端，各模块还要解耦呢。那前后端解耦也挺好。工作量方面，虽然分开后总体工作量高一些。但是未必人力要多很多。也依然可以全栈，一个人负责全部。另外从招聘角度，招聘个优秀的全栈，不如单独招聘容易。

这问题就像单体和微服务一样，本身都是基于一定的需求出现的

国外前端 js 后端也是 js，所以合起来不分离更好

我现在手里的几个项目都是前后端 JS，都是人员不分离，技术上分离。