前端负责页面，后端负责接口，双方按照接口文档进行开发，后端专注于处理数据，前端负责视图渲染

第一種是實現MVVM模式，即前後分離，前端不需要掌握後台的框架或者後台方式去實現對頁面渲染，好處可以讓後端代碼完全分離開頁面中，便於維護。而且後台的api接口可以用與更多平台，不需要二次開發。壞處，假如頁面是主頁，那樣需要大量api去獲取數據，渲染。但MVC架構的就方便很多
第二種實現Mvc,後台負責套邏輯，前端負責渲染頁面，但前端必須對MVC後台開發中模板有所了解，個人認為這樣其實方便了後台，苦逼了前端的方式。
第三就解釋。
其實還有一種是前端兼後台的工作，當然這是適用項目不大的方面。如NODE.JS
其實主要看你公司前後端搭配和項目來決定。例如像我們這邊後台多得一B，前端少得一B的公司，可能會用MVC架構，前端渲染由後台去處理。當然，你前端人多，肯定是MVVM模式比較適合。當然這只是表面問題

跟楼主一个样，混合开发，虽然问题很多，但是没办法，后段不做，你也不能打人家一顿。
前后端分离的方式很多。最理想的当然是前后端纯接口对接，这样就不会混在一起了。
但是现实不是，比如公司现有后端，再有前端，那你只能在后端代码里调页面。
我们的解决方式是让后端不在动页面。
好处是
1.页面专有前端控制
2.前后端职责分清
坏处是
1.需要学习后端模版
2.调试不方便
3.前端很多脚手架不能用

国内太多公司都不专业，没办法，大环境是这，只能尽力去做吧

让前端学习一个模板引擎又不难，交给前端做，在说前端做的页面他自己套非常快

我觉得要么不分离，前端只设计静态页面，后端负责来套；
或者前后完全分离，后端写api，前段用jquery ajax或者react、vue来调用这些api，页面完全由前段来写。

完全分离的情况，后端必须写规范的接口，每个接口要给出清晰的文档（正常流返回的数据实例以及异常流的数据实例都要！主要是返回值的层级结构和变量的命名，便于前段开发来使用这些数据），接口有变动的时候，必须及时更新文档，最好通知下前端开发人员。如果不这样做，前后合作会乱成一锅粥！！

总的来讲，无非就是说，这个渲染数据到底是谁该做的，谁来协调。
就安卓和ios的人员来讲来讲，他们所有的活除了接口不用写，其它的都可以全程参与。
那web前端开发人员呢，如果他们不懂得后端语言，调用接口，把数据渲染在动态网站上，明显不太现实。所以一般来讲，web前端人员做好页面之后，还需要有一个会后端的人调用接口，将数据铺到前端人员开发的模板上。

后台给出接口文档，前端在写静态页面时，可以根据接口文档自己mock一些假数据，最后等到接口写完取消mock操作

真正前后端肯定是js拿接口数据然后遍历，页面改的话肯定也是前端的事

我们公司就比较简单直接，采用的是你的第二种方案。
采用的是php框架，前端只要把页面写好，然后后端逻辑处理好。套页面什么的，需要用到框架语法或者php语法的，就给后端人员去输出渲染页面(有的js也是后端写的，前端只需要把静态页面写好就可以)。

前端的页面写的没问题，后端套页面一般也挺快。如果后端人员在渲染视图数据的时候，发现样式有问题，就提交到问题系统(对，我们有个问题系统的项目，限于内部使用，用于前后端人员提交bug)上，然后所有的前后端开发者，每天会查看问题系统上是否有自己的问题，再进行解决。

其实只要把规则定好，一切顺着规则走，前后端的配合也会显得方便、明了。

你说的这两种我们公司都有在用。关于第一种，不知道你的公司有没有把前端的页面从java或php项目里面拉出来还是依旧嵌套在里面？如果嵌套在java或php项目里面话，你那个让前端套后端的模板引擎的话，是不麻烦的，我们的公司的后台项目都是嵌套在java项目不单独迁出来的，我经常用前端套后端的模板引擎的写法，没毛病。至于第二种，联调成本比较高，我个人觉得其实并不高的，不知道你是在什么情况下联调比较麻烦。