我瞭解的前端史
同事邀我寫一篇前端技術發展史，用於新員工培訓。
在查資料寫正式文件之前，我想先寫下自己的經歷和感悟，以免到時分不清 什麼東西是自己的、什麼東西是別人的。
1995 年，網景公司希望給網頁加一些互動性，花兩週時間創造了 javascript，用來控制網頁中的元素。
兩週時間創造的語言一定精緻不到哪去。
但巧妙的是，這門語言非常得開放靈活，開發者可以自己定製它。
例如：
給
String添加個首字母大寫的方法：String.prototype.capitalize = function() { return ( this.charAt(0).toUpperCase() + this.slice(1) ); }; "hello".capitalize(); // Hello修改
Date toString方法：Date.prototype.toString = function() { return ( this.getFullYear() + "/" + (this.getMonth() + 1) + "/" + this.getDate() ); }; new Date().toString(); // 2019/12/21
因為這種開放性，javascript 吸收了大量開發者的智慧，變得越來越好。
這種策略對我很有啟發。
一件事我自己搞不定，那可以把他變成大家的事，讓集體智慧發揮作用。
道理簡單，但難在放低姿態，保持開放的心態，能真正聽進去意見。
吸收了開發者集體智慧後，javascript 標準【準確點是 ECMAScript 標準】發展得很快。
但碰到了一個問題：標準跑到了半山腰，瀏覽器們還在山腳下。
畢竟程式跑在瀏覽器上，標準再好，瀏覽器不支援 開發者也沒法用。
甚至眾多瀏覽器對標準的支援情況也不一樣，不僅是 javascript，html 和 css 也一樣。
一度招聘要求裡都有一條“能解決瀏覽器相容性問題”。
瀏覽器相容性問題讓開發者很頭疼。“幫開發者解決瀏覽器相容性問題”成了各框架的重點任務。
其中玩得比較過的是 ExtJS。
html、css、javascript 相容性問題它全包了。
思路是這樣的：
html、css：開發者不要寫了，所以開發者不用關心這類相容性問題了。
html、css 寫法
<style> .submitBtn { font-size: 2em; padding: 10px; } </style> <button class="submitBtn">提交</button>ExtJS 寫法
{ xtype: 'button', scale: 'large', padding: 10 }
javascript：開發者使用 ExtJS 的 api，而不用 ECMAScript 標準的 api。
例如拷貝 b 物件的屬性到 a 物件上:ECMAScript 標準
Object.assign(a, b);ExtJS
Ext.apply(a, b);
ExtJS 徹底讓開發者不用考慮瀏覽器相容性問題，大幅提升了開發效率。
但代價是：
開發者和 html、css、javascript 標準被隔離開，
開發者像是在用一門新語言程式設計，被綁架在這個框架上。
再後來 babel 出現了，開發者終於可以擁抱最新 ECMAScript 標準了。
babel 的思路是這樣：
開發者用最新 ECMAScript 標準去寫程式碼，然後通過 babel 編譯，轉成瀏覽器支援的程式碼。
前面說了框架可以提升開發效率，其實框架還有一個更重要的作用：限制開發的自由度。
從 A 處到達 B 處，
如果不限制交通工具，那麼每個人採用的方式就可能不同，有人走，有人開車，有人坐飛機……
對應到開發：
- 框架自由度大，你將看到人類無限的創造力；
- 框架自由度小，你將區分不出別人的程式碼和自己的程式碼。
早些年前端流行 MVC 框架。
從程式碼職責層面，什麼檔案幹什麼活 確實很清楚。
但因為 MVC 使用事件驅動，事件太靈活，資料流到底怎麼走，你預判不了，得看開發者當時的心情。
View 派發一個事件，可能是 Controller 在監聽、可能是父元素在監聽、還可能是兄弟元素在監聽、還可能是多個地方同時在監聽，甚至還和監聽的順序緊密相關。
團隊人多時，這種靈活性將是一個噩夢。
近些年 React 等框架限制就嚴格得多：資料流單項傳遞，只能父到子。
一些場景下 程式碼實現比事件驅動麻煩，但好處是 大家的程式碼長得更像了