nizniz187 / study-es6transpilingpolyfill Goto Github PK

快速總結目前已知的

1. 導入 ES6 分兩個部分：
   • 轉譯：將 ES6 新語法轉成 ES5 (ex. let → var)
   • Polyfill：將 ES6 新功能用舊語法實作出來 (ex. Promise.resolve().finally();)
2. 上述導入沒有相依性，可獨立進行，但通常兩個會一起做（否則在寫 ES6 的時候還得注意有沒有用到不支援的新功能。）
3. 導入相關套件：
   • 轉譯：Babel / Traceur
   • Polyfill：core-js / Polyfill.io
4. 目前選用 Babel 作為目標導入套件。

Babel 能做到什麼？

1. 可同時實現轉譯與 Polyfill。
2. 引用 core-js 函式庫來實現 Polyfill。
3. 可進行線上即時轉譯（dev 環境適用），也可線下事先轉譯（prod 環境適用）。
4. 但 Babel 預設是在 node 環境下執行，綁定 npm 工具與 node 專案架構，因此需要其他工具來打包轉譯過的檔案才能與現有開發環境作整合。

其他工具是什麼？

1. 前端打包工具有很多，目前以 webpack 作為目標套件。
2. webpack 可實現自動轉譯。
3. 預定學習目標

最重要的 VS 整合議題呢？

1. VS 有一些工具可以實現整合 Babel + webpack，而這些通常是跟著 React.js 需求走的。
2. 只大略看過一些文章，但需要先了解 webpack 才比較容易評估。如有興趣可自行先研究：
   • SETTING UP A REACT ENVIRONMENT FOR ASP.NET MVC
   • ReactJS.NET
3. 應能解決環境整合問題，但對於其他非前端程式人員的部署 / 開發是否為最佳解仍有待研究。

效能？成本？

1. 使用 Babel 轉譯的成本比較多是在開發環境（Babel 核心程式、轉譯時間），實際轉譯後的檔案大小視新語法的使用量而定。
2. 需要時間才能進行更深入的分析。
3. 轉譯成本在舊瀏覽器上相對較高，但愈舊的瀏覽器使用比例也愈低；只要能跑得動，讀取時間長一點應是能接受的。

結論

1. 目前確定可導入，只是仍需要時間來尋找 VS 環境整合的最佳解。最糟就是在下個專案花多一點成本部署環境。
2. 下階段目標：研究 webpack + VS 整合。預計工時 5 天。

其他資訊

• 完整學習筆記
• 學習進度規劃
• 待思考議題
• 整體專案研究主題

前情提要

1. ES6 導入所需技術：polyfill + transpiler
2. ES6 導入工具選擇：Babel + webpack

webpack 學習進度

1. 安裝
2. 資源管理
   • 資源配置
   • 資源打包
3. 自動編譯
   • 開發中即時編譯與更新
4. 程式碼拆分配置
   • 動態載入模組
   • 資源分析
   • 快取最佳化

下階段目標與工時預估

其他資訊

• webpack 學習筆記
• webpack 研究主題規劃

主要變動

1. 將所有資源 (JS/CSS/Images) 放到 Assets 資料夾下。
2. 前端專案相關設定檔 (package.json/package-lock.json/.babelrc/.browserslistrc) 與 npm 管理之套件 (node_modules) 會放在 Web 專案的根目錄下。

測試環境配置

如只是要執行前端程式而不需要修改，從 git 下載最新版本即可，不需額外變動。前端人員會在上版前把所需資源編譯配置好，所有配置好的前端資源都會在 Assets/dist 資料夾下。

前端開發環境配置

如需修改前端程式並上版，需要進行以下步驟：

1. 作業系統安裝 node.js
2. VS 安裝 NPM Task Runner 擴充工具
3. 使用 NPM Task Runner 執行 install 命令（如遇到錯誤，調整外部網站工具設定）
4. 修改完程式後，使用 NPM Task Runner 執行 build 命令

在 VS 中使用 Babel 的幾種方式

1. Babel standalone：直接引入 babel js，在頁面載入的過程中即時轉譯 JS。
   • 僅適用於開發環境。
2. NPM Task Runner plugin + WebPack Task Runner plugin
   • 基本上只是將 babel 與 webpack 的命令列環境移到 VS 裡執行而已，並無太多整合效益。
3. ReactJS.NET plugin
   • 主要是針對 react 轉譯的插件。但因其轉譯使用 babel，所以亦適用於非 react 的 babel 專案。
   • 綁定 msbuild，與 VS 的建置命令整合在一起。（建置專案時會同步轉譯 JS 檔案）

Modern JS 與 VS 整合的可預見問題

其實 Modern JS 是一條往前端獨立發展的進程，所以沿著 ES6、Module API、NodeJS、babel、webpack 這條路線一直往下走，會發現前端專案管理已經自成一套體系。此時要再回頭來探討如何與 VS 這種偏向後端的 IDE 整合，就會顯得格格不入──整合相關資源少，未來發展性也不高。

因此可以說：整合進 VS 的 Modern JS 專案會是閹割後的版本；很多前端專案管理自動化或優化的功能無法實現，或是得要花額外的成本來整合實現。例如：cache 優化、動態配置檔名與打包、自動化測試等。

參考：Visual Studio +WebPack 构建Asp.net Mvc

整合策略分析

整合議題有兩大面向：

1. 前端開發者如何將前端專案整合進整體專案裡。
2. 非主要前端開發者如何修改前端內容並順利完成前端專案建置。

我們會希望儘可能降低這兩者的成本，但在許多角度看來兩者似乎是相互牴觸的。

以最小成本來看

使用 ReactJS.NET 能滿足我們的基本需求：使用 babel 轉譯 ES6 語法、與 VS 建置功能整合。
主要缺點是前端的擴展性會受到限制。

以開發效益來看

前後端完全分離會是一個很好的方向。兩者的檔案放在同一目錄結構下，但使用各自的 IDE 開發；前端能因而有完整的專案管理機制，擴展性高。
主要缺點是：非主要前端開發者的學習成本高，且前後端傳值得完全 API 化（不再有 cshtml）。