Before web2.0, although there were es and JSTL when writing jsp, we still insisted on jsp. Later, the outsourcing company used php Smart technology for fast delivery.
After web2.0, front-end template technology became popular.
There are three categories of representatives:
String-based template technology (string-based parse and compile process)
DOM-based template technology (based on Dom's link or compile process)
Living template (string-based parse and dom-based compile process)
String-based templating
This is a string-based templating technique that takes a string and data as input and constructs a complete HTML string by replacing placeholders with the required data with regular expressions.
The string template engine mainly relies on these dom APIs: createElement, appendChild, innerHTML.
Among these APIs, innerHTML has the best readability and practicality, and has become the main de facto standard. Although other APIs may be better in performance, the most commonly used string generation scheme in native js is innerHTML .
The biggest credit of a string-based template engine is that it frees you from a lot of string concatenation with entrained logic. Because of its completely string-based nature, it has some irreplaceable advantages.
It is essentially a way to address the need to populate an HTML view with data in a better way than having to write a big, ugly string concatenation expression.
Fast initialization time: A lot of angular fans taunting String-based templating seem to miss this.
Isomorphism: Completely dom-independent, it can be used as server-side and browser-side (guest officer, don't rush to move phantomjs first).
Stronger syntax support: Because they are either self-built DSLs or JavaScript-based syntaxes, Parser's flexibility is incomparable to HTML-limited Dom-based template technology
Since the string-based template method relies on innerHTML rendering, it brings the following problems.
Security issues: The use of innerHTML to build DOM has security risks. The dynamic data used for rendering may have security vulnerabilities. If it is not specially escaped, it may cause XSS attacks or CSRF attacks.
Because innerHTML has security implications., eg:
, I know a good programmer like you wouldn't write code like this, but when the html fragment isn't entirely under your control (like from a remote server), this becomes a A possible detonation of ×××.
Performance issue: Replacing the DOM with innerHTML is inefficient. Even if only one attribute or text content of the DOM is replaced, the entire DOM must be replaced by innerHTML, which results in browser reflow and repainting.
Development efficiency problem: Because the string is spliced in a specific function after matching with regular expressions, it is easy to cause repeated calculations, and the existing DOM is completely removed, and then re-rendered, the events and states mounted on the DOM are all will no longer exist
It is possible to create unexpected nodes : because the parser of html is so "friendly" that it accepts non-standard writing, thus creating unexpected structures, and the developer does not get an error message.
represent:
mustache and its derivative handlebar, etc.: weak logic
Dust.js : Strong logic (recommended)
doT.js : super fast
DOM-based模板技术
这是一种基于 DOM 节点的模板技术,通过innerHTML获取初始 DOM 结构,再通过 DOM API层级从原始 DOM 属性中提取事件、指令、表达式和过滤器等信息,编译成 LivingDOM,从而完成数据 Model和 View 的双向绑定。 AngularJS就是 DOM-based模板技术的代表。
Dom-based的模板技术事实上并没有完整的parse的过程(先抛开表达式不说)，如果你需要从一段字符串创建出一个view，你必然通过innerHTML来获得初始Dom结构. 然后引擎会利用Dom API(attributes,getAttribute,firstChild… etc)层级的从这个原始Dom的属性中提取指令、事件等信息，继而完成数据与View的绑定，使其”活动化”。
所以Dom-based的模板技术更像是一个数据与dom之间的“链接”和*“改写”*过程。
注意，dom-based的模板技术不一定要使用innerHTML，比如所有模板都是写在入口页面中时, 但是此时parse过程仍然是浏览器所为。
DOM-based模板技术比String-based模板技术更加灵活,功能也更加强大,达到了一定意义上的数据驱动。
是活动的: 完成compile之后，data与View仍然保持联系，即你可以不依赖与手动操作Dom API来更新View
是运行时高效的: 可以实现局部更新
指令等强大的附属物帮助我们用声明式的方式开发APP
但其存在以下问题：
信息冗余:信息承载于属性中，这个其实是不必要和冗余的。
由于 DOM-based模板技术通过innerHTML 获取 DOM 编译节点,信息承载于属性中,造成了不必要的冗余,同时也会影响阅读,提升开发难度。一种解决办法就是通过读取属性后再进行删除处理,诸如removeAttribute的方式移除它们，其实这个不一定必要，而且其实并无解决它们Dom强依赖的特性，还会影响性能,降低用户体验。
初始节点获取问题:通过innerHTML获取初始节点,没有独立的语法解析器或词法解析器,与 HTML是强依赖关系。初次进入 DOM 的内容是模板,渲染需要时间,所以会造成内容闪动——FOUC(Flash of unstyled content)这个无需多说了，只怪它初次进入dom的内容并不是最终想要的内容。
没有独立的Parser，必须通过innerHTML(或首屏)获取初始节点，即它的语法是强依赖与HTML，这也导致它有潜在的安全问题
代表：
AngularJS: 都28000star了还需多说么
Knockout: 在此领域内，对Web前端而言是鼻祖级的
Livingtemplate技术
Livingtemplate技术与String-based、DOM-based模板技术的最大区别是不依赖innerHTML来渲染和提取所需信息。其主要思想是:首先,结合数据绑定技术,使用成熟的词法解析和语法解析
技术,将输入的字符串解析成抽象语法树AST，而不是仅仅通过简单的正则表达式匹配特定语法,再进行字符串拼接;其次,通过对 AST进行编译,创建具有数据动态绑定功能的 Living DOM,从而避免使用innerHTML,解决了浏览器的元素闪动问题,提高了应用的安全性,其原理如图1所示。
从图1可知,输入的字符串通过词法解析器Lexer,生成对应的词法块。词法块通过语法解析器 Parser,构建抽 象 语 法 树 AST。然 后 将 AST编译成具有动态数据绑定功能的LivingDOM,从而实现 View 和 Model的双向绑定。
与Dom-based 模板技术利用Dom节点承载信息所不同的是，它的中间产物AST 承载了所有Compile过程中需要的信息(语句, 指令, 属性…等等).
我们可以发现Living templating几乎同时拥有String-based和Dom-based模板技术的优点
利用一个如字符串模板的自定义DSL来描述结构来达到了语法上的灵活性，并在Parse后承载信息(AST)。而在Compile阶段,利用AST和Dom API来完成View的组装，在组装过程中，我们同样可以引入Dom-based模板技术的诸如Directive等优良的种子。
living template’s 近亲 —— React
React当然也可以称之为一种模板解决方案，它同样也巧妙规避了innerHTML，不过却使用的是截然不同的策略：react使用一种virtual dom的技术，它也同样基于脏检查，不过与众不同的是，它的脏检查发生在view层面，即发生在virtual dom上，从而可以以较小的开销来实现局部更新。
轻量级, 在Dom中进行读写操作是低效的.
可重用的.
可序列化, 你可以在本地或服务器端预处理这个过程。
安全, 因为安全不需要innerHTML帮我们生成初始Dom
代表：
htmlbar: 运行在handlebar之后的二次编译
ractivejs: 独立
Regularjs独立
此文还需进一步整理，以及自定义模板引擎思考方向与工程实践内容补充。这方面需要下的功夫还是需要蛮多的，敬请期待。
For reprints, please indicate the source "Let's talk about front-end HTML template technology " and the reference document reference link. If there is any infringement or inappropriateness in this article, please notify me to revise it. This article is still the first draft. thanks
Reference documentation:
Design and Implementation of Data-driven Dynamic Web Template Technology
[Communication and discussion] What do you think about front-end template technology? . .
Template engine principle and partial implementation
Build a front-end template engine using Virtual-DOM
Summary of front-end data template engines
How to implement a DOM-based template engine
A comprehensive summary of front-end template technology