Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
37 lines (20 sloc) 6.09 KB

封面

现代 JavaScript 开发:语法基础与工程实践

历经二十载风云变幻,JavaScript 也终于成为了一流的语言,在前端开发、服务端开发、嵌入式开发乃至于机器学习与数据挖掘、操作系统开发等各个领域都有不俗的表现。而在这不断的变化之后,也有很多语法或者模式成了明日黄花;本系列文章即是希望为读者总结与呈现出最新的应该掌握的 JavaScript 语法基础与实践基础。

JavaScript 的设计与语法一直为人所诟病,不过正如 Zeit 的 CEO Guillermo Rauch 所言:JavaScript 虽然生于泥沼,但是在这么多年不断地迭代中,它也慢慢被开发者与市场所认可,最终化茧成蝶,被广泛地应用在从客户端到服务端,从应用开发、系统构建到数据分析的各个领域。JavaScript 最薄弱的一点在于其是解释性的无类型的语言,这一点让其在大型项目或者系统开发中充满了很多的性能瓶颈或者不稳定性;譬如在 JavaScript 中某个函数可以接受任意数目、任意类型的参数,而 Java 则会在编译时即检测参数类型是否符合预期。早期的 JavaScript 仅被用于为网页添加简单的用户交互,譬如按钮响应事件或者发送 Ajax 请求;不过随着 Webpack 等现代构建工具的发展,开发者可以更加工程化地进行高效的前端项目开发,并且整个网页的加载性能也大大提高,譬如 PWA 等现代 Web 技术能够使 Web 应用拥有与原生应用相近的用户体验。

我喜爱这门语言,所以我希望能够以绵薄之力让更多的人无痛地使用它,在返回主页后您可以看到更多有关 JavaScript 的代码实践。本篇的所有参考资料声明在 Awesome JavaScript Lists

ECMAScript

ECMAScript 是 JavaScript 语言的国际标准,JavaScript 是 ECMAScript 的实现。要讲清楚这个问题,需要回顾历史。1996 年 11 月,JavaScript 的创造者 Netscape 公司,决定将 JavaScript 提交给国际标准化组织 ECMA,希望这种语言能够成为国际标准。次年,ECMA 发布 262 号标准文件(ECMA-262 )的第一版,规定了浏览器脚本语言的标准,并将这种语言称为 ECMAScript。这个版本就是 ECMAScript 1.0 版。

之所以不叫 JavaScript,有两个原因。一是商标,Java 是 Sun 公司的商标,根据授权协议,只有 Netscape 公司可以合法地使用 JavaScript 这个名字,且 JavaScript 本身也已经被 Netscape 公司注册为商标。二是想体现这门语言的制定者是 ECMA,不是 Netscape,这样有利于保证这门语言的开放性和中立性。因此,ECMAScript 和 JavaScript 的关系是,前者是后者的规格,后者是前者的一种实现。在日常场合,这两个词是可以互换的。

ECMAScript 定义了:

ECMAScript 标准不定义 HTML 或 CSS 的相关功能,也不定义类似 DOM(文档对象模型)的Web API,这些都在独立的标准中进行定义。ECMAScript 涵盖了各种环境中 JS 的使用场景,无论是浏览器环境还是类似node.js的非浏览器环境。

特性阶段

  • Stage 0 “strawman” — The starting point for all proposals. These can change significantly before advancing to the next stage. There is no acceptance criteria and anyone can make a new proposal for this stage. There doesn’t need to be any implementation and the spec isn’t held to any standard. This stage is intended to start a discussion about the feature. There are currently over twenty stage 0 proposals.

  • Stage 1 “proposal” — An actual formal proposal. These require a “champion”(i.e. a member of TC39 committee). At this stage the API should be well thought out and any potential implementation challenges should be outlined. At this stage, a polyfill is developed and demos produced. Major changes might happen after this stage, so use with caution. Proposals at this stage include the long-awaited Observables type and the Promise.try function.

  • Stage 2 “draft” — At this stage the syntax is precisely described using the formal TC39 spec language. Minor editorial changes might still happen after this stage, but the specification should be complete enough not to need major revisions. If a proposal makes it this far, it’s a good bet that the committee expects the feature to be included eventually.

  • Stage 3 “candidate” — The proposal has approved and further changes will only occur at the request of implementation authors. Here is where you can expect implementation to begin in JavaScript engines. Polyfills for proposals at this stage are safe to use without worry.

  • Stage 4 “finished” — Indicates that the proposal has been accepted and the specification has been merged with the main JavaScript spec. No further changes are expected. JavaScript engines are expected to ship their implementations. As of October 2017 there are nine finished proposals, most notably async functions.

You can’t perform that action at this time.