ECMAScript簡史和 JavaScript的將來（譯）

時間 2019-11-10

標籤 ecmascript 簡史 javascript 將來欄目 JavaScript 简体版

原文原文鏈接

本文翻譯自 Nicolas Bevacqua 的書籍《Practical Modern JavaScript》,這是該書的第一章。翻譯時我收穫很大，但願閱讀時你也能有所收穫。javascript

本章主要講述瞭如下內容：css

JS語言的發展簡史；html

規範的stage0,stage1,stage2,stage3,stage4各階段的意義；java

ployfill是侷限性的新規範實現；node

babel，eslint的基本使用方法;git

ES6的劃分；github

如下爲正文web

誰也想不到，1995年被當作營銷策略推出的JavaScript語言，在2017年成爲了最受歡迎平臺（web）上的核心語言。JavaScript如今不只能夠在瀏覽器中運行，它還被用做開發桌面和手機應用，用於嵌入式設備，甚至NASA還拿它來設計太空組件。正則表達式

這些年來，JavaScript語言取得的成績有目共睹，其變化也是日異月殊，咱們不由好奇，JS是如何取得這些成績的，將來的JavaScript又該向何處發展？算法

JS標準制定簡史

1995年，那時候的瀏覽器還只支持html和簡單的css,當時的瀏覽器巨頭--網景公司，不甘於瀏覽器中只能實現用HTML的靜態網站，Brendan Eich 也所以被招進網景，着手開發一種供瀏覽器使用的相似Scheme的函數式語言。不過他加入後發現，網景公司高層但願這門語言看起來像Java（存在暗中進行的交易）。

只花了10天時間 Brendan 就開發完成了當時被稱做Mocha的第一版 JavaScript 原型，這個新語言相似 Scheme ，它把函數當作一等公民，並以原型鏈爲其核心。那時候的JS比較簡陋，沒有數組和字面量的對象的概念，全部的報錯都只能經過醜陋的alert展現，缺少異常處理機制，出錯時不少運算的結果會是NaN或undefined。不過 Brendan 對 DOM 0 的描述及第一版的JavaScript仍是成爲了最初的標準。

1995年9月，網景公司發佈了Netscape Navigator 2.0 beta版，JavaScript也被包裝爲LiveScript一同面世。1995年12月，Netscape Navigator 2.0 beta3發佈，LiveScript在這時被更名爲JavaScript(當時這個商標爲Sun公司全部，如今屬甲骨文公司)。以後不久,網景推出了LiveWire，一種在其服務器（Netscape Enterprise Server）上的JavaScript實現¹。

1996年，微軟推出了JScript，同ie3捆綁發行,JScript在微軟的IIS服務器上一樣可用。

1996年開始,JS語言開始走上規範之路，它已ECMAScript的名字被標準化到ECMA-262規範，規範指定者是ECMA組織下的一個名爲TC39的技術委員會。因爲當時Sun公司不肯意轉讓JavaScript這一商標，雖然微軟願意轉讓JScript這一商標,但卻遭到其它公司成員的反對，所以這一語言的名字就成了咱們熟悉的ECMAScript。

儘管JavaScript和JScript是競爭關係，網易和微軟在當時的TC39標準委員會佔主導地位，委員會仍是取得了大量的成果，向後兼容被設定爲以後標準制定的黃金法則，好比說雖然有了新的嚴格相等運算符===，可是JS同時兼容了非嚴格相等運算符==。

1997年6月ECMA-262的初版發佈，以後一年中，規範依據ISO / IEC 16262國際標準進行了改進，並由ISO認證機構大量審查，1997年6月ECMAScript規範正式發佈第二版。

1999年12月，第三版也發佈了，這一版的規範帶來了正則表達式，switch，do/while,try/catch，Object#hasOwnProperty以及其它的一些改變，同時新增的大部分規範在網景的新版瀏覽器SpiderMonkey中也得以實現。

ES4標準的草案在以後不久就被TC39提出，這一草案直接影響了2000年中期的JScript,.NET等的開發，2006年Flash推出了ActionScript 3也深受其影響。

可是關於JavaScript語言該如何發展，當時的意見很是矛盾，這使規範制定的工做停滯不前。這在Web標準指定史上是一個很是尷尬且奇妙的時刻，當時微軟掌握着主動權，可是它對規範的改進卻沒太大的興趣。

