现在又开始流行前后端不分离？

不涉及数据库操作的都是前端

SSR 了解一下？前后端是否分离本来就不应该严格区分，都有各自适用的场合。

思考一下，为什么大部分网页前端开发者，都是开发后台管理界面的？

流行就是复古

SSR 也是强造名词罢了

比较蛋疼的现实，为了取个数，前端写 rest 接口，后端 java 分三层，controller ，service ，dao 里都要写代码。
然后就是在这基本上的一些简化，如部分简单的逻辑在 controller 里直接调用 dao ，就少写 service 层的代码。
比如 dao 直接用框架封装生成，不用手写代码等

前后分离, 是为了降低服务器压力、划清前后端代码管理界限、充分利用设备浏览器过剩的性能、以及提高非首屏页面加载速度.
而从三大框架的 ssr 方案, 主要还是为了提供 SEO 方案, 以及偏中台的‘后台服务’,
个人觉得, 如果不需要 SEO, 可以说完全分离是比较好的方案, 无论从开发还是用户浏览体验上来说都会更好.

@ciming 逻辑都写在客户端上，给人家逆向了就完犊子了

@wu67 降低压力肯定不是。不管分不分离，前端总得部署，总要吃服务器资源

不分离现在主要适用于纯前端开发人员需要搞一些少量的后端的工作，以前还要学后端的很多知识，搭建一个后端的框架。

现在很多的新的 SSR 框架，比如 remix.run solid-start sveltekit qwik-city 等等，前端人员可以一把撸一个站，前后端代码写在一起统一逻辑，代码复用达到了顶峰，它们各自的 build 系统会自动区分前后端代码分割打包。

还是多了解下技术的螺旋发展和相对进步，而不是提起 SSR 就想到了 PHP 一把撸。不是一回事。

当年前后端分类主要是应对多端的发展，比如 WEB, APP, H5 ，小程序，你不分离出一套统一的 API 服务出来，难道每个端都用模块引入一个超级大的后端然后修补前端么。

低代码：利好 toB
ASP.NET：落后技术

不是回去，是螺旋上升

后台管理系统类简单的增删改查适合给前端来做，加快开发速度，避免扯皮。

其实不一样的，表面像过去，事实也是差很大的，主要还是靠前端技术来做的页面呈现，只是客户端转到服务端呈现了， 但不是又甩给后端程序员做

不是最近才火的, 两三年前 nextjs 就很火了, 只是你没关注

这叫 “大前端”

跟火不火都没关系，从来没有说一定要分离或者不分离。

分离不分离都各有优劣，比如分离 seo 不友好，所以在很早 next 之类的框架就有了。。。

代码框架只是工具，既然是工具就是为业务和需求服务的，怎么合适怎么来。

后端管前后--->后端管后，前端管前--->前端管前后

看起来是不分离，面向用户是不一样的。

有关前后端混合渲染的一系列概念，实践和标准本来应该是由 php 完成的，但是 php 这么多年以来一直在摸鱼什么都没干出来。那自然被活跃的 js 社区抢了

php 要凉

Blazor: C Sharp+Razor ，数据绑定, 底层用到 webassembly ，面向 web 端 /桌面端 。这种？？