1.前後端協作主要一般分兩種，一種就是後端寫接口，前端用artTemplate或vue.js負責渲染數據，前後端分離；
2.另外一種就是專案採用的是後端的模板引擎，譬如php的smarty或java的freemarker，如果這種做前後端分離的話後端負責寫文檔和做功能，前端就需要學習後端模板引擎的用法，以及在動態環境上做修改。
3.主要是針對第二種，之前一直都是後端負責套頁面，就會出現不時前端給過來的頁面老有問題，結果還是需要前端在套好的頁面上改，前後端聯調成本比較高
4.現在讓前端套後端的模板引擎會不會比較麻煩，想問一下你們公司的前後端協作是怎樣的？或是比較好的協作方式
我們公司就比較簡單直接，採用的是你的第二種方案。
採用的是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等框架即可使用第一種方式，前後端分離。反之 使用第二種，前端只需要做靜態頁面，由後端來進行渲染處理資料