兩年後，隨着火狐瀏覽器市場佔有率不斷增高，就任於 Mozilla 的 Brendan 迫使微軟回到標準指定的議程中。2005年中期開始，TC39委員會又開始了例會。從新開始討論起ES4，他們計劃在ES4中引入模塊系統，類，迭代器，生成器，解構，類型註釋，適當的尾調用，新的數據類型和各類其餘功能,因爲這個工程的野心太大，ES4的制定於是被一而再的延期。

2007年，TC39委員會被迫分爲兩部分，一部分負責ES3的漸進增強版ES3.1標準的制定，另外一部分則負責從新設計改動巨大的ES4標準。2008年8月，ES3.1被認爲是正確的選擇，隨後其改名爲ES5，ES4也隨之被廢棄，不過值得慶幸的是 ES4 提出的不少新功能被融入到了 ES6 ，也有一些功能仍然在考慮之中，另外一些則已被放棄，拒絕或撤回。兼容ES3.1 成爲 ES4 標準提出的功能可能被採納的前提。

2009年12月，ES3發佈10週年後，第五版ECMAScript才得以發佈。這個版本把十年來各瀏覽器中已有的廣泛實踐標準化了，新增了get`set`，改進了數組原型的函數式特徵，原生支持了JSON的解析，提出了嚴格模式。

2011年6月，ES5標準再次修改並改進爲 ISO/IEC 16262:2011標準 的第三版，並以ES5.1的名義正式發佈。

2015年6月，也就是ES5.1發佈的四年後，TC39公佈了JS語言有史以來最大的更新 ES6，其中包含了不少ES4中提出草案。本書，咱們將深刻探索ES6。

ES6的發佈是JS標準制定歷史上的一個重要里程碑。除了數十種引入注目的新功能，ES6 的發佈也標誌着 ECMAScript 標準將持續更新。

持續更新的 ECMAScript 標準

ES3發佈了十年都沒有重大變化，然後的ES6花了四年才得以標準化，TC39的效率確實須要改進了。以前標準的修訂自己是有期限的，可是隻要未達成共識，修訂時間就會被延長，延長的時間裏可能有些功能又有了新的變化，這又致使更多的延遲。

不過隨着ES6標準的指定，TC39的工做流程也流線化了。爲了知足頻繁的需求能持續更新，他們優化了規則的制定過程，爲此，新流程的指定從基於Word轉移到使用Ecmarkup（用於格式化ECMAScript規範的HTML超集）和Github request,這使得提案數量以及非會員參與度都大大提高，新的流程指定過程也更透明瞭，以往你須要從網上下載某個規範的word或pdf說明文稿，如今你隨時能夠經過這個網站看見最新的草案。

如今Firefox，Chrome，Edge，Safari和Node.js的最新版都原生實現了 ES6 規範中超過95％的標準了，可是咱們並不須要等到規範百分百的被支持再使用新語法。在描述如何使用以前，咱們先看看規範指定的幾個階段。

Stage0 ：任何還沒有提交爲正式提案的討論，想法，改變或對已有規範的補充建議都被認爲是一個稻草人草案（「strawman」 proposal），但只有TC39成員能夠提出此階段的草案。
Stage1 ：此階段，稻草人草案升級爲正式化的提案，並將逐步解決多部門關切的問題，如與其餘提案的相互之間會有什麼影響，這一草案具體該如何實施等問題。人們須要對這些問題提供具體的解決方案。stage1的提案一般還須要包括API描述，擁有說明性使用示例，並對語義和算法進行討論，通常來講草案在這一階段會經歷巨大的變化。
Stage2 ：此階段，草案就有了初始的規範。經過polyfill，開發者能夠開始使用這一階段的草案了，一些瀏覽器引擎也會逐步對這一階段的規範的提供原生支持，此外經過使用構建工具也能夠編譯源代碼爲現有引擎能夠執行的代碼，這些方法都使得這一階段的草案能夠開始被使用了。
State3 ：此階段的規範就屬於候選推薦規範了，這一階段以後變化就不會那麼大了，要達到這一階段須要知足如下條件：
- 規範的編輯和指定的審閱者必須在最終規範上簽字；
- 用戶也應該對該提議感興趣；
- 提案必須至少被一個瀏覽器原生支持；
- 擁有高效的ployfill，或者被Babel支持；
Stage4 ：此階段的提案必須有兩個獨立的經過驗收測試的實現，進入第4階段的提案將包含在 ECMAScript 的下一個修訂版中。

