最近到了一家公司，团队处于发展阶段。当前公司的开发模式是先由前端根据原型图与设计图做出前端页面，由技术经理制定的规则是前端按照后端需要将页面分为 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多，而发展是往后端去的，
你们还有设计师怕啥，我们直接照着原型图写页面，然后给开发，最后全部工序完了，然后才是定页面风格，排版，神马的，伤筋动骨一周，上线
