Javascript竟然没有标准库?

_sx_

发布于 2019-08-07 14:40:59

1.6K0

发布于 2019-08-07 14:40:59

文章被收录于专栏：前端技术地图

Javascript竟然没有标准库?

Bobi.ink

2019-07-16

最近在SegmentFault热心解题，一个问题比较让我比较印象深刻：一个初学者试图在浏览器中导入Node.js的net模块。结果就是在控制台打印后是一个空对象。

对于有点Javascript经验的人来说，这是一个‘弱智’问题，怎么可以在浏览器端运行Node程序呢？因为这些node模块经过webpack处理, 所以变成了一个空对象，更好的处理应该是抛出异常.

仔细反思一下，对于这些刚入门Javascript的或者从其他语言切换过来的，他们压根就没有概念，比如Python、Ruby、Java这些语言都有强大的标准库，可以满足80%的开发需求，不管它在什么环境、什么平台运行，都可以统一使用这套标准库。而Javascript目前的现状就是不同的运行环境API结构是割裂的。

Javascript这门十几天开发出来的、专供浏览器的语言，可能当初设计是根本就没有考虑标准库这些玩意，比如文件系统，网络等等。因为这个背景, Javascript不具备独立性，它深度依赖于浏览器这个运行环境, 处于一种给浏览器打辅助的角色, 所以Javascript很多年没有走出浏览器玩具语言这个范围. 当然这既是劣势，也是优势, 现在没任何语言能撼动Javascript在浏览器中的地位。

我想很多人跟我当初一样将浏览器提供的Web API等价于Javascript的标准库, 比如console.log、setTimeout(下文会介绍这些功能都不在Javascript规范里面). 正如当年那些把JQuery当成Javascript的人.

直到NodeJS的出现，Javascript才走出浏览器约束，延伸到服务器领域, 不再是一个’沙盒语言’。NodeJS定义了很多模块来支撑服务端的开发, 如fs、os、Buffer、net。但是这些和WebAPI一样不是标准的、也就是说NodeJS !== Javascript.

再到后来，学不动了，NodeJS原作者吐槽了一通NodeJS，又搞出了一个Deno, 它也会有自己标准库，会定义自己的文件系统、网络API。从名字上就暗示着这些API不可能和NodeJS兼容。Ok，现在回到文章开始那个问题，如果deno发展起来，说不定哪天又有人尝试在浏览器引用Deno的模块？

现有的Javascript API结构

如上图, Javascript其实是有一层比较薄全局的、通用的、标准的、核心的API层，即标准内置对象，这是一些语言核心的内置对象，可以全局访问。关键的是这些是标准的，它们在ECMAScript规范中被定义. 在这个基础之上，不同的运行环境拓展了自己的API。

以浏览器为例:

浏览器端的Web API是一个非常复杂API集合，上图总结了一下基本就包含两块东西:

Core DOM. DOM是一个通用的技术，不仅仅局限于浏览器，这个规范定义了结构化(structured document)文档的解析和操作规范。定义了基本的节点类型和操作方法。不局限于HTML的操作
HTML DOM. 可以认为是Core DOM的扩展，这里面定义了各种HTML元素对象类型、扩展了元素的操作方法，另外还包含了浏览器相关的接口，如XMLHttpRequest。这一块通常也被统称为BOM

WebAPI基本概览:

如果你有留心查看MDN文档下面的规范引用，你会发现有些规范引用了W3C, 有些则引用了WHATWG. 到底谁说了算?

如果你掀开锅盖，就会发现这是一场闹剧. 如果前阵子有关注新闻，会看到这些标题‘WHATWG 击败 W3C，赢得 HTML 和 DOM 的控制权’、’W3C将与WHATWG合作制定最新HTML和DOM规范标准’. 大概可以猜出这两个组织之间的关系. 本文就不扯这些‘八卦’了，相关背景可以看这篇文章WHATWG 击败 W3C，赢得 HTML 和 DOM 的控制权

相对而言, 语言层则由ECMAScript规范定义的，比较独立, 近些年成果也比较显著.

标准内置对象层主要包含这些东西

特殊值
- Infinity
- NaN
- undefined
- null
- globalThis
函数
- eval()
- uneval()
- isFinite()
- isNaN()
- parseFloat()
- parseInt()
- decodeURI()
- decodeURIComponent()
- encodeURI()
- encodeURIComponent()
基础对象
- Object
- Function
- Boolean
- Symbol
- Error
- EvalError
- InternalError
- RangeError
- ReferenceError
- SyntaxError
- TypeError
- URIError
数值和时间
- Number
- BigInt
- Math
- Date
文本处理
- String
- RegExp
索引容器
- Array
- ‘TypedArray’
键值容器
- Map
- Set
- WeakMap
- WeakSet
结构化数据
- ArrayBuffer
- SharedArrayBuffer
- Atomics
- DataView
- JSON
控制抽象化对象
- Promise
- Generator
- GeneratorFunction
- AsyncFunction
反射
- Reflect
- Proxy
国际化
- Intl
WebAssembly
其他
- arguments

这些全局基本对象数量很少, 平时我们使用的非常频繁的定时器和Console都不再此列. 这些对象是每个JavaScript开发者必须掌握的.