ES6開始，TC39每一年都會發布新的規範，新的規範將包含年號，如ES6 別名 ES2015，2016年經過的規範將叫真名叫 ES2016 而非ES7，以此類推。不過對ES6，社區仍是習慣喊其爲 ES6，由於其在新命名規則公佈以前就以被你們熟悉，ES7有時候也會面臨相似的問題，不過以後就會好轉了，咱們以後會說ES6，ES2016，ES2017，ES2018等等。

精簡提案流程和每一年發佈的新版本使得新版標準的發佈得以持續化，不過這也意味着版本號再也不那麼重要了，這也使得如今你們都把精力放在提案上，對參考ECMAScript標準的期待反而變少了。

瀏覽器支持狀況和兼容工具

上文已經說了，只要JavaScript引擎提供了兩個獨立的實現，第3階段的候選推薦方案就很是有可能在下一步中就被歸入規範。實際上，Stage3的提案經過能夠經過實驗階段的瀏覽器解析，ployfill或者轉譯器解析後，通常被認爲是能夠在生產環節中安全的使用。Stage2的提案以及更早的提案也被有些開發者運用到生產中，這使得社區對規範有了更多的反饋。

相似Babel這樣，以代碼做爲輸入，以瀏覽器可識別的HTML，CSS，JS的做爲輸出的工具被稱爲轉譯器，或者轉譯器（轉譯器的子集），當咱們想在咱們的代碼中寫還不是正式標準的語法時，Babel 這類轉譯器能夠幫助咱們，它們能夠把尚不被支持的語法轉換爲目前被瀏覽器普遍支持的語法。

編譯通常在開發階段進行。這使得瀏覽器更早的‘支持了’新的規範，讓JS開發者更早享受到了新規範帶來的好處。同時這對規範的做者和實踐者也大有裨益，他們所以收集到了更多關於規範可行性、可取性，可能的錯誤或邊緣案例的反饋。

使用轉譯器轉譯，是現今在生產環境使用ES6語法的最值得信賴的方案，只須要一個build步驟,咱們的新代碼就能夠被老的瀏覽器成功解析了。

一樣咱們也能夠經過轉譯提早使用ES7甚至更新的語法，新的標準每一年的推出，轉譯器也將會立刻支持ES2017，ES2018等等，與此同時，隨着瀏覽器對新標準的支持度愈來愈高，轉譯器也會逐步減小對ES6代碼的轉譯，ES7的轉譯等等。從這個角度看來，轉譯器起到了鏈接新舊的做用。

Babel如此重要下面咱們談談如何在工做中使用Babel。

Babel轉譯器簡介

Babel能夠轉譯ES6代碼爲ES5代碼，經轉譯的代碼是易讀的，這有助於咱們加深咱們對新語法的理解。

