前言在做前后端分离的时候，首先要关心的就是渲染，渲染是View层面的工作。在传统的开发模式中，浏览器端和服务端是由两个不同的前后端团队开发的，而模板则处于两者之间的模糊地带。因此，模板上的逻辑总是越来越复杂，最终难以维护。而我们选择了NodeJS作为前后端中间层。尝试使用NodeJS来梳理View层面的工作。让前后端的分工更加明确，让项目更容易维护，获得更好的用户体验。这篇文章中渲染的工作在前端开发者的日常工作中占了非常大的比重，也是最容易和后端开发纠缠不清的地方。回顾这几年前端技术的发展，View层面的工作发生了很多变化，比如：Form提交全页面刷新=>AJAX局部刷新Server端持续渲染+MVC=>Client端渲染+MVC传统页面变化跳转=>单页应用可以观察到，近几年大家倾向于将渲染从服务器端转移到浏览器端。服务器端专注于服务，提供数据接口。浏览器端渲染的好处我们都知道浏览器端渲染的好处，比如摆脱了Java模板引擎中业务逻辑和表现逻辑的耦合和混淆。对于多终端应用，接口更容易。在浏览器端匹配不同的模板，呈现不同的应用。页面渲染不仅仅是html。前端渲染可以更方便的以组件化的形式（html+js+css）提供功能，使得前端组件不需要依赖服务端生成的html结构。摆脱对后端开发和发布过程的依赖。方便联调。浏览器端渲染带来的劣势但是在享受好处的同时，我们也面临着浏览器端渲染的劣势，比如：模板分离在不同的库中。有些模板放在服务器端（JAVA），有些则放在浏览器端（JS）。前后端模板语言不兼容。需要等待浏览器端加载完所有模板和组件后再渲染，不能立即查看。***进入时会出现白屏等待渲染时间，不利于用户体验。开发单页应用时，前端Route与服务端Route不匹配，处理起来比较麻烦。重要内容集中在前端，不利于SEO反思。末尾的职责划分对于浏览器渲染来说是没有必要的。只是因为在传统的开发模式下，浏览器是离开服务器之后才来的，所以前端的工作内容只能局限在浏览器端。所以很多人认为后端=服务器端，前端=浏览器端，就像下图一样。在淘宝UED目前的Midway项目中，通过在JAVA-Browser之间搭建一个NodeJS中间层，试图根据工作职责区分前后端分界线，并根据硬件环境（服务器&浏览器）进行区分.因此，我们有机会共享模板和路由，这也是前后端分工中最理想的状态。淘宝中途岛中途岛在中途岛项目中，我们把前后端的界限从浏览器端搬到了服务器端。有了一个前端容易控制并与浏览器共享的Nodejs层，就可以更清晰的完成前后端分离。也可以让前端开发针对不同的情况决定最合适的方案。并非所有事情都在浏览器端处理。中途的职责分工并不是前端想抢后端饭碗的项目，目的是清理模板的模糊区域，获得更清晰的职责分工。后端（JAVA），关注服务层数据格式、数据稳定性，前端业务逻辑，关注UI层控制逻辑、渲染逻辑交互、用户体验，不再拘泥于服务器或浏览器的区别。模板共享在传统的开发模式中，浏览器端和服务端是由两个不同的前后端团队开发的，而模板则处于两者之间的模糊地带。因此，模板上的逻辑总是越来越复杂，最终难以维护。有了NodeJS，后端同学可以专注于JAVA层的业务逻辑和数据的开发。前端同学侧重于控制逻辑和渲染的开发。并选择这些模板是在服务器端（NodeJS）还是在浏览器端呈现。使用相同的模板语言XTemplate，相同的渲染引擎JavaScript，在不同的渲染环境（Server-side、PCBrowser、MobileBrowser、WebView等）下渲染出相同的结果。路由共享也是可以的，因为有NodeJS层，可以更详细的控制路由。如果需要在前端做浏览器端路由，可以同时配置服务端路由，这样无论是在浏览器端换页还是在服务端换页，都能得到一致的渲染效果。它还会处理SEO问题。模板共享的实践通常我们在浏览器端渲染一个模板，其过程无非是在浏览器端加载模板引擎（xtmpleate、juicer、handlerbar等）。在浏览器端加载模板文件，方法可以使用打印在页面上使用模块加载工具加载模板文件（KISSY、requireJS等）)别人获取数据，使用模板引擎生成html插入html到指定位置。从上面的过程可以看出，要实现模板的跨端共享，其实关键在于模块选择的一致性。市场上流行的模块标准有很多，比如K??MD、AMD、CommonJS。只要能通过一致的模块规范将NodeJS模板文件导出到NodeJS端，就可以完成基本的模板共享。后续系列文章将进一步探讨Model的代理和共享。Casestudy因为有了中途岛的中间层，过去的一些问题有了更好的答案。例如案例1复杂的交互应用（如购物车、订单页面）情况：所有的HTML都在前端渲染完成，服务端只提供接口。问题：进入页面时，会出现短暂的白屏。答：***进入页面，在NodeJS端进行整页渲染，后台下载相关模板。后续交互操作，在浏览器端完成局部刷新，使用相同的模板，产生相同的结果Case2单页应用状态：使用ClientSideMVC框架在浏览器中改变页面。问题：渲染和换页都是在浏览器端完成的。直接输入网址或f5刷新时，无法直接显示相同的内容。答：浏览器端和NodeJS端共享同一个Route。在浏览器端设置页面变化时，在浏览器端改变Route，渲染页面内容。当直接输入相同的URL时，页面框架+页面内容渲染会在NodeJS端进行。无论是在浏览器端更改页面，还是直接输入相同的网址，看到的内容都是一样的。除了增加经验和降低逻辑复杂度。它还解决了SEO的问题。案例三：纯浏览页面情况：页面只提供信息，交互很少或没有问题：HTML在服务器端生成，css和js放在另一个位置，相互依赖。答：通过NodeJS，如果以后需要扩展成复杂的应用或者单页应用，可以方便的转移html+css+js的统一管理。Case4跨终端页面状态：同一个应用需要在不同的端点呈现不同的界面和交互问题：HTML管理不易，往往会在服务端生成不同的html，需要在浏览器做不同的处理side答：跨终端终端页面是渲染问题，由前端统一处理。通过NodeJS层和后端服务，我们可以为这类复杂的应用设计出最佳的解决方案。综上所述，过去AJAX、Client-sideMVC、SPA、Two-wayDataBinding等技术的出现，都是为了解决当时前端开发遇到的瓶颈。NodeJS中间层的出现，也是试图解决目前前端局限于浏览器的一个局限性。本文重点介绍前后端模板分享，希望能够抛砖引玉与大家共同探讨如何在NodeJS中间层框架下完善我们的工作流程，如何配合后端使前端工作做得更好。原文链接：http://ued.taobao.org/blog/2014/04/xtpl/
