基于前后端分离的模版探索

在做前后端分离时，第一个关注到的问题就是 渲染，也就是 View 这个层面的工作。

在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。

而我们选择了NodeJS，作为一个前后端的中间层。试图藉由NodeJS，来疏理 View 层面的工作。

使得前后端分工更明确，让专案更好维护，达成更好的用户体验。

本文
渲染这块工作，对于前端开发者的日常工作来说，佔了非常大的比例，也是最容易与后端开发纠结不清的地方。

回首过去前端技术发展的这几年， View 这个层面的工作，经过了许多次的变革，像是：

Form Submit 全页刷新 => AJAX局部刷新
服务端续染 + MVC => 客户端渲染 + MVC
传统换页跳转 => 单页面应用
可以观察到在这几年，大家都倾向将 渲染 这件事，从服务器端端移向了浏览器端。

而服务器端则专注于 服务化 ，提供数据接口。

浏览器端渲染的好处
浏览器端渲染的好处，我们都很清楚，像是

摆脱业务逻辑与呈现逻辑在Java模版引擎中的耦合与混乱。
针对多终端应用，更容易以接口化的形式。在浏览器端搭配不同的模版，呈现不同的应用。
页面呈现本来就不仅是html，在前端的渲染可以更轻易的以组件化形式 (html + js + css)提供功能，使得前端组件不需依赖于服务端产生的html结构。
脱离对于后端开发、发佈流程的依赖。
方便联调。
浏览器端渲染造成的坏处
但是在享受好处的同时，我们同样的也面临了 浏览器端渲染 所带来的坏处，像是：

模版分离在不同的库。有的模版放在服务端 (JAVA)，而有的放在浏览器端 (JS)。前后端模版语言不相通。
需要等待所有模版与组件在浏览器端载入完成后才能开始渲染，无法即开即看。
首次进入会有白屏等待渲染的时间，不利于用户体验
开发单页面应用时，前端Route与服务器端Route不匹配，处理起来很麻烦。
重要内容都在前端组装，不利于SEO
反思前后端的定义
其实回头想想，在我们把渲染的工作从 服务端(Java) 抽出来到 浏览器端(JS) 的时候，我们的目的只是 明确的前后端职责划分，并不是非浏览器渲染不可 。

只是因为在传统的开发模式中，出了服务器就到了浏览器，所以前端的工作内容只能被限制在浏览器端。