下午经过一场激烈的关于前端页面呈现问题的头脑风暴，：
经过讨论之后初步确定应该是两种方式：
第一种为，页面模板由后端返回，并由浏览器进行缓存。页面需要的业务数据，则通过服务调用的从后端获取。当数据获取之后，在前端页面通过JS的方式，将数据渲染。
第二种为，浏览器呈现的页面是有后端实现模板和数据的整合，并生成页面的HTML字符串，并把该字符串从后端返回给浏览器。页面的JS文件则主要完成前端的交互。
其实这两种方案，现有的技术都有使用，但是他们还是有一定的区别，此时我能想到的区别有：
1）第一种方案，可以有效的利用浏览器缓存实现网络传输流量的节省。比如通过另外的站点或ＣＤＮ实现网站前端页面模板的传输，并且一次传输，可多次使用。现有的前端ＭＶＣ框架主要是这种趋势。这种方案可有效的降低服务器对服务脚本的编译与执行，以及服务脚本转化为ＨＴＭＬ的字符串拼接过程。能够有效的提高服务器的响应效率。但是这种策略有一个问题：需要前端的ＪＳ去做业务数据在页面展示的逻辑判断，增加前端ＪＳ的复杂度。但是随着Web应用的发展，这种方式也逐渐的成为趋势。这种策略的用户体验也在一定程度上依赖用户机器的性能。
2）第二种方案，可以在服务端对数据与呈现的页面做一个有效的合并，并依据业务数据做出页面展现的逻辑。这种策略可以有效的利用服务器的高性能，快速的完成页面HTML代码的生成。这种方案把页面呈现的逻辑留在了后端，使得处于浏览器中的页面的JS交互逻辑变的更加简单。现有的基于JSP，ASP,PHP等的网站开发方式，都是基于这种策略。这种策略可以有效地降低由于用户机器的性能差异带来的体验差异。但是这种策略，把页面的呈现逻辑留在了服务器端，加重了服务器端资源的消耗。随着用户机器性能的提升，以及前端JS应用框架的大量涌现，我感觉有可能被第一种方案替换。
这是我对这两种策略的一个分析对比，由于是最近开始接触前端，可能理解的会有偏差。