主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹

【2】JavaScript还是Simple，语言未必是问题

2009年7月27日，Google发布了一种新语言，Simple (http://code.google.com/p/simple/)。Google的官方声明中说，Simple语言的宗旨，是方便人们在Google Android环境下的开发工作。但是坊间有传言，Simple的真正目标，是取代JavaScript，让浏览器在Android环境中，运行得更敏捷。坊间传言可信吗？

前文提到，很多应用软件都遵循MVC范式，M=Model=Data，V=View=UI，C=Control=Logic。在View方面，Google 最新推出的Chrome OS，与传统意义的OS，有鲜明的不同。在传统OS环境下，应用程序的UI，通常是通过编程的手段来实现。而在Chrome OS环境下，应用程序开发者不需要编写程序去实现UI，他们要做的，只是定义HTML和CSS这样的文本文件。HTML和CSS只关注UI布局和渲染的最终效果，而实现预定结果的过程，交给浏览器去自动完成。

至于Control，它的作用主要是实现用户与应用程序的交互。例如，当用户用浏览器打开某个网页，点击这个网页中的某个按钮，这个网页会发生一些相应变化。相同的按钮，不同的网页，点击按钮的后果不一定相同。这意味着，应用程序的开发者，不仅要定义UI的布局和渲染效果，而且必须有权力去编写程序，制订事件响应的处理逻辑。

如果UI的定义是通过HTML+CSS来实现的，那么事件响应的程序应该放在那里呢？最自然的方式是把程序嵌入到HTML文本文件里。JavaScript 就是这样的做法。在HTML文本文件里，嵌入JavaScript代码，当浏览器捕捉到用户触发的事件以后，浏览器找到相应的JavaScript代码，然后把代码交给JavaScript Engine去解析并运行。

1996年，Brendan Eich发明JavaScript，并使之运行于Netscape浏览器。后起的微软的IE浏览器，也追随Netscape的做法，支持JavaScript。从此，JavaScript成为浏览器必备的功能。实现MVC范式中的Control，办法很多。JavaScript的办法，优点是容易开发，但是运行速度较低，CPU和Memory消耗较高。

传统的JavaScript Engine，采用的是逐句解析的方式，来执行JavaScript代码。用这样的方式来运行篇幅很长的JavaScript代码，运行速度必然快不了。为了提高速度，最新的JavaScript Engine，大多数采用即时编译（Just-In-Time，JIT）的做法。不同于传统的逐句解析的做法，JIT整段地编译JavaScript代码，并且缓存编译结果，以避免重新编译那些先前已经编译过的代码。另外，整段编译有利于自动优化代码。

引入JIT，意味着JavaScript不再是一个传统意义的脚本语言（Script Language）。脚本语言的本质之一，是逐句解析的解释型语言，而JIT改变了这个本质，使JavaScript悄悄向编译型语言演变。 JavaScript属于哪一类语言，并不是争论的焦点。焦点在于，人们开始质疑JavaScript语言本身，以及JavaScript Engine，它们是否有必要存在。

1. 既然JavaScript最终是作为一种编译型语言被运行，那么为什么不采用预先编译的做法？所谓预先编译的做法，就是当浏览器访问某个网页时，像往常一样，下载三种文件，HTML+CSS+JavaScript。但是与以往不同，JavaScript不是文本文件，而是预先编译好的二进制文件。

2. 如果预先编译的做法可行，那么进一步的问题是，谁负责运行预先编译好的二进制码，JavaScript Engine还是native OS？考虑到JavaScript Engine将耗费可观的CPU时间以及Memory空间，让JavaScript Engine去运行预先编译好的二进制代码，是否有画蛇添足的嫌疑？

3. 在CPU时间和Memory空间的消耗成本方面，或许Simple语言比JavaScript更优越。但是作为另一种脚本语言，Simple的优势似乎不可能超越native语言。所以，用Simple语言去取代JavaScript，似乎不具有太大的吸引力。

总之，我们怀疑JavaScript以及JavaScript Engine都是历史演变中，在短暂时期内出现的过渡性的解决方案。运行效率更高，CPU和Memory成本更低的解决方案，开发难度会比较大，但是并非不可能。