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

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

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

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

第一种是实现MVVM模式，即前后分离，前端不需要掌握后台的框架或者后台方式去实现对页面渲染，好处可以让后端代码完全分离开页面中，便于维护。而且后台的api接口可以用与更多平台，不需要二次开发。坏处，假如页面是主页，那样需要大量api去获取数据，渲染。但MVC架构的就方便很多
第二种实现Mvc,后台负责套逻辑，前端负责渲染页面，但前端必须对MVC后台开发中模板有所了解，个人认为这样其实方便了后台，苦逼了前端的方式。
第三就解释。
其实还有一种是前端兼后台的工作，当然这是适用项目不大的方面。如NODE.JS
其实主要看你公司前后端搭配和项目来决定。例如像我们这边后台多得一B，前端少得一B的公司，可能会用MVC架构，前端渲染由后台去处理。当然，你前端人多，肯定是MVVM模式比较适合。当然这只是表面问题

这个看起来只是人的问题啊,我觉得是没什么问题的

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

给个静态，让他们自己玩ajax

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

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

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

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

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

第一种的话对前端要求比较多一些，通过API接口之间的对接来渲染页面数据，后端只需要提供接口就可以。这样分工比较明确，每个岗位只需要做自己擅长的方向就可以；

第二种的话对后端要求多一些，前端只需要提供静态模板页，后端通过模板框架来渲染数据，必要的一些效果还需要写一些ajax和Js来实现。出现问题后还得需要前端跟后端联合调试。

我是做后端php的，个人感觉 如果公司前端开发经验多使用过anglajs ，ajax等框架即可使用第一种方式，前后端分离。反之 使用第二种，前端只需要做静态页面，由后端来进行渲染处理数据