wenfeng

Brendan Eich在设计JavaScript的时候是没有加入类型系统的，所以JavaScript是一门动态语言，类型是进入执行上下文的时候可能才去确定，这就可能出现一个JavaScript变量在上一瞬间是String，下一瞬间就是Number了，在这个过程中，JavaScript变量进行了类型的转换。使用Javascript进行相等运算时，我们可能会用==，===和Object.is来进行比较两个值是否相等。 使用===时,恒等，严格比较运算符，不做类型转换，类型不同就是不等，NaN与NaN不相等。 使用Object.is()时，其行为与"==="基本一致，不过有两处不同: +0不等于-0。 NaN等于自身。 使用时，不同类型的值也可以被看作相等。这可能会让很多的JavaScript困开发者感到困惑。使用&

越来越臃肿的web应用 随着Web应用变得越来越复杂，特别是像一些toB的web应用(例如财务软件，ERP等企业级软件)，传统的前后端REST架构交互方案在极大的限制了软件的开发效率，提高维护的成本，不仅是前端，后端的开发和维护成本也是越来越高。 对于REST架构来说，主要的问题是以下几点： 过度获取数据，例如，有的时候前端为了满足在web和移动端的业务需求，可能会在同一接口是获取相同的数据，但是有的数据在两端上并不是必须的。 前端业务数据可能要通过多个接口请求去获得，而想chrome这样的浏览器允许的请求的最大的并发数是六个，在一定程度上会有体验方面的问题。 有一些REST接口并不十分规范，比如一些查询接口的数据字段过多就会被定义成POST接口。 前端需要知道每个接口服务的地址，才能去获得对应的资源数据。 如果后端API发生了更改，那么可能会导致另外一个或者多个API奔溃，前端数据可能会受到破坏，哪怕只是一个简单的数据结构调整，这对于前端来说很可能是致命的，大概率会跟着调整。 当有新的功能需要开发时，后台需要去聚合多个微服务的数据提供给前端使用。 由于REST架构让前后端产生了一定的耦合，除了以上的技术问题之外，

在开始聊Webassembly(下文简称为wasm)之前，咱先了解一下为什么会出现wasm这个全新的web格式。这得从Javascript的诞生说起。 Javascript的诞生 在1994年的时候，网景公司成立，同年发布了Navigator浏览器0.9版本，这个浏览器只能用来浏览，不能和用户进行相关的交互。1995年，Brendan Eich进入网景公司，花了十天的时间研究出了Mocha，之后更名为LiveScript，最后因为网景公司想趁Java的热度才更名成Javascript。 Brendan Eich主要研究的方向是函数式编程，网景公司希望研究将Scheme语言作为网页脚本语言的可能性。Brendan Eich也认同这种想法。网景公司希望网页脚本语言要与Java足够相似，并且要比Java简单，要让非专业的开发者也能上手，然而，Brendan Eich对Java谈不上一点喜欢，所以他花了10天就设计出了JavaScript。 Javascript的弊端和改进之路 由于JavaScript最初只是为了简单的在浏览器上进行简单的交互，所以Brendan