1)Node.js版本變化
https://github.com/nodejs/LTS#lts-schedule
- 發佈Node.js 6.x 並進入LTS(長期支持版本),凡是LTS的都可以在生成環境使用
- 發佈Node.js 7.x 支持Async/await,儘管需要加flag纔可以開啓
根據node.green統計Node.js 6.x(LTS下面)的es 2015即es6兼容99%
-
- DevTools Inspector Integration
-
- Capture Names of Listeners on an EventEmitter
-
- Overhauled Buffers Constructor APIs
-
- Unhandled Promise rejection warnings
-
- Quick and Safe Temporary Directory Creation
-
- Timing Attack Prevention
-
- Process Warnings API
-
- Symlink Preservation
-
- V8 Performance Profiling Directly Through Node.js
-
- Process CPU usage
2)Node.js在2016年被哪些企業使用?
- 高朋使用Node.js重建了整個Web層
作爲決策的結果,高朋團隊使用Node.js重建整個Web層
他們在多個平臺使用Node:
- 大概3-400個後端服務使用Nde.js Java和Ruby混合
- 使用Node作爲API集成層。
- 使用Node作爲後端服務的客戶端,包括網站。
當前,高朋有70個Node.js生產應用。應用在30個國家。
- Node.js在Skycatch應用
skycatch是家數據公司,幫助捕獲、管理和分析商業無人機數據。skycatch看到挖掘數據需要大量查詢數據庫。使用現有的工具如原始SQL查詢是困難和耗時的,而skycatch的解決方案可以方便地從網站中提取可操作的數據。
“我們在你能想得到的地方都使用了node - Node是我們的膠水”。
- Node.js在Lowe’s Home Improvement 應用
通過Node.js,工程師隊可以擁有從UI到後端整個堆棧的全部開發職責,前端他們能夠重用自己在JavaScript和HTML上的精通。
現在他們可以很快地把新的功能放一起做原型設計做研究和做一些用戶測試。然後把這個想法應用到生產級別併發布,不會導致應用程序棧其他部分的風險
原文http://www.jdon.com/48441
上面是國外的一些,據我所知很多大公司都用Node.js只是沒人出來講而已,創業公司就更加數不勝數了。
調查一下,用Koa的公司來頂一下 這個帖子,7個月之前,統計Koa都很20家左右,所以整體來看,普及力度還不錯的。
3)left-pad事件
2016年3月份,kik是Azer寫的模塊,但Kik同時是手機通信錄的社交軟件,所以這個社交軟件上就無恥的直接說讓Azer把kik名字給他們,Azer不同意,他們就拿律師函恐嚇,並讓npm妥協,所以npm就妥協了
Azer一怒之下將自己在 npm 上的 273 個封包全部撤下,其中就包括 left-pad 封包。一石激起千層浪,依賴 left-pad 的上千個項目包括 babel 和 react-native 瞬間崩潰。大量開發者看着自己項目構建失敗,頓時被嚇尿。
觀點
-
1)就沒見過這麼傻逼的公司,一個紅包就能解決的事兒,非要用強權,如果對方在改模塊上耗費心血少的話,轉給你也沒啥問題的。去年百度從我手裏要走了一個模塊,一個紅包而已
-
2)11行代碼要不要封裝成一個包?
sindresorhus: Containing complexity is not about putting everything in one-line functions/modules.
你的模塊必須含有一定的複雜性,不然就沒啥意義了。
- 3)npm看着那麼多包,大多數都是無意義的吧?
從我開始講Node.js全棧大約是3月份,那是npm上是25.6萬個吧,截止到年底是35萬個,我想說的是那個包倉庫都是有好有壞,按照80/20原則,數量是也是相當可觀的。總比那些某些語言連包管理機制都不完善的要強吧!
- 4)結果npm調整了撤銷策略,24小時之後就不讓撤銷了
If the version is less than 24 hours old, you can unpublish it. The package will be completely removed from the registry.
http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
4)Yarn:一個高效的npm替代品
2016年10月份, Facebook 和 Google 聯手搞出 Yarn,你一個新的包管理器。一週之內,在github上star過萬,現在已經21843個star了。
替換的原因
- 在Facebook的大規模 npm 都工作的不太好
- npm拖慢了公司的ci工作流
- 對一個檢查所有的模塊也是相當低效的
- npm被設計爲是不確定性的,而Facebook工程師需要爲他們的DevOps工作流提供一直和可依賴的系統
與hack npm限制的做法相反,Facebook編寫了Yarn
- Yarn 的本地緩存文件做的更好
- Yarn 可以並行它的一些操作,這加速了對新模塊的安裝處理
- Yarn 使用lockfiles,並用確定的算法來創建一個所有跨機器上都一樣的文件
- 出於安全考慮,在安裝進程裏,Yarn 不允許編寫包的開發者去執行其他代碼
Yarn, which promises to even give developers that don’t work at Facebook’s scale a major performance boost, still uses the npm registry and is essentially a drop-in replacement for the npm client.
很多人說和ruby的gem機制類似,都生成lockfile。確實是一個很不錯的改進,在速度上有很大改進,配置cnpm等國內源來用,還是相當爽的。
5)Chrome DevTools支持Node.js 應用調試了!
https://blog.hospodarets.com/nodejs-debugging-in-chrome-devtools
要求
-
- Node.js 6.3+
-
- Chrome 55+
步驟
- 開啓chrome://flags/#enable-devtools-experiments URL
- 啓動 Developer Tools experiments flag
- 重啓 Chrome
- 打開 DevTools Setting -> Experiments tab (重啓之後的才能看見)
- 按下 “SHIFT” 6 次
- 選中 “Node debugging” 複選框
- 打開/關閉 DevTools
https://blog.hospodarets.com/nodejs-debugging-in-chrome-devtools
另外推薦一個electron包裝的devtool,也非常好
https://github.com/Jam3/devtool
6)lerna:一個用戶管理多個包模塊的工具。
非常好用,babel等都大量應用
7)Flow和Typescript越來越流行
Flow 是一個新的開源JavaScript靜態類型檢查器給JavaScript增加了靜態類型來提高開發人員的生產力和代碼質量。特別是,靜態類型提供了一些極大的助益,如前期錯誤檢測,它可以幫助您避免某些種運行時故障;如代碼的智能提示,這有助於代碼維護、導航、轉換和優化。
TypeScript是JavaScript類型(es6)的超集,它可以編譯成純JavaScript。可以在任何瀏覽器、任何計算機和任何操作系統上運行,並且是開源的。類型檢查啊也是非常棒的。
由於大規模和深度js應用,導致js編寫複雜性越來越高,而且又要多人合作,所以對於靜態類型的需求會尤其大,flow相對更加輕量級,ts更加像一攬子解決方案。以我的觀察,flow就是react這陣風帶起來的,喜歡輕量級的可以考慮,長久來看,ts可能會有更大的發展潛力。我相信在2017年ts會有更好的成長,無論是前端,還是Node.js,都會大量應用。
8)異步流程演進
這裏加異步流程演進部分,目的是爲了後面講述框架變化做鋪墊,同時異步流程控制也是Node.js非常核心的內容,是每個開發者都必須掌握的。
JavaScript流程控制的演進過程,分以下6部分:
- 同步代碼
- 異步JavaScript: callback hell
- Thunk
- Promise/a+
- 生成器Generators/yield
- Async函數/Await(以前說是ES7 stage-3)
看起來挺簡單的,作爲*js(沾邊)工程師的各位自測一下,當前是哪個階段?
我對異步流程控制的總結
- Async函數是趨勢,如果Chrome 52. v8 5.1已經支持Async函數(https://github.com/nodejs/CTC/issues/7)了,Node.js已經支持,Node.js 7.x版本需要加flag才能開啓,在明年的8.x裏會默認開啓。
- Async和Generator函數裏都支持promise,所以promise是必須會的。
- Generator和yield異常強大,不過不會成爲主流,所以學會基本用法和promise就好了,沒必要所有的都必須會。
- co作爲Generator執行器是不錯的,它更好的是當做Promise 包裝器,通過Generator支持yieldable,最後返回Promise,是不是有點無恥?
我整理了一張圖,更直觀一些。
- 紅色代表Promise,是使用最多的,無論async還是generator都可用
- 藍色是Generator,過度貨
- 綠色是Async函數,趨勢
結論:Promise是必須會的,那你爲什麼不順勢而爲呢?
推薦:使用Async函數 + Promise組合,如下圖所示。
9) vsc是一個比較潮比較新的編輯器
(跨平臺Mac OS X、Windows和 Linux )
- vsc功能和textmate、sublime、notepad++,ultraedit等比較,毫不遜色
- vsc尤其是在nodejs(調試)和typescript、go上支持尤其好
- vsc提供了自定義 Debugger Adapter 和 VSCode Debug Protocol 從而實現自己的調試器
vsc的宣傳語是:
一個運行於 Mac OS X、Windows和 Linux 之上的,針對於編寫現代 Web 和雲應用的跨平臺源代碼編輯器。
按它說的,vsc特別適合來作爲前端開發編輯器。
內置html開發神器emmet(zencoding),對css及其相關編譯型語言Less和Sass都有很好的支持。
當然,最nice的還是寫js代碼了,這也是我接下來要着重介紹的功能。
目前vsc已經開源了:
- 代碼https://github.com/Microsoft/vscode
- 官方博客http://blogs.msdn.com/b/vscode/?Redirected=true
- roadmap https://github.com/Microsoft/vscode/wiki/Roadmap
- 支持go語言 https://github.com/Microsoft/vscode-go
Node.js 的應用場景
Node.js能幹什麼?
- 網站(如express/koa等)
- im即時聊天(socket.io)
- api(移動端,pc,h5)
- http proxy(淘寶首頁)
- http proxy延伸,組裝rpc服務,作爲微服務的一部分
- 前端構建工具(grunt/gulp/bower/webpack/fis3…)
- 寫操作系統(NodeOS)
- 跨平臺打包工具(nw.js、electron、cordova/phonegap)
- 命令行工具(比如cordova)
- 編輯器(atom,vscode)
前端工具
先區分2個概念:Web Server和Application Server
- Web Server
當Web Server接收到一個HTTP request的時候,它會以HTTP response的形式相應這個請求,也就是返回一個HTML頁面, Web Server可以響應一個靜態的HTTP頁面,也可以轉發或者代理請求到其他的服務端腳本引擎(CGI, JSP或者ASP、PHP、Node.js等等),然後返回一個動態的相應。不管以什麼樣的服務端技術, Web Server大多說情況都只是以HTML德形式返回一個HTTP響應。
- Application Server
根據Application Server的定義, Application Server是爲客戶端應用提供業務邏輯,它與客戶端應用的交互可以通過多種協議,其中也包括HTTP協議, 一個Web Server主要是處理HTTP請求,發送HTML到瀏覽器,而Application Server爲客戶端應用提供了訪問業務邏輯的接口。客戶段應用可以像調用一個對象的方法一樣調用這些業務邏輯。
使用Node.js做Web Server
apache、nginx等http server,主要提供靜態http服務和反向代理
- 靜態文件託管,比如js、css等,效率會比較高
但有一個問題,如果你期望的文件要處理header或者其他變態請求,nginx就沒法給你處理(nginx + lua也是可以,但比較麻煩),這是使用Node.js的server就會非常好用。
純http來看,nginx和node能夠的功能是非常類似的,我們做的最多的是nginx擋在node前面,所以很多人都不太清楚這個點。
使用Node.js處理靜態資源,單機過億次是輕輕鬆鬆的。
使用Node.js做Web Server
這就是我們大部分理解的Node.js作用。動不動就Express或Koa,連接數據庫crud等
proxy 2種
反向代理
反向代理功能同nginx,這裏不細講,Node.js也有模塊可以完成一樣的功能,如果會Node.js比玩nginx要簡單
應用層面的代理
比如淘寶基於Node的前後端分離
這裏的Node.js服務
- 1)對接前端,給前端渲染提供數據
- 2)抽象了model proxy,用於完成各種接口對接
一般大型網站都會非常複雜,做個了很多版本升級、重構,那麼必然會慢慢的向服務化靠攏,無論是SOA還是微服務,都會提供非常多的服務,而且各種協議都有,那麼你的前端要怎麼處理呢?
放到前端來說,肯定是不好的,所以比較合理的方式就是在服務和前端直接,增加Node.js作爲代理。
我希望在2017年這個地方能夠做的更好
- 服務組裝(rpc)
- bigpipe
- server-side render
如何做框架選型?
Node.js從2009橫空出世之後,至今已經7年有餘,各種web框架也林林總總,目前大約在npm上有35萬左右包,刨去前端和一些無意義的封裝,也是有非常可觀的優秀的模塊的。其中web框架也是特別搶眼的,從早期的express到現在koa,對異步流程控制的改進前仆後繼。隨着移動端崛起面向api的框架hapi和restify也如火如荼,更有一些面向特性的框架,比如thinkjs對es6/es7/typescript支持,整體來說,質量都是非常不錯的,算百花齊放,還是那句話,即使不優化,你也能用這些框架獲得較高的性能。
很多人都爭論這個問題,不同的leader也有不同的解決方案,那麼,如何做框架選型呢?我總結了一下,大概有3個決定因素
- 場景,是做api還是管理後臺,還是h5,不同的應用場景會有不一樣的選擇
- 團隊能力,如果團隊Node.js經驗非常豐富就無所謂,如果不是特別熟,那就至少要有一個人能cover住,如果都沒有,那就挑選最成熟的最保守的做吧
- 趨勢,如果leader大局觀不錯,綜合上面2點,再輔以趨勢的話,就非常好,畢竟現在技術革新太快,別你剛學會,別人都不用了,也是比較痛苦的。
無論如何,至少要有一個人能cover住,這是我選型的根本,框架再好,也不是給你設計的,所以難免會各有各種各樣的問題,那麼你就只有一個選擇了
f**k = fork or fuck
要麼fork了自己改,要麼what the fuck。。。
Node.js 2017 展望
- 前端工具類繼續作爲基礎設施普及
- 會出現更多爲js的全棧程序員,前端水平會有質的提高,也會甩掉一批人
- 作爲Proxy,服務組裝部分,應該可以再拿下一部分
- 大量普通Typescript
- 異步流程控制方面,普及Async,但會有相當長的一段時間是 普及Async + Promise共存
- 期待Node.js 8.x版本,完美支持Async/await
- Koa 2.x以及基於Koa 2.x的async版本普及
- 如果可以,Node.js能夠在cup密集任務方面有提供就更好了
爲什麼Node.js還會繼續火
-
- 蹭一波ssr + pwa熱潮,node是大前端(泛指各種view層相關技術)最佳拍檔
- 2)性能差不多的情況下,看的就是喜好,js基數大node就用戶量就非常大,簡單粗暴獲得一個相當不錯的性能
- 3)目前在proxy層基本普及了,但向後端和微服務部分還有很大發力空間,io密集的後端必有一席之位