es6用於web前端(非node後端)是不是還太早了？

12-31

我最近寫了一個canvas庫https://github.com/ErosZy/Moco，除了排遣自身寂寞外順便熟悉一下es6的語法。這個庫用es5語法寫uglify壓縮後整體為20多kb，但換為babel+browserify後儘管壓縮都有130多kb。對於在注重大小的web端，感覺確實太尷尬了，目前的es6是不是現在用於web端還太早了？感覺除了代碼漂亮了，有些語法糖之外對於團隊來說受益並不大啊，還增加了學習負擔。

僅僅語法轉換是不會增大多少體積的。

你那130KB里包含了所有的polyfill。

如果你看一下現在瀏覽器對ES6+的支持度，再看下你的用戶瀏覽器分布，基本上可以斷言，對於至少50%的用戶來說，其實並不需要載入那額外的100多KB。

所以不是太早，而是優化不夠。

當然現在完善的polyfill按需載入方案確實還沒有業界公認的範例。也許 http://polyfill.io 有希望，可以參考。

最近的一個項目里用了ES6的Set，測試時發現UC瀏覽器不支持Set，於是去找polyfill。看了babel-polyfill的依賴發現Set的polyfill在core-js里，於是直接引用core-js，require的模塊數由108個變成了416個，嚇了一跳。然後翻了翻core-js，把require("core-js")改成了require("core-js/es6/set.js")，模塊數降到了175個，到了可以接受的範圍。引用了整個babel-polyfill模塊數會更多。

其實還有另一種選擇，直接用typescript

天貓前端*已經*全面ES6

已經成為未來標準的、確定的東西，越早用越好。

反正用ES6寫Vue的體驗不得不說非常爽，代碼簡潔，結構清晰，也是給未來的維護工作降低成本啊。

個人見解，還是有必要的。

ES6是個大趨勢，就好像CSS3一樣，雖然很多瀏覽器支持還不是很好。但總歸是一個趨勢。

如果我們總要等到各種條件都允許，這些新潮的技術總是自己電腦中的一個"demo",那這些技術何時才能大面積普及？

只有快速且適當的把這些技術運用到生產環境，才能推動其真正的發展

100多K很大嗎？現在直接拿手機看視頻的人都越來越多了

一百個人眼中有一百個哈姆雷特，一百個人能寫出一百種風格的JS代碼，這就是ES6之前的現狀，題主是在沒在大的團隊呆過吧？

不會,相反我倒是覺得很多人可能太過於關注文件大小產生的影響.

可能大家還是受到雅虎的性能優化"軍規"影響比較深.

我覺得用不用ES6,擔心文件大小,一方面可以從技術方面探索如何減小體積,比如前面有提到直接引入目標模塊;

還有就是結合你的業務實際情況,比如歷史遺留老項目,用戶基數大,改造大,影響廣,那基本上可以不用.但是新項目則可以大膽地用,無非就是在某些漸進增強,優雅降級上要多做考慮.如果你的項目不需要考慮低版本IE那自然就更舒坦了.

ES6非常重要，至少在天貓寫的前端代碼都是ES6標準的。

反正瀏覽器的兼容性本來就是很尷尬的事情，因為國內的瀏覽器不光種類多，而且用的版本也參差不齊，等到ES6像現在的ES5這麼普遍再寫ES6，那就太晚了。各種框架都擁抱ES6了，開發者還不擁抱一下嗎~

目標項目了如果只是宣傳頁用es5吧

如果是後台管理頁面商城級別上es6

typescript也可以考慮

不早吧，我們現在使用的多是一個ES6語法而已，再通過babel 預編譯成ES5規範；等真正瀏覽器都支持ES6之後，只是省去了預編譯的步驟，性能會提升一點，對於我們沒有任何新的學習成本。為什麼不呢？

reactjs項目,已用ES6半年，目前沒發現太大的不妥

相比代碼的維護性來說，100多K其實還是非常值得的，另外健壯性也是會提高不少的吧

同時es6以後肯定是慢慢越來越普及的

再者說現在帶寬的發展，100k簡直是~~

玩react都用es6