webpack入門（一）webpack的動機 ---前端專業英語

記得某次考試，出國N年老師出的卷子全是英語，坑的英語很差的咱們不要不要的。幸好上了專業英語課。最重要的是專業英語對於咱們很重要，好比webpack，一堆博客都是幾小時入門，如何會用webpack，當你想用它的某種特性，好比異步加載moudle，用到require.ensure，或者一些很細節的api，一些遇到的問題，都是中文網站，博客解決不了的。曾經嘲笑那些學視頻的自認爲大神前端，你找個webpack中文詳細教學視頻看看。

[笑哭].此次，咱們來copy一下webpack官網，學一下英語。

開始的motivition，why we do it.web app 能作不少事，咱們能在瀏覽器裏用js作更多的事…導致客戶端有n多代碼，咱們須要一種代碼加載，模塊加載的東西。

Module systems offer the option to split your code base into modules.模塊系統提供一個選項去把代碼劃分到模塊裏。

There are multiple（多重的;多個的;複雜的;多功能的;） standards for (標準)how to define dependencies and export values:下面列舉了模塊的標準，amd，cmd，es6的import等。

This is the way you would handle a modularized（模塊化的）code base if you didn’t use a module system.

<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>

他們共同的問題Common problems

• Conflicts in the global object.全局對象的衝突
• Order of loading is important.加載的順序
• Developers have to resolve dependencies of modules/libraries.開發者須要解決模塊和庫的依賴問題
• In big projects the list can get really long and difficult to manage.大工程的list很大很難管理

CommonJs: synchronous（同步） require cmd的同步加載

AMD: asynchronous require     amd的異步加載

他們的Pros（優勢）Cons(缺點)就不寫了。

ES6的模塊加載機制

import "jquery";
export function doStuff() {}
module "localModule" {}

Pros

• Static analysis is easy   靜態分析是很容易的
• Future-proof as ES standard  是將來的標準

Cons

• Native browser support will take time  本地瀏覽器支持還須要一段時間
• Very few modules in this style   還不多有模塊是es6版的

TRANSFERRING

Modules should be executed on the client, so they must be transferred from the server to the browser.

There are two extremes on how to transfer modules: 模塊應該在客戶端執行，因此他們必需要從服務器端轉換到瀏覽器，這有怎樣轉換模塊的兩個極端。

• 1 request per module      每一個模塊一個需求
• all modules in one request   全部模塊都用一個需求

Both are used in the wild, but both are suboptimal: 這倆都是野辦法，用的都是（次優的）不咋樣。

• 1 request per module
  • Pro: only required modules are transferred    只有加載的模塊被轉換了
  • Con: many requests means much overhead    更多的請求意味着更多的開銷
  • Con: slow application startup, because of request latency   這個app啓動很慢，由於請求的延遲
• all modules in one request    
  • Pro: less request overhead, less latency     更少的請求開銷和延遲
  • Con: not (yet) required modules are transferred too   未請求的模塊也被轉換了

Chunked transferring   分塊轉換(chunk)

A more flexible transferring would be better. A compromise between the extremes is better in most cases.一個更加複雜的轉換多是更好的，在大多數狀況下，極端之間的妥協是更好的。

→ While compiling all modules: Split the set of modules into multiple smaller batches (chunks). 編譯全部模塊的時候，把這個模塊切分到一些更小的分支，也就是每一個chunk

We get multiple smaller requests. Chunks with modules that are not required initially（最初）are only requested on demand(需求), The initial request doesn’t contain your complete code base and is smaller.咱們獲得一些更小的請求，modules的chunks沒有加載最初的，僅加載了須要的chunk，初始請求不包含你完整的代碼庫，它更小。

The 「split points」 are up to the developer and optional.劃分紅chunk這點是開發者可選的。

→ A big code base is possible!

Note: The idea is from Google’s GWT.

Read more about Code Splitting.

WHY ONLY JAVASCRIPT?

Why should a module system only help the developer with JavaScript? There are many other static resources that need to be handled:爲啥模塊系統只能服務於js開發者？這裏這些靜態資源都須要被處理。

• stylesheets
• images
• webfonts
• html for templating
• etc.

And also:

• coffeescript → javascript
• elm → javascript
• less stylesheets → css stylesheets
• jade templates → javascript which generates html
• i18n files → something
• etc.

This should be as easy as:

require("./style.css");
require("./style.less");
require("./template.jade");
require("./image.png");

Read more about Using loaders and Loaders.

STATIC ANALYSIS

When compiling all the modules a static analysis tries to find dependencies.當編譯全部模塊的時候，靜態分析試着去尋找依賴。

Traditionally this could only find simple stuff without expression, but i.e. require("./template/" + templateName + ".jade") is a common construct.

傳統上只能找到簡單的依賴可是不被解析。可是ie裏面require("./template/" + templateName + ".jade")是公認的結構

Many libraries are written in different styles. Some of them are very weird…許多庫都用不一樣方式寫，而許多都是很奇怪的。。。