在線的Babel REPL (Read-Evaluate-Print Loop）爲咱們學習ES6提供了很好的途徑，無須安裝Node.js,無須使用 Babel CLI ，在網頁上就能夠實現源代碼的轉譯。

在Babel REPL中咱們只須要在左側輸入代碼，在右側就能夠看到編譯後的代碼，轉譯會自動進行。

在REPL中，咱們在左側輸入如下代碼看看會發生什麼：

var double = value => value * 2
console.log(double(3))
// <- 6

在右側咱們能夠看到編譯爲ES5的結果，以下圖所示，當你更新左側代碼時，右側也會實時更新

學習新語法免不了實踐，REPL就是咱們的練武場，不過須要注意的是，Babel 不能直接轉譯新增的Symbol,Proxy,WeakMap等語法，並不是Babel忽略了這些新特性，轉譯時，若是運行了Babel提供的相關插件，這些語法也能被轉譯，這意味着咱們須要在代碼中引入babel-ployfill。

爲何要這樣呢？

須要額外引入ployfill是由於，老版本的JS中，想要正確執行這些新語法是很難的或者幾乎是不可完成的。polyfills 雖然能夠貌似解決這種問題，可是一般並不能百分百覆蓋全部使用場景狀況，也就是說 ployfill 實際上只是一種折中處理，所以若是咱們在生成環境中使用這類新的語法，就算經過ployfill轉譯了，咱們也應該在正式上線前仔細進行測試。

也所以，對於這些沒法轉譯的新內置語法，咱們最好仍是等瀏覽器徹底支持之後再使用。不過就算暫時不能使用，咱們也仍是應該學習這些新特性，使得本身對JS語言有更深入的理解。

雖然新的Chrome，Firefox，Edge等現代瀏覽器如今已經支持大部分的 ES2015 甚至更新的語法，當咱們使用某個新語法時，瀏覽器的開發者工具很是有用。可是若是生產階段想要使用新語法，咱們仍是推薦你對代碼進行轉譯，這能讓你的app的適用性更廣。

除了REPL，經過Babel提供的一個node.js包，咱們還能夠在命令行中實現轉譯，下面以一個簡單的例子做爲示範：

新建目錄，打開目錄所在位置的終端，並經過npm init 命令實現這個目錄的初始化；

mkdir babel-setup
cd babel-setup
npm init --yes # yes參數使得初始化時採用默認設置

建立一個名爲example.js的文件，在babel-setup目錄下新建子目錄 src,並把這個文件保存其中，在example.js中添加下述內容：

var double = value => value * 2
console.log(double(3))
// <- 6

打開終端工具，輸入如下代碼完成Babel的安裝：

npm install babel-cli@6 --save-dev
npm install babel-preset-env@6 --save-dev

注：經過 npm 指令初始化的node項目，會自動在根目錄新建一個名爲node_modules的文件夾，以後咱們經過npm scripts或經過require語句就能夠在項目中引用這些包

--save-dev 參數會將新安裝的包添加到咱們的package.json配置文件中做爲開發依賴項，當咱們把咱們的項目複製到新的環境中時，咱們只須要經過npm install指令完成依賴環境的安裝。

@標記用以指明安裝某特定版本的包，使用@6，npm 將安裝babel-cli,6.x版中的最新版。這種偏好設置能夠很是有效的在將來保護咱們的應用，永遠不會安裝7.0.0或者更新的版本，這些新版本可能包含咱們在此時開發時沒法預料的重大改變。

接下來，咱們按照下面的方法替換 package.json 文件中的 scripts ，babel-cli 提供的 babel 命令會檢測整個src目錄，把他們轉換爲咱們想要的輸出格式，並存儲在目錄dist中。

{
  "scripts": {
    "build": "babel src --out-dir dist"
  }
}

如今咱們的 package.json 應該是下面這個樣子了

{
  "scripts": {
    "build": "babel src --out-dir dist"
  },
  "devDependencies": {
    "babel-cli": "^6.24.0",
    "babel-preset-env": "^1.2.1"
  }
}

任何寫做scripts對象中的命令均可以經過npm run <name>來執行，它會暫時修改$PATH的值，這使得雖然咱們的babel-cli並未全局安裝，可是也能夠直接運行

咱們在命令行中輸入npm run build命令，系統會自動新建dist/example.js文件，此時的輸出文件會和咱們的源代碼一致，這是由於babel並不會自動給咱們添加配置文件，咱們須要在根目錄建立文件.babelrc輸入下述代碼進行配置

{
  "presets": ["env"]
}

咱們安裝的env 預設 , 會在構建時添加一系列的Babel插件，這些插件能夠轉換不一樣的ES6代碼爲ES5代碼，具體到咱們的 example.js 咱們會看到咱們使用的箭頭函數被轉換爲了 ES5中的普通函數，env 預設依照協議，依據瀏覽器的支持狀況轉換JS代碼，這個預設是能夠配置的，咱們能夠控制須要兼容到哪一版本的瀏覽器。默認狀況下全部的新語法都會被轉譯，以讓咱們的應用有儘量廣的兼容性。

example.js轉譯爲ES5後，代碼以下：

» npm run build
» cat dist/example.js
"use strict"

var double = function double(value) {
  return value * 2
}
console.log(double(3))
// <- 6

下面咱們來講明如何使用另一個很是有用的工具，eslint，它能夠依據某個基線標準，幫助咱們改善代碼質量。

使用ESLint改善咱們的代碼質量並保證一致性

隨着應用逐步複雜，咱們的代碼量會愈來愈多，這同時會帶來不少問題，一些代碼多是多餘的或再也不那麼有用，咱們須要寫新的代碼，刪除一些再也不相關或必須的特性；運用新架構也可能也會須要調整代碼位置；可是隨着項目的擴大，開發人員也隨之增多。

lint工具能夠用於識別語法錯誤，現代的lint工具也經常是可自定義的，經過抽象團隊成員的意見爲編碼樣式規則，以合適的配置使用linter工具，能幫助團隊構建一種對每一個人適用的一致的編碼風格。

除了確保程序能夠正常運行，咱們可能還但願防止throw語句拋出異常，在生產代碼中不容許出現 console.log 和 debugger 等語句。這些均可以經過lint工具來實現。

儘管linter在定義和實行編碼風格方面是有效的，可是咱們也應該當心定義規則，若是定義的規則過於嚴格，開發人員可能會沮喪到影響開發效率，若是過於寬鬆，則又難以維持代碼的一致性。

ESlink是一個具備不少插件的現代linter工具，它支持衆多規則，並容許咱們挑選須要的規則去遵照。經過配置能夠實如今沒有準守這些規則時會在輸出中打印出警告語句或者錯誤。

使用npm 能夠完成eslint的安裝：

npm install eslint@3 --save-dev

接下來，咱們對ESlint進行基本配置 , 因爲咱們的eslint並不是全局安裝，咱們能夠在node_modules/.bin文件夾下找到對應的命令行工具。執行下面的命令行命令將引導咱們完成對項目的首次配置。在這裏，咱們選用standard以選用流行風格，並配置配置文件爲JSON格式:

./node_modules/.bin/eslint --init
? How would you like to configure ESLint?
  Use a popular style guide
? Which style guide do you want to follow? Standard
? What format do you want your config file to be in? JSON

除了我的風格，eslint容許咱們拓展預約義的風格，這些拓展都以node.js的包呈現。在選擇standard風格後，咱們會發現ESlint添加了一些依賴項到package.json中，它們是預約義標準風格的所依賴的包，eslint還在根目錄下，建立了一個名爲.eslintrc.json的配置文件，以下所示：

// .eslintrc.json
{
  "extends": "standard",
  "plugins": [
    "standard",
    "promise"
  ]
}

在命令行中使用命令時還要帶上node_modules/bin這樣的路徑感受很很差，爲了解決這個問題，咱們把lint命令也添加到package.json中：

{
  "scripts": {
    "lint": "eslint ."
  }
}

也許你還記得，npm run會臨時把node_modules目錄添加到$PATH中。如今當我想lint咱們的代碼時，輸入npm run lint就能夠了，npm會自動找到對應的包。

仍是以example.js文件爲例，這個文件目前存在一些樣式問題，咱們看看ESLint的效果如何：

// 樣式不對的expamle.js
var goodbye='Goodbye!'

function hello(){
  return goodbye}

if(false){}

當咱們執行lint腳本，ESlint會列出這個文件中的全部問題，以下：

若是咱們在執行上述命令的時候添加參數 --fix，eslint會爲咱們修復大部分的問題，咱們修改package.json以下

{
  "scripts": {
    "lint-fix": "eslint . --fix"
  }
}

當咱們執行 lint --fix的時候，咱們會發現如今的錯誤只是說 hello 從未使用過，false是一個不變的狀態，其它的問題都被修復了，修復後的代碼以下。

// 修改後的example.js
var goodbye = 'Goodbye!'

function hello() {
  return goodbye
}

if (false) {}

--fix的參數是咱們解決代碼風格問題時的有效幫手，可是也不用擔憂它會攪亂咱們的程序，ESlint只會修復該修復的部分。

prettier是另外一個相似的工具，它會自動規範化咱們的代碼，當咱們給定固定的規則，如空格數，使用單引號仍是雙引號，尾逗號，以及一行最大長度時，prettier會實現咱們的代碼的自動重寫。

讀到這裏，你已經知道了如何轉譯現代的JS爲瀏覽器廣泛支持的JS，也知道了如何合適的使用lint來規範代碼，下面咱們瞭解一下本書的結構。

ES6中的新特性

ES6改動很是大，這從規範的頁數就能夠看出，ES5.1 258頁，ES6 566頁。總的來講新增的規範能夠劃分爲如下不一樣類別：

語法糖
新機制
更好的語義化
更多內置的方法
現存侷限方法的非破壞性解決方案

語法糖是ES6全部改變中最重要的一塊，class語法可簡潔的構建對象實例，支持使用箭頭函數，簡寫的對象屬性方法，解構，剩餘值，和拓展，等提供語義良好的編寫程序的方法。第二章 [ES6 Essentials and Classes, Symbols, Objects, and Decorators]()將討論 ES6 的這些新特性。

ES6爲咱們提供了幾種控制異步代碼流的機制：包括可靠的promises，表徵一系列值的iterators，特殊的iterators--> generators。基於這些新概念,ES2017還有了了async/await語法，讓咱們以同步的方式來書寫異步代碼。在[Iteration and Flow Control]()一節中，咱們將詳細敘述各類新機制。

ES6提供了一些新的內置類型來管理set和map,這些新類型不具備僅使用字符串鍵的限制，這一部分，咱們會在[Practical Considerations]()這一節中進行系統的描述。

Proxy對象從新定義了咱們經過JavaScript reflection能夠作什麼，Proxy對象相似於其它上下文中的代理。能夠用以修改與JavaScript對象的任何交互，如定義、刪除或訪問屬性。考慮到代理對象的工做機制，他們不能完全經過ployfill實現，事實上相關的ployfill也是存在的，可是因爲存在侷限性使得他們在某些方面與規範有所不一致。咱們將在[ Managing Property Access with Proxies]()這一節完全理解代理對象。

除此以外，ES6對Number,Math,Array和string等都進行了更新，提供了新的api。在[Build-in Improvement in ES6]()這一節，咱們將經過大量的示例來實踐這些api。

ES6還在語言層面上爲咱們提供了模塊系統，[JavaScript Modules]()一節裏，咱們將講述JS的模塊系統。

考慮到ES6的改動之大，咱們很難用咱們現有的JS知識理解全部的新特性，[ Practical Considerations ]()一節咱們會分析各ES6特性的優勢和重要性，以便你對ES6有一個更加系統的理解。

JS語言的將來

誰也想不到出生如此卑微的JS語言，今天的應用會如此廣，它改變巨大，ES6就是這變化過程當中的一大步，固然這確定不是終點，考慮到標準每一年都會更新，學會如何和最新標準保持一致很是重要。

前面咱們已經說明了，ES是一個持續更新的標準，最好的學習新標準的方法是週期性的瀏覽TC39的建議庫，尤爲要注意瀏覽處於stage3階段的提議，這些極可能就是以後的標準。

另外一些跟上進度的方法是，訂閱每週電子郵件，和閱讀JavaScript的博客。

在寫本書的時，等待已久的Async Functions 提議已經定於在ES2017中發佈。同時還有一些處於候選階段的提議，好比動態import()，這容許異步的加載本地JS模塊，還有一個建議用ES6中的rest和 spread語法對對象屬性進行枚舉。

儘管本書主要將討論ES6，咱們也會學習一些重要的候選方案，如以前已經說起的async functions,dynamic import()，calls以及對象的 rest/spread和一些其它的屬性。

參考文獻

A booklet from 1998 explains the intricacies of server-side JavaScript with LiveWire.
You can read the original announcement at the Microsoft website (July, 2000).
Listen to Brendan Eich in the JavaScript Jabber podcast, talking about the origin of JavaScript.
You can read a news report from The Mac Observer, July 2003.
Brendan Eich sent an email to the es-discuss mailing list in 2008 where he summarized the situation, almost 10 years after ES3 had been released.
For the full set of changes made when merging the Web ECMAScript specification upstream, see the WHATWG blog.
Check out the presentation 「Post-ES6 Spec Process」 from September 2013 that led to the streamlined proposal revisioning process here.
Check out all of the proposals being considered by TC39.
Check out this detailed table reporting ES6 compatibility across browsers.
Take a look at the TC39 proposal process documentation.
You can track strawman proposals.
Note that Standard is just a self-proclamation, and not actually standardized in any official capacity. It doesn’t really matter which style guide you follow as long as you follow it consistently. Consistency helps reduce confusion while reading a project’s codebase. The Airbnb style guide is also fairly popular and it doesn’t omit semicolons by default, unlike Standard.
Check out all of the proposals being considered by TC39.
There are many newsletters, including Pony Foo Weekly and JavaScript Weekly.
Many of the articles on Pony Foo and by Axel Rauschmayer focus on ECMAScript development.