為什麼Node的web端框架express和Koa的生態環境差距還是巨大（2017.11）？
現在Node也進入了9.0.0時代， 各種平台對es2016+的支持都好了很多，而koa的寫法很明顯是好於express的，而且更加簡潔，但為什麼express和koa的生態依然差距很大？
npmjs上express和koa的對比，前者express，可以看出差距是非常大
更不要談兩者的各種中間件的生態差距了（express各種插件用的人遠遠大於koa常見中間件，如koa-route）
另外， 兩者在GitHub上的star也幾乎是兩倍的差距。
這些數據能說明什麼，為什麼現在還有很多人使用express而不是koa？
Koa 的下載量和 Express 的下載量差距很大，並不意味著 Koa 的生態完善程度和 Express 也有這麼大的差距。其他回答也提到，社區許多前端的 server 工具通過 Express 開發，由於依賴 Express 的第三方模塊眾多，所以 Express 的下載量也非常巨大。為什麼會這樣的原因我猜測主要有兩點：
- 先發優勢，Express 更早出現，而且從可以實現的功能上來說 Koa 並沒有優勢。非同步編程體驗的提升並不能提供足夠的動力讓社區將老項目遷移到 Koa 上。
- Express 版本支持的更廣泛，Koa 1 依賴 Generator Function，在它剛面世的時候甚至要通過 flag 開啟。
可能從 Koa 開始寫的第一天起，TJ 包括 Koa 的維護團隊就並沒有想過讓 Koa 比 Express 更熱門，Koa 和 Express 基本由同一撥人開發和維護，也基於同樣的思想，所以在我看來 Koa 和 Express 其實是同一個框架，我們再來理一下 Express + Koa 的演化過程：
- Express 誕生之初，底層還有一個 connect 框架實現經典的中間件模型，Express 則在它的基礎之上完善了路由和一些常用中間件，實現了一個功能相對完整的 Web 框架。
- 後來 Express 去除了 connect 依賴，將中間件模型放到 Express 中實現，並去除了所有常用中間件（單獨模塊維護），僅保留了路由功能。由於這些常用中間件均從 Express 中獨立出來，所以有官方欽定了一大堆中間件的感覺。
- 在 node 0.11 引入 Generator Function 特性之後，TJ 實現了 co 基於 generator 的控制流工具，可以在 Async Function 還未落地時即可得到類似的非同步編程體驗。然而這是一個顛覆式的改變，它完全推翻了 node 社區自誕生以來的 callback 編程習慣，很難在 Express 的新版本上使用，否則對 Express 的社區也是個很大的震動。因此 TJ 另起爐灶，重新開發了 Koa，沒有歷史包袱，Koa 相比於 Express 更加精簡，僅僅實現了基於 co 的中間件模型以及對 HTTP 請求對象的抽象，連路由功能都交由社區實現。當時 Koa 與 co 依賴的 Generator Function 特性還需要通過 flag 打開，而又恰逢 io.js 和 node 之爭，node 社區的動蕩導致 Generator Function 遲遲難以落地，願意嘗試 Koa 的人更加稀少，可以說這個階段的 Koa 必定是小眾產物。
- 隨著 io.js 和 node 的合併，ES 規範推進越來越快，babel 也越來越成熟，Async Function 的非同步編程解決方案也慢慢的被更多開發者知曉，Koa 底層的中間件模型經過一次重構，從 co 遷移到了 Promise，給 Async Function 做準備，發布了 Koa 2。從此 Koa 社區處在兩個版本長期共存的境況。一方面 Koa 2 支持 Async Function，但是 node 並未支持，需要通過 babel 轉譯，而 Koa 1 提供的 Generator Function 編程體驗和 Async Function 相比並無太大差異，許多開發者並不願意將服務端代碼通過 babel 轉譯後運行（收益並不明顯）。而兩個大版本並存導致社區的中間件維護者也左右為難，很多中間件不得不維護兩個版本。
- 在 node 8 發布之後，Async Function 終於正式在 LTS 版本中落地，從此 Koa 1 和 co 慢慢要退出歷史舞台了，egg 基於 Koa 2 的版本也開始開發（今天已發布第一個 beta 版本）。相信統一之後 Koa 的社區也將會迎來一個快速發展期。
了解來 Experss 和 Koa 的發展史，其實也不難理解為什麼 Koa 到今天為止和 Express 相比仍然有相當大的熱度差距了。有意思的是，最近 hapi.js 的作者 Eran Hammer 也發布了一篇文章，他在計劃基於 Async Function 開發一個新的框架 Kevin。文章中也描述了當時 Express 和 Koa 遇到的場景，有興趣的同學可以看看他的思考。
另外，上面打了這麼多字，其實我只是想說：如果大家對 Koa 或者 Node.js 很感興趣，不妨來 螞蟻金服-體驗技術部，我們一起搞 Node.js！簡歷請郵件 busi.hyy@antfin.com ！
1，都是 TJ 寫的。
2，都是 TJ 撒手不管的。3，都是社區驅動，熱心的接班人無償貢獻著。
4，express 有過黑歷史；國內大神都願意給 koa 出謀劃策，寫生態，tj 偶爾過來點贊。cnodejs 前十名都是多談 koa 少談 express。5，用 koa 的node新手比express少，用koa的後端開發比express多。(個人感覺)注，個人用 koa，不管開發 demo 還是用於生產。npm下載量差了40多倍，這其中很大一部分原因是一般用的開發伺服器，比如webpack-dev-server依賴了express，這種裙帶關係使得下載量相差巨大。在本身龐大的體量下，即使star比express差了一半，但koa社區依舊也很完善。
前兩年知乎上還遍地是前端抱怨後端不思進取，不願用新的框架。
現在一部分前端也開始寫後端，才發現現實所迫，原來不用新東西有的時候真的不只是因為懶得學。哈哈哈，長大了我就變成了你。koa 解決的是一個弱需求，強需求的解決辦法多的是，並不是非koa不可。
基於框架的產品開發，複雜度全在業務上，koa框架原生的優點在業務層上並不明顯，雖然普遍覺得寫業務很low，不過這一塊卻是實在的最大的需求。
以callback hell為例，職責（例mvc,各中間件）劃分清晰後，跨職責間的callback，只需一次，框架內部非暴露的 callback，再深也和大多數的開發人員無關，引包，用包，會從包里找信息，碰到問題，能適當定製包源碼，對大部分功能性產品的開發足夠了（npm的生態，很多包的應用，根本沒有文檔，得自已從測試用例，源碼里找，這是很多語言生態通病，強類型的語言，沒文檔的，但看代碼提示邊猜邊試，有疑問直接跳到實現確認，js的語法提示很弱，還都是猜的，現在有tsd稍好了一些）
真正的痛點是業務層的各種數據、交互、io 的依賴，流控，眾多開發人員所見的callback hell在這裡。
es2016+的 feature，並不只是koa才能用，基於express 的項目，express只保留框架本身的淺層 callback，業務層，怎麼換花樣寫都無所謂，別說es2016+了，typescript 寫的更順溜（我從 async、promise，換到 co，又換了typescript，還在es5的時候，typescript就已經支持async/await了，不為別的，就為了早早用上async/await）
以開發功能包的思路,typescript還是es2016+之類寫個業務層的功能包(可以只是抽象的一個概念)，express寫兩行配置（需要動的那點代碼已經和改配置文件差不多了），相關功能，引業務包作一層調用就完事了，90%的工作量在包的開發上，koa相對 express 只是在剩餘10%上的提升，相對而言，並不重要。
再者expree的較複雜的一些歷史項目，功能上會依賴部分 express 的中間件，這些在 koa 需要另外找替代，或自造輪子，既然是老項目，說明有一定穩定性，生命周期也處於維護階段，改變意味著成本（加班）和風險（背鍋），強行遷移，付出和回報完全不成比例
————————————
當然，新開的項目，會以 koa 來寫，倒不是非他不可，只是要與時俱進。
一群鳥中總有一兩隻愛叫喚，讓人覺得鳥都愛叫喚。程序員中也有各色各樣的，有的就愛追求新鮮語言和框架。但這並不代表沉默的大多數。
語言/框架本身的優勢、社區、文檔、積累、名望、PK等等因素決定了其流行程度，編程技術一方面沒有一招鮮，百花齊放是正常形態，另一方面若無顛覆性的鮮明優勢就不要想徹底擊潰對手。
express出現的比較早，那幫使用express的程序員，早已經開枝散葉，而程序員界都有個共性，就是普遍不願意學習新的框架去完成相同的事情。
如果koa能夠有新的突破功能，比express做到更強大的事情，我想會有更多的express工程師轉投koa的懷抱。
express穩定型的項目比較多，而且後端項目需要穩定，通常不會去用koa重構。koa更多是新入行的工程師在體驗。當然，歷史告訴我們，未來是屬於年輕人的。
為什麼python2都快EOL了，大部分流行項目都還沒遷移到python3的意思？
為什麼c++17都出來了，大部分人連c++11特性都不用？
為什麼java都出到9了，好多項目還死守著java6？（甚至在甲骨文EOL後自己拉分支出來繼續維護jdk6）
：）
你牛逼，幾百萬行幾千萬行代碼你去遷移啊。
因為沒有好到要換。就像很多人問為什麼C# 3.0都出了快10年了，寫了40年的Word不在第30年的時候整個用C#重寫一遍來證明.net的品質一樣。
因為太多項目無法遷移，換一下成本太大換koa後所有中間件都要跟著換，可是並不是所有中間件koa社區都有，比如webpack的熱載入插件在Github本來星就很少 找起來用起來心裡總覺得有點不放心，其實沒有任何區別。還有類似passport這樣的中間件，官方推薦的只有express的，koa的是個個人寫的，你是否會考慮官方的更可靠？所以改變世界的不是新技術，而是用技術做出的產品，產品需要什麼，當然是穩定性。
Koa 的大客戶阿里，內部用的應該是 cnpm，不然可以加一個數量級
謝邀
感覺樓上說的已經差不多了，一個是因為很多用 express 的場景都是微服務，或者是 dev-server 這樣簡單的場景，或者作為別的語言後端的輔助，業務邏輯不複雜，使用 express 也不會很困擾。另一個是已經存在的項目沒有很大的動力去重構成 koa 的，比如都快 2018 了 Python2 還是主流呢（笑）
但是沒有任何理由新項目不用 koa，現在 koa 的生態環境已經成熟了，express 有的中間件 koa 基本都有，即使偶爾遇到沒有的，把一個 express 中間件包裝成 koa 中間件是非常輕鬆的事情，如果說腳手架的話，koa 也有 eggjs, thinkjs 之類的大廠開發的框架，論開發範式 koa 的舒適程度遠超 express。
謝邀。
一樣東西出現得到，而且挺好使，那另一樣東西想超越它就不能只是好一點，而是要優越很多，因為已經有很多投入在前一樣東西上了，換一樣東西無論學習成本還有legacy code都是麻煩。
我個人觀點，koa當然不錯，但是相比express並沒有無可替換的優勢，要搭一個小project我也會先想到express，反正code也不多。流行不全跟質量成正比，還跟歷史存量、發起人影響力等有關
koa真沒比express優秀多少。。。
koa1 基於generator的寫法，真沒覺得哪裡好。。。
koa2基於async的寫法倒是不錯
我比較反感用generator來做非同步，但非常喜歡async，所以koa1註定是一個過渡產品，過渡產品。。。
然而async的兼容性啊。。。生產環境，誰沒事升級node玩。。。所以啊再等幾年吧O(∩_∩)O哈哈~
我預言：koa2會大放異彩
那為什麼不能認為express比koa做的好呢，就因為koa函數執行模型特殊，支持語法糖多？koa的生態圈感覺放養心態，如果koa要實現express全部功能，N多模塊要搜索，要校對版本號，要看issue,找吐血的節奏，而且有些模塊是停滯狀態。
因為 2014 年，TJ 退出了 Node.js 社區……
這兩個框架都是 TJ 做的，TJ 把 Express 做到很成熟了之後才開始做 Koa，Koa 還沒到 1.0 的時候 TJ 就宣布退出 Node.js 社區了。
TJ 一個人就是一個生態你曉得伐？
你對 TJ 的代碼輸出效率一無所知！TJ 的戰鬥力是以噸來計算的！
所以，Koa 比不過 Express 咯。
expressjs/express
koajs/koa
沒有 TJ，就沒有生態~（蛤蛤）
其實還有個哈啤
hapi.js在國內用的不多,我來稍微安利一下
hapi.js(讀音是應該是happy js~~)是由walmart(沃爾瑪) 技術團隊開發的web框架，在 black friday的搶購服務中，表現優異,根據核心團隊的回答,使用了10 CPU cores 和28GB內存，比較輕鬆的抗住了Black Friday的流量。
國內用的人非常少。。但是我們公司大佬非常看好它
hapi的特點還是比較鮮明的
以配置為核心.代碼可讀性很好,不過有時配置太多,記憶負擔有點重,做好代碼的管理,以備以後copy paste以request生命周期的各種拓展點（extension points）來縱向拓展server的功能,大部分的插件都是基於這些ext points.這和express的中間件機制很不一樣server在緩存,驗證,監控管理等方面都有考慮,配合官方的插件,算得上是 battery ready的框架
大部分老代碼都是經過評審，測試，生產環境長時間驗證的，重寫談何容易。對於新代碼來說，拍板上新技術的風險也要遠高於用成熟的技術，人好招，基本上可能碰到的坑都已經有人趟過了，各種周邊相關的工具，庫也都比較完備。
因為我剛學nodejs的時候官方提供的就是express框架啊，在沒有巨大差距推動的情況下我為什麼要換呢？ 要知道kotlin被android官方定為標準開發語言到現在開發android還是java為主，巨大的慣性作用下沒那麼容易變革的。
推薦閱讀：