这些对象只能满足很基本开发需求, 根本不能和其他语言的标准库相比. 当然这和语言的定位也有一定关系，JavaScript最初的定位就是浏览器脚本，谁知道它现在发展得这么快？

什么是标准库?

标准库是什么没有一个规范化的定义，按照Wiki的说法标准库就是该语言在不同实现中都按例提供的库, 比如Ruby官方实现和基于JVM的JRuby都应该按照规范实现标准库。 标准库怎么设计，需要包含什么内容取决于语言各自秉持的哲学和定位。我认为标准库应该有以下特征:

标准化的，有规范明确定义它的内容和行为
内容经过仔细雕琢和挑选，可以覆盖大部分使用场景或者符合的语言定位
可选的、按需导入. 标准库不是全局的，需要通过模块导入, 非强制性使用

至于标准库需要包含什么内容，可以参考其他语言的实现。比如：

大概分析一下，它们标准库大致都有这些内容：

网络协议
文件系统
- 文件系统
- 流
- 标准输入输出
- 二进制处理
算法
- 密码算法
- 编码
- 压缩、归档
- 排序
- 数学
- 字符串、文本
数据结构, 例如树、堆、队列等等
数据持久化和序列化. 比如JSON序列化，二进制序列化，数据库操作等等
调试/辅助
单元测试
文档处理
设计模式. 标准库中经常会携带(或辅助设计)该语言的最佳实践和设计模式, 例如go中的context, Ruby中的singleton
国际化
时间、日期
操作系统
- 命令行
- 环境变量
- 系统资源
并发
- 进程
- 线程
- 协程
语言底层原语

大部分语言的核心都很小(C++除外)，我们学一门语言，大部分时间是花在标准库上，但是你会发现这些标准库一般都是大同小异，这就是为什么有经验的开发者可以很快地入手一门语言.

显然上面这些功能大部分在NodeJS中已经实现了，鉴于NodeJS这么广泛的使用率，NodeJS可以算是事实上的标准了

我们需要标准库?

显然是需要的，但是要结合当前的背景来辩证地考虑。

有标准库有什么好处?

标准库提供通用、定义良好、优化的功能和行为，减少第三方模块依赖, 而且第三方库很难保证质量
避免社区割裂, 抚平不同运行环境的差异. 现在有NodeJS、后面有Deno，可能还会有Aeno、Beno, 尽管取代NodeJS的可能性很低，有规范化的标准库可以避免重复造轮子，不然真会学不动
安全性. 近期npm投毒、删库(left-pad事件)、npm商业运作, 给社区带了不少麻烦。标准库由运行环境内置，可以避免引用第三方库导致的安全问题
今天的Javascript应用会有很多依赖(node_modules hell)，打包出来的体积很大，网络加载和脚本解析需要耗费一定的资源，而且这些资源不能在多个应用之间被缓存. 一个很大的原因是npm的依赖过于零碎(比如几行代码的包)和重复(依赖不同的版本、Dead Code)，使用标准库可以减少这部分依赖
选择困难症. 没有标准库，可以选择npm上的第三方库，有时候就是懒得去比较和选择
优雅的标准库，是学习的榜样. 网上很多教程都是钻研标准库算法和实现的，对语言的开发者来说标准库是一块宝藏
学习成本。其他语言的开发者，可以较快入手

标准库可能会有什么问题?

标准可能滞后跟不上社区发展. Javascript正处于快速发展阶段，很多规范的定义是由社区驱动的，比如Promise、async/await. 跟不上社区的发展结果可能就是没人用
想下WebComponent目前的境遇
标准库不可能满足所有人的口味

如何设计标准库? 标准库推进进程可能会有什么障碍?

NodeJS已经是事实上的标准, 怎么兼容现有的生态?
标准库应该包含什么内容，如何保持和社区同步?
如何把控标准库内容的尺度? 最小化的标准库容易被维护和升级，就可能出现没什么卵用的情况；最大化的标准库，例如Java的标准库，几乎包含了所有的东西，开发者可以快速开发一个东西, 但是过了几年很多API就会变得过时，一般为了保持向下兼容，这些API会一直像一根刺一样卡在那里，另一个非常典型的反例就是PHP的标准库，这里可以看到各种风格的API. 而且标准库是跟随语言发布的，如果你的项目中使用了过时的API，又想升级语言版本，就需要重构项目。而使用第三方库则可能可以保持不动。
Javascript的主要战场还是浏览器, 标准库是否应该有一个基本版(浏览器或者一些操作系统抽象的运行环境)还有个旗舰版(服务端), 或者只提供一个跨越所有平台的标准库?
如何处理兼容性问题?
如何与现有的全局对象或用户模块分离？

近期的一些尝试

proposal-javascript-standard-library 这是一个非常早期的语言提议，定义了如何引用标准库(built-in modules)，但是没有定义标准库的内容
KV Storage: the Web’s First Built-in Module Chrome在年初推出的实验性功能，尝试实现proposal-javascript-standard-library提议. 它通过下面方式来引用‘标准库’模块: import {storage, StorageArea} from 'std:kv-storage'; // std: 前缀，和普通模块区分开来