前后端分离的意思是：前后端分离并非仅仅只是一种开发模式，而是一种架构模式。
前后端分离已成为互联网项目开发的业界标准使用方式，通过【nginx+tomcat】的方式，也可以中间加一个nodejs，有效的进行解耦。
SSR优势
1、更好的SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。
2、更快的内容到达时间(time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。无需等待所有的JavaScript都完成下载并执行，才显示服务器渲染的标记，所以用户将会更快速地看到完整渲染的页面。
通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content)与转化率直接相关」的应用程序而言，服务器端渲染(SSR)至关重要。
PHP没有前后端分离的概念吗有啊前端通过vue或者angular之类的框架或者直接使用ajax请求php后端接口获取数据通过js来渲染使得前端页面不存在后端语言php只做数据接口不加载任何模板不传任何参数到模板这就是前后端分离
分布式开发，和前后端分离是一个意思吗？举个例子，系统a中有业务层和dao层，系统b中有前端页面和控制层首先简单说一下：
前后端分离就是前端页面只有前端代码，
后端只负责出接口和数据库。前后端分离的好处就是维护方便，代码清晰，
例如，现在有一个官方网站，那么前端要写的就是一个管理后台和前端页面，
后端php（这里只是举例，其他语言的也是一样），需要做的是通过php写出数据接口，
然后前端只需要通过接口来发送和返回数据。然后上线的时候前端只需要把前端代码打包上传到服务器就可以了，混合开发像java和jsp，它们是前端代码和后端代码一起写的，需要把代码一起打包上传到服务器
php怎么进行前后端分离
可以考虑使用基于MVC的框架,比方说codeigniter,cakephp或者zend等.
后端的东西都放在C(Controller控制器)和M(Model模型)里,而前端则放在V(View视图)里面
php是前后端分离吗php本身就是服务器端脚本语言
但apache会把PHP语言解析成浏览器可以解析的语言
浏览器也可以解析html
所以php里面可同时包含php语言和html两种
因此分布分离都可以
但最好是分开写
怎么理解前后端分离对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。
这个说法是不合适的，打个比方，别人问的是逗如何解决家禽把蛋生在水草边的问题看地，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答逗不让去水边就行了地，这显然不在点子上。
这
两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了
少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。
那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：
-性能优化（尤其是外部资源的管理与发布，请求合并等等）
-协作的顺畅性（已形成模板的界面片段的返工等问题）
那么，模板到底应该在什么地方跟数据结合看
这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。
所
以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就
是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。
所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。
至
于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node
做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。
这时候回头看你问题中的这句：
前后端分离的意思是，前后端只通过JSON来交流，组件化、工程化不需要依赖后端去实现。
我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到服务器端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。
组
件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗看是数据吗看是数据和模板的结合体吗看没法回答。在此，我说一
句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不
带逻辑的界面模板。
最近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问
题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改
变，用这个方案去解决的话，有些牛刀杀鸡的感觉。
关于B类项目的组件化，我之前那个没写完的系列是关于它的，但经过最近一年多的思考，我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我，这就写。