最近到了一家公司，團隊處於發展階段。當前公司的開發模式是先由前端根據原型圖與設計圖做出前端頁面，由技術經理制定的規則是前端按照後端需要將頁面分為 head、body、menu 和 foot 四部分，然後單獨分配一個控制器給他們測試頁面。前端頁面測試完成後再交給我們後端開發頁面。
前端只負責製作頁面，許多互動效果，比如 Ajax，提交動作等都是由後端來完成，還有一些諸如彈窗的效果都是先由前端獨立寫出一段彈層代碼再由後端整合進模板裡，往往模板裡寫了數百行的JS代碼，這讓我感覺網站代碼十分混亂。
其次，因為前端的頁面和我們後端的模板是分開的，當前端需要做出一些改動的時候他們是先在他們的頁面中先修改，然後再告訴我們該修改的部分，如果小改動還好，改動大的時候就十分混亂了，而且模板裡還有大量由我們後端添加的 JS 代碼，修改起來往往產生很多衝突。而且因為前端和後端通常是同步進行開發，但因為後端的模板與前端的頁面之間的脫節，往往也造成了一些小麻煩。
起初我認為，模板應該完全交給前端來編寫，他們只要編寫簡單的範本語言以及按照我們後端提供的結構寫 Ajax 互動，那麼可以讓互動的工作完全由前端掌控而不至於太過於混亂，但是前端經理卻不這麼想，他認為應該讓前端與後端徹底分離，前端單純只做出頁面即可，甚至希望拋棄當前的做法讓前端僅僅做出一個純靜態 HTML 而不需要根據後端規則對頁面進行切割，不過當時這個提議因為會加重後端工作量和開發時間而沒被採納。
想聽聽大家意見，前端應該寫模板嗎？
回複內容：
以大部分前端業內人士（包括我）的看法，模板（準確的說是表現層）應主要由前端負責，這意味著，不僅html/css是由前端做，js、ajax也應由前端來做。雖然仍然有不少公司中，有單獨的頁面重構（只做html/css），但總體上這種方式遭到了越來越多前端從業者的質疑和否定。
當然小豬算是一個例外。 :)前端與後端徹底分離, 難道不是指後端只給出介面和資料麼...
我們的做法,
後端開發只與前端開發協商介面及資料格式並給出資料, 前端開發寫後端模板或者前端模板, 並完成所有ajax請求, 使用者互動.
製作一個純靜態html頁面,私以為不叫前端.趕緊跳槽吧。
你們公司沒前端，只有切圖的和程式員。
你被當作切圖的。
另外有興趣來阿里的話，可以私信發簡曆。亂點來到這裡。
我覺得，如果你們的前端經理的觀念是前端只負責靜態demo輸出，認為前端開發就只是html+css+少量js，那麼，我認為你應該想辦法把這個經理幹掉，或撤退換一個項目。
我的觀點，在任何一個對使用者體驗有追求的互連網項目中，前端團隊都必須接管所有展示層的業務，包括用戶端渲染的模板和服務端的view層，因為只有前端來接管著這些業務，才能更好地把web效能最佳化做到極致。
只要是前端的東西，後端不要過界，也就是說js的所有邏輯，後端不應該參與。誰過界，把他的手剁了，扔回去。
當然，純粹的靜態demo也是可以模組化的，前些天回複了個話題，你可以參考。但我不太想去寫那個使用文檔。沒為什麼，覺得太簡單了，自己參悟吧。
grunt的怎麼進行靜態資源定位配置？ - 前端工程師團隊實力太差就這樣吧，典型學生時代開發感。。。。
團隊缺前端攻城獅，有的只是切圖的。趕快給jieyou投簡曆去體驗純粹的後端感覺題主的問題不涉及前後端分離，只是一種工序。
他們的專案經理的要求是 前端寫出 html檔案，然後後台 copy & paste 靜態部分到他們的代碼裡，然後把動態替換成 動態代碼。動態那些標識還是 後台寫的。甚至檔案都是兩份，一份靜態，一份動態。
這不是前後端分離，只是psd切圖後產生範例html 交給後端工程師去寫頁面罷了。
真正的MVC模板 是應當內嵌 背景模板代碼，就是項目的一部分才對。
比如 到本文的地方 就是 {{CONTENT}} 標題就是 {{TITLE}} 這種。或者像 @小豬 他們項目裡頭一樣 使用一些 位置標記，運行時綁定資料。前端和後端維護的是同一個檔案。
而真正的前後端分離是，後端只提供介面，不涉及 html的渲染的。比如使用angular js 就是其中一種典型應用。
如果說前段開發 懂一些 指令碼的概念，是可以做到改動不需要過多的後台參與的，提高開發效率的。但不是解放前端生產力，而是減少後端的工作量 :P來來來，告訴你們的前端經理，我完全認同他的觀點，前端就應該唯寫HTML就行了，但是，但是，但是，這需要合適的技術來支援，市面上你們能看到的技術架構，都不是為前端設計的，都是該死的後端工程師為了他們一己之便利寫出來忽悠前端的。
所以，我們打著解放前端生產力的旗號就竄出來了，是的，用竄的，不服的來跟我一起竄，1，2，3。。。
前端開發 與後台開發 如何協作？ - 小豬的回答
如何評價Knot.js? - 小豬的回答
順便摘抄一段我在上邊那個回答下面回複的評論
小豬（作者） 回複 賀師俊
你猜測我們的設計是外包的，這是錯誤的，我們的設計是獨立的團隊不假，但是它是我們內部的團隊，只所以讓他們獨立， 是因為我們認為engineer和designer是有區別的，一個好的engineer，幾乎不可能同時是一個好的designer，反之亦然，所以，不能夠也不應該讓他們混合工作。
======純吐槽=======
很多公司，包括facebook，試圖用全棧工程師來解決模板與資料邏輯的關聯工作，讓工程師來完成頁面部分的工作，我不得不說，當我們的設計師mm在觀摩山水，悲秋傷月的培養美學靈感的時候，我們正在寢室裡面揮汗如雨的打遊戲好不好，怎麼能指望我們這些摳腳大漢寫出一個讓人覺得漂亮的頁面來。。。
==================
所以，我們是特意構建了這樣的團隊結構，然後開始尋找技術解決方案，當然，從這個意義上講，你說的團隊架構反過來影響技術架構也是沒錯的。
賀師俊 回複 小豬（作者）
所以你雖然不是外包團隊，但是按你說的獨立團隊的情況，跟外包的做法也差不多了。其實我個人對這種配置是非常質疑的，因為我看過很多這樣配置得到糟糕結果的例子（不管是外包還是准外包性質的內部獨立團隊），不過沒看到你們實際的工作情況我也沒資格做評價就是。
豬（作者） 回複 賀師俊嗯，你看到的糟糕的情況是理所當然的，除了我們手上的這兩個架構，沒有其他任何架構能夠適合這種團隊結構，不然我們為啥自己做架構。至於說我們成不成功，我自我評價是amazing。 現有的技術棧都是engineer導向的，強行剝離設計部分一定是撕破皮流血的結果。但換個角度說，你能夠看到很多失敗的案例，就說明這種結構是有需求的，所以大家才會去嘗試，我想，我們算是走對了路的一小撮。進一步的，由於現有的engnieer導向的技術棧無法良好的支援剝離設計，所以有經驗的技術主管都會避開這種團隊結構，從這一點說，分離設計的現實需求應該比我們看到的僅僅是失敗的案例要多得多。
看著都複雜，我司只有切圖的 和 其他的職位是JAVA初級軟體開發工程師，做的就是JavaWeb工作，
編寫好各種代碼，提供Controller。
然後又要跑去做頁面的AJAX擷取資料，事件綁定，等等操作。
ui團隊只提供一個靜態頁面，還有一些簡單的操作事件(全選，單選，彈框)，最終還是讓後端的人去弄各種的JavaScript...
幹了一年了，寫JS比Java多，而發展是往後端去的，你們還有設計師怕啥，我們直接照著原型圖寫頁面，然後給開發，最後全部工序完了，然後才是定頁面風格，排版，神馬的，傷筋動骨一周，上線
