2019年12月16日，北京下了今冬第二场雪❄️，不大不小。
年终岁尾，国际上几大软件及互联网公司（Google、Microsoft、Apple和Mozilla）拉上互联网标准化机构W3C发布了 Web Assembly的推荐标准（ -R/t2SS ）。此举意味着，WebAssembly技术从遮遮掩掩的实验室后台走向前台，开始面向大众，尤其是开发者进行推广应用。
- Web Assembly推出背景猜测
Assembly 字面上的解释是， “a group of people gathered together in one place for a common purpose”，一群人为一个共同的目标聚集到一个地方。Web Assembly的目标简略地说，就是将 C/C++/Rust 这些编程语言写的程序能够运行在上面那几大公司到网页浏览器中（Google Chrome，Microsoft Edge，Apple Safari 和 Mozilla Firefox）。目前在网页上流行的编程语言 JavaScript 将迎来或是帮手，抑或是对手的Web Assembly。
时光倒回到约10年前， HTML5 标准刚推出来时，其首要的任务是丰富 HTML 或者说 网页应用，使之能够承载其由“内容展示平台”向“应用承载平台”转变的重任（此前 -人民网 内部研究报告）。在这之前，一直是 Adoble Flash努力地奋斗着。 HTML5 贡献了一大批新颖的功能，网页告别第一代只能做内容展示的功能受限版。
HTML5 带来了浏览器/网页作为“应用承载平台”的大发展。不想中途出现了“应用商店”App的怪胎，一下子将互联网前进的步伐打回到PC单机时代，要用个什么软件都需要下载、安装，这明显与互联互通都发展趋势是相背离的。信息孤岛逐渐形成，互联网的继续发展不是加速信息的流动，相反是加剧了信息的不对称，不流通。
这既有商业层面的利益考虑，也有技术层面的制肘，网页应用计算力弱，体验不好，安全有问题等等，一时局面甚是尴尬，有几个应用商店，一个应用就需要开发几个不同的版本。信息在各个APp之间逐渐扎起篱笆，这些与互联网先驱们的让信息更加流畅地流动的理念渐行渐远。
直到 WeAssembly的推出，或许是扭转时局的契机之一。HTML5将网页由“内容展示平台”升级到“应用承载平台”，WebAssembly或将进一步升级优化”应用承载平台”，从根本上消除网页应用与本地应用之间到性能差异。从而实现“Open and Run”， 而不是 “Open 、Download、Install and Run”，实现“Write once， run anyway”， 而不是“Write once more，run once more”。
在 WebAssembly之前，也有类似的探索， 如 asm.js , 甚至上 Java的 Applet 都是希望将编译后的程序能够在浏览器中安全高效地运行，现在看之前的努力并不算成功，希望这次能有所不同而获得预期效果。
2. WebAssembly的直觉体验
对 WebAssembly 的直觉体验：由 hello.c 到 hello.html
$ mkdir hello $ cd hello
$ cat << EOF > hello.c #include <stdio.h> int main(int argc, char ** argv) { printf("Hello, world!\n"); } EOF
$ emcc hello.c -o hello.html
可以预见，大量必需由 C/C++/Rust 写的程序将有可能轻松移植到浏览器以网页应用的形式交付，极大地改变了软件研发及交付的方式方法。
3. Web Assembly的发展前瞻
3.1. WebAssembly 可能不会取代 JavaScript
而只是对其的互补，在 JavaScript 短板之处寻找其发展空间，展现其优势。
3.2. 客户端软件App
单独为特定平台写App的需求将降低，网页应用将逐渐实现跨平台，并与本地应用相一致的体验和性能。有望实现网页应用一版通天下。单独写iOS客户端，Windows客户端，或者Andorid客户端的开发人员，可能需要着手学习使用 WebAssembly。
前景是美好的，预计Native App还将存在相当长时间，并存与网页应用，并逐渐转为小众领域的特定开发。
3.3. C/C++/Rust 走向前端
古老的C/C++等编程语言将应用范围扩展到前端，从而实现真正意义上到跨平台。用 C/C++等写HTML网页，将不再是互联网上的笑话。
如此以来，为解决 C/C++ 写不了网页HTML而诞生等解决方案或者编程语言等，是否也就过时了？ 或者意义不大了？
如果 C/C++ 能写网页，还需要用 ASP.NET/PHP/Perl/Python或者Java 来写 HTML应用吗？或许需要，因为有大量类库已经开发，或许需要，还有其他更多完整的生态考虑。但有一点确认的是， WebAssembly的推出，引发我们对这样对问题的重新审视和思考。
3.4. 网页应用
网页应用开发人员需要熟悉新情况，有了新增的屠龙刀，也要善加利用才能将其设计功效发挥出来。
JavaScript 有了 Web Assembly的加持和增强，其性能或有进一步的提升，可供用来设计的应用软件将进一步的扩增，体验或将更好。
得益于 JavaScript进步，也得益于Web Assembly的推出，依赖于其上 Hanjst 汉吉斯特模版语言及引擎将运行更快，体验更好。我们将着手针对这些新特性进行优化。
Hanjst.js 已经投入不少使用。
Hanjst.was / Hanjst.wasm 也将开始研发，为追求更极致的性能和体验，Hanjst 或将以 C/C++/Rust 编写，然后经编译后，引入到浏览器中进行运行。
3.5. 网络应用开发框架 Web Framework
如前所述，既然Web Assembly的原生代码可以工作在服务器端，而编译后的.wasm 可以运行在客户端浏览器中，那么开发网络应用的方式方法势必要受此影响而有所改变。
因此，可以预见，通用网络应用架构GWA2，或将以此为契机进行改造升级，推出 GWA2 in Assembly 或者 GWA2 in C / GWA2 in C++， 又或者是 GWA2 in Rust.
至于最终实现的是 GWA2 的哪个新版本，可能要结合 Web Assembly推广应用普及到一定阶段之后才能有某种趋势判断或定论。
Hanjst是一种基于JavaScript的模板语言及解析引擎，她运行在客户端/服务器端。
Hanjst能够表述逻辑控制，能够实现与服务器端模版语言相同的功能。
-
Hanjst当完全在客户端解析时，节省服务器端计算资源;
-
Hanjst模板语言独立，不与服务器端资源做任何绑定；
-
纯粹的MVC，层间数据用JSON格式传递；
-
常见模板语言功能全支持，附带复杂而强大的JavaScript编程能力；
-
无学习成本，直接使用JavaScript书写模板语言；
-
….
Hanjst is a JavaScript-based templating language and parsing engine that runs on both the client-side and/or server-side.
Hanjst can express logical control and achieve the same functionality as the server-side templating languages.
-
Hanjst’s Run-time in client-side, reduce computing render in server-side;
-
Hanjst is Language-independent, not-bound with back-end scripts or languages;
-
Totally-isolated between MVC, data transfer with JSON;
-
Full-support template tags with built-in logic and customized JavaScript functions;
-
No more tags languages to be learned, just JavaScript;
-
….
