1.7 JavaScript的应用环境
在此前的内容中，我们讨论的都是JavaScript语言及其规范，而并非该语言的应用环境。在大多数人看来，JavaScript的应用环境就是Web浏览器，这也的确是该语言最早的设计目标。然而从很早开始，JavaScript语言就已经在其他的复杂应用环境中使用，并受这些应用环境的影响而发展出新的语言特性了。
JavaScript的应用环境，主要由宿主环境与运行期环境构成。其中，宿主环境是指外壳程序（shell）和Web浏览器等，而运行期环境则是由JavaScript引擎内建的。图1-9说明了由宿主环境和运行期环境共同构建的对象编程系统的基本结构。
图1-9 由宿主环境与运行期环境构成的应用环境
1.7.1 宿主环境
JavaScript是一门设计得相对“原始”的语言，它被创建时的最初目标仅仅是为Netscape提供一门在浏览器与服务器间都能统一使用的开发语言。简单地说，它原来的设计目标是想让B/S架构两端的开发人员用起来都能舒服一些。这意味着最初的设计者希望JavaScript语言是跨平台的，能够提供“端到端（side to side）”的整体解决方案。
然而事实上这非常难做到，因为不同的平台提供的“可执行环境”不同。而宿主环境（host environment）就是为了隔离代码、语言与具体的平台而提出的一种设计。一方面，我们不能让浏览器中拥有一个巨大无比的运行期环境（例如像虚拟机那么大）；另一方面，服务器端又需要一个较强大的环境，因此JavaScript就被设计成了需要“宿主环境”的语言。
ECMAScript规范并没有对宿主环境提出明确的定义。比如，它没有提出标准输入和标准输出（stdin、stdout）需要确切地实现在哪个对象中。为了弥补这个问题，RWC在WebAPI规范中首先就提出了“需要一个window对象”的浏览器环境。这意味着在RWC或者浏览器端，是以window对象及其中的Document对象来提供输入输出的。
但这仍然不是全部的真相。因为“RWC规范下的宿主环境”，并不等同于“JavaScript规范下的宿主环境”。本书也并不打算讨论与特定浏览器相关的细节问题，因此我们采用在多数宿主程序中的实现：使用全局对象console来提供输入输出，如表1-2所示。
表1-2 本书对宿主环境在全局方法上的简单设定
1.7.2 外壳程序
外壳程序（shell）是宿主的一种。
不过在其他的一些文档中并不这样解释，而是试图将宿主与外壳分别看待。其中的原因在于将“跨语言宿主”与“应用宿主”混为一谈。
在Windows环境中，微软提供的WSH（Windows Script Host）是一种跨语言宿主，在该宿主环境中提供一个公共的对象系统，并提供装载不同的编程语言引擎的能力。如此一来，WSH可以让多种语言使用同一套对象—这些对象由一些COM组件来实现并注册到Windows系统中。所以我们在IE浏览器中既可以用VBScript操作网页中的对象，也可以用JScript来操作。基本上来讲，IE浏览器采用的是与WSH完全相同的宿主实现技术。
多数JavaScript引擎会提供一个用于演示的外壳程序。该外壳程序通过一种命令行交互式界面来展示引擎的能力—在UNIX/Linux系统中编程的开发人员会非常习惯这种环境，而在Windows中编程的开发人员则不然。在这种环境下，可以像调试器中的单步跟踪一样，展示出许多引擎内部的细节。图1-10所示的是SpiderMonkey JavaScript随引擎同时发布的一个外壳程序，它就是（该脚本引擎的）一个应用宿主。
如同引擎提供的这种外壳程序，我们一般所见到的shell是指一种简单的应用宿主，它只负责提供一个宿主应用环境：包括对象和与对象运行相关的操作系统进程。但是在另外一些情况下，“外壳（而不是外壳程序）”和“宿主”也被赋予一些其他的含义。例如，在WSH中，“宿主”是指整个的宿主环境和提供该环境的技术，而“shell”则是其中的一个可编程对象（WScript.WshShell）—封装了Windows系统的功能（例如注册表、文件系统等）的一个“外壳对象”，而非“外壳程序”。
而Node.js的情况比这些都要复杂。Node.js中的默认JavaScript引擎是V8，这个脚本引擎可以连接到node主进程的内部，或者单独以DLL（动态链接库）的形式提供。所谓node主进程，就是一个宿主，然而这个宿主如果以交互形式运行，那么它又是一个传统意义上的外壳程序。在后者这种情况下，开发人员可以在命令行交互式界面上进行测试、调试等，由其（动态加载的）内核模块repl来提供支持。在这两种模式下，Node.js都以全局的process对象来提供对宿主的访问，例如可以通过process.moduleLoadList查看当前装载的模块列表。
图1-10 SpiderMonkey JavaScript提供的外壳程序
讨论脚本引擎本身时，我们并不强调宿主环境的形式是WSH这种“使用跨语言宿主技术构建的脚本应用环境”，还是SpiderMonkey JavaScript或Node.js所提供的这种“交互式命令行程序”。我们只强调：脚本引擎必须运行在一个宿主之中，并由该宿主创建和维护脚本引擎实例的“运行期环境（runtime）”。
1.7.3 运行期环境
不同的书籍对JavaScript运行期（runtime）环境的阐释是不一样的。例如，在《JavaScript权威指南》中，它由“JavaScript内核（Core）”和“客户端（Client）JavaScript”两部分构成；而在《JavaScript高级程序设计》中，它被描述成由“核心（ECMAScript）”“文档对象模型（DOM）”“浏览器对象模型（BOM）”三个部分组成（见图1-11）。
图1-11 对“运行期环境”的不同解释
本书是从引擎的角度讨论JavaScript的，因此在本书看来，与浏览器相关的内容都属于“应用环境”：属于宿主环境或属于用户编程环境。本小节开始位置的图1-9表达了这种关系。在这样的关系中，运行期环境是由宿主通过脚本引擎（JavaScript Engines）创建的。图1-12说明了应用程序—宿主在这里可以看成一个应用程序—如何创建运行期环境。
图1-12 应用（宿主）通过引擎创建“运行期环境”的过程
因此，在本书中讲述的运行期环境特指由引擎创建的初始应用环境。主要包括：
■ 一个对宿主的约定。
■ 一个引擎内核。
■ 一组对象和API。
■ 一些其他的规范。
我们这样解释运行期环境的特点，而并不强调（或包括）在应用、宿主或用户代码混杂作用的、运行过程中的应用环境，就是要将讨论聚焦于引擎自身的能力。不过即使如此，不同的JavaScript脚本引擎所提供的语言特性也并不一致。因此，在本书中若非特别说明，JavaScript是指一种通用的、跨平台的和跨环境的语言，并不特指某种特定的宿主环境或者运行环境。也就是说，它是指ECMAScript-262所描述的语言规范。
1.7.4 兼容环境下的测试
本书撰写的代码主要使用Node.js 4.x来进行测试，但所有代码全部经过兼容性检查，以确保它们在Node.js 4.x之后的版本中表现一致（或对有差异的内容做出明确解释）。
本书所述的兼容环境包括Chakra、JavaScriptCore、Node.js、SpiderMonkey、V8和xs。本书使用ESHOST和JSVU来构建测试环境，并确保所有示例得到完整测试。读者可以尝试通过如下方式构建相应的测试环境。
需要留意的是，默认情况下执行jsvu总是更新全部最新版本的JavaScript引擎。你可以用如下命令行来切换不同的版本，或指定JSVU或ESHOST有选择地管理哪些引擎。例如：
本书将通过开源项目提供全部章节的示例和相关代码，读者可以参考阅读。