1. Es gibt zwei Haupttypen der Front-End- und Back-End-Zusammenarbeit. Die eine ist die Back-End-Schreibschnittstelle. Das Front-End verwendet artTemplate oder vue.js zum Rendern von Daten
2. Das andere ist, dass das Projekt eine Back-End-Template-Engine wie PHPs Smarty oder Javas Freemarker verwendet. Wenn das Front-End und das Back-End getrennt sind, ist das Back-End für das Schreiben von Dokumenten verantwortlich und Ausführen von Funktionen, und das Front-End muss die Verwendung der Back-End-Vorlagen-Engine erlernen und Änderungen in der dynamischen Umgebung vornehmen.
3. Hauptsächlich für den zweiten Typ In der Vergangenheit war das Backend immer für die Konfiguration der Seiten verantwortlich. Daher gab es immer noch Probleme mit dem Frontend Änderungen an den eingestellten Seiten vorzunehmen und das Frontend und Backend zu verbinden, ist relativ hoch
4 Wird es aufwändiger sein, die Frontend- und Backend-Template-Engine jetzt zu integrieren? Fragen Sie, wie die Front-End- und Back-End-Zusammenarbeit in Ihrem Unternehmen aussieht? Oder eine bessere Möglichkeit zur Zusammenarbeit
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
我们公司就比较简单直接，采用的是你的第二种方案。
采用的是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等框架即可使用第一种方式，前后端分离。反之 使用第二种，前端只需要做静态页面，由后端来进行渲染处理数据