正文
大家好，我是winter，今天我分享的主題是“你不知道的組件化開發(fā)：組件化的前世今生”。
今天前端生態(tài)里面，React、Angular和Vue三分天下。雖然這三個框架的定位各有不同，但是它們有一個核心的共同點，那就是提供了組件化的能力。W3C也有Web Component的相關(guān)草案，也是為了提供組件化能力。今天我們就來聊聊組件化是什么，以及它為什么這么重要。
其實組件化思想是一種前端技術(shù)非常自然的延伸，如果你使用過HTML，相信你一定有過“我要是能定義一個標(biāo)簽就好了”這樣的想法。HTML雖然提供了一百多個標(biāo)簽，但是它們都只能實現(xiàn)一些非常初級的功能。
但是，HTML本身的目標(biāo)，是標(biāo)準(zhǔn)化的語義，既然是標(biāo)準(zhǔn)化，跟自定義標(biāo)簽名就有一定的沖突。所以從前端最早出現(xiàn)的2005年，到現(xiàn)在2019年，我們一直沒有等到自定義標(biāo)簽這個功能，至今仍然是Draft狀態(tài)。
不過有同學(xué)會問：自定義標(biāo)簽也不等于組件化本身啊。沒錯，不過可以進(jìn)一步思考，其實我們需要的并不一定是自定義標(biāo)簽這樣的一個形式，可以從軟件工程的通用思想來解釋，組件化可以拆解為四個更基本的概念：
- 復(fù)用：組件將會作為一種復(fù)用單元，被用在多處。
- 解耦：組件本身隔離了變化，組件開發(fā)者和業(yè)務(wù)開發(fā)者可以根據(jù)組件的約定各自獨立開發(fā)和測試。
- 封裝：組件屏蔽了內(nèi)部的細(xì)節(jié)，組件的使用者可以只關(guān)心組件的屬性、事件和方法。
- 抽象：組件通過屬性和事件、方法等基礎(chǔ)設(shè)施，提供了一種描述UI的統(tǒng)一模式，降低了使用者學(xué)習(xí)的心智成本。
我們可以進(jìn)一步分析，其實組件化并非前端獨有的一種需求，任何軟件開發(fā)過程，或多或少都有那么一些組件化的需求。而你可以思考為什么較好的組件化解決方案（三大框架）會出現(xiàn)在2014年左右這個時間點，這是一個耐人尋味的問題。而我認(rèn)為這個問題的答案，就藏在前端發(fā)展的歷史當(dāng)中。
我們可以看下復(fù)用、解耦、封裝、抽象這四個概念，很顯然，它們都是為了大型的、多人協(xié)作的軟件開發(fā)所準(zhǔn)備的。所以我認(rèn)為，2014年左右這個時間點，正是前端發(fā)展到了一個需要規(guī)模化的時間點。
我們縱觀前端的發(fā)展歷程，開始于2005年左右，是特效為王的時代，前端領(lǐng)域追逐的是炫酷的效果；到了2009年左右，jQuery開始統(tǒng)治前端，這時API易用性和瀏覽器兼容性是最重要的；等到了2012年移動互聯(lián)網(wǎng)出現(xiàn)之后，提供組件化方案的“三大框架”逐步占據(jù)了前端重要的生態(tài)地位。
接下來我們深入具體的技術(shù)細(xì)節(jié)，看看組件化是如何一步步發(fā)展的。
首先，標(biāo)準(zhǔn)的DOM元素是這樣創(chuàng)建和掛載的：
這里的element是一個對象，但是其實JavaScript（早期）里面，根本沒法創(chuàng)建這樣的對象。一方面也是我們沒有辦法改變createElement這個函數(shù)的行為。
既然API風(fēng)格沒法靠攏DOM原生，那么就靠攏JS原生吧，所以一些前端開發(fā)同學(xué)就萌生了創(chuàng)建一個帶容器的對象的想法：
不過，要想掛載又成了難題，普通的JS對象沒法被用于appendChild，所以前端工程師就有了兩種思路，第一種是反過來，設(shè)計一個appendTo方法，讓組件把自己掛到DOM樹上去。
第二種比較有意思，是讓組件直接返回一個DOM元素，把方法和自定義屬性掛到這個元素上：
雖然從前端全領(lǐng)域來看，組件化到后期（2014年）才有比較普及的應(yīng)用，但是早年用這樣的思路實現(xiàn)組件體系的方案并不少，說明組件化在一些公司和領(lǐng)域始終有需求。雖然當(dāng)時有一些組件化方案沒能夠影響行業(yè)，但是不可否認(rèn)它們也還算是不錯的解決方案，比如著名的ExtJS（現(xiàn)已更名為Sencha），我們來看看它的組件定義：
你可以看到，這是一個完全使用JS來實現(xiàn)組件的體系，它定義了嚴(yán)格的繼承關(guān)系，這樣的方案很好地支撐了ExtJS的前端架構(gòu)。
不過，創(chuàng)建和掛載對象的方式可不止DOM API，還有HTML語言，如何讓前端組件融合進(jìn)HTML語言呢？
關(guān)于這方面，依賴早期標(biāo)準(zhǔn)的前端技術(shù)可以說幾乎沒有辦法。但是，歷史中總有些遺珠，微軟的IE瀏覽器已經(jīng)提供了組件化的解決方案，名為HTML Component，我找了一段非常古老的示例。
這項技術(shù)提供了事件綁定和屬性、方法定義，以及一些生命周期相關(guān)的事件，應(yīng)該說已經(jīng)是一個比較完整的組件化方案了。但是我們可以看到后來的結(jié)果，它沒有能夠進(jìn)入標(biāo)準(zhǔn)，默默地消失了。用我們今天的角度來看，它可以說是生不逢時。
到了“三大框架”出現(xiàn)的時代，因為面向的客戶群體從少數(shù)公司、少數(shù)領(lǐng)域變成了廣大前端開發(fā)群眾，也因為一些新技術(shù)的出現(xiàn)，讓舊時代組件化沒法解決的問題有了新的可能性，這些新的組件化方案都保持了HTML甚至CSS的書寫習(xí)慣。
Vue.js采用了JSON的方法描述一個組件：
還提供了SFC（Single File Component，單文件組件）“.vue”文件格式：
React.js發(fā)明了JSX，把CSS和HTML都塞進(jìn)JS文件里：
Angular.js選擇在原本的HTML上擴展，定義組件的方式也是JS class：
我們可以看到，現(xiàn)代的組件化方案跟舊時代組件化方案的一個明顯區(qū)別就是，現(xiàn)在的組件化方案保留了原有的標(biāo)記語言部分，并且努力保留了樣式表部分。
雖然技術(shù)從舊到新經(jīng)歷了各種變遷，但是組件化的核心并沒有變化，我們的目標(biāo)仍然是在API設(shè)計盡可能接近原生的情況下完成復(fù)用、解耦、封裝、抽象的目標(biāo)，最終服務(wù)于開發(fā)，提高效率，降低錯誤發(fā)生比率。
如果你的公司和前端團(tuán)隊規(guī)模正好面臨需要建立組件化體系，希望你能從今天所分享的歷史中獲得一點靈感。
Q & A
Q1：我想請問老師，組件的顆粒度什么樣比較合適？它的包含度又應(yīng)該是什么樣的范圍
A：其實組件的粒度是無所謂的，它是一個級聯(lián)的結(jié)構(gòu)，所以說可以有粗粒度的組件，也可以有細(xì)粒度的組件。我個人覺得用體系這個詞去替代粒度的這個概念會更好。你怎樣設(shè)計細(xì)粒度組件，又怎樣設(shè)計這個粗粒度組件，最后是要形成一個很好用的體系，這個組件體系可以滿足你，簡單地用，復(fù)雜地用，現(xiàn)成地用，大塊兒地用...
Q2：組件化了還能做SEO么？
A：如果你對現(xiàn)代的這個seo有一定的了解的話，你會發(fā)現(xiàn)seo其實已經(jīng)走到了一條完全不一樣的道路上了。我們現(xiàn)在很多的seo方案是服務(wù)端專門渲染一套給搜索引擎去看的一個頁面。如果我們正常的使用各種組件化的技術(shù)，這肯定會對seo產(chǎn)生負(fù)面影響。畢竟你用了一個自定義的標(biāo)簽，而瀏覽器并不認(rèn)識。不過其實瀏覽器也有專門專門寫給搜索引擎看的一些標(biāo)簽。
Q3：如果避免組件過度封裝？
A：其實我覺得現(xiàn)在大家還沒有到擔(dān)心過度封裝的時候，但是大家往往會發(fā)生一種沒有封裝的情況。當(dāng)然，這個狀態(tài)也會比較危險，當(dāng)你從沒有封裝過，然后突然發(fā)現(xiàn)封裝這玩意兒很好用，就可能去過度封裝了。實際上針對封裝，我們應(yīng)該去了解一些基本的知識。比如什么叫對象？為什么要把這些方法和屬性，聚合成一個對象？這里有個概念就是局部性，當(dāng)你把有局部性東西聚合起來，就是好的；你把沒有局部性的聚合起來，就會適得其反。當(dāng)然這只是個例子，主要是講一下面向?qū)ο蟮幕驹瓌t，當(dāng)你學(xué)習(xí)了這些，就不會過度封裝。
Q4：如何進(jìn)行組件化的體系設(shè)計？
A：UI組件可以參考w3c的AccessibilityInitiativeWAI標(biāo)準(zhǔn)，它把人類常用的組件規(guī)范都總結(jié)完了，它本身不是組件，但是你去設(shè)計組件的去參考它是非常好的。
Q5：老師能講講微服務(wù)嗎？
A：微服務(wù)這個概念本身就是從后端來的一個純粹的概念，我還沒見過誰在前端搞微服務(wù)。服務(wù)這個詞對前端頁面的維度來說有點大，前端是沒有服務(wù)這個概念的，更何況再衍生出來微服務(wù)的這個概念。微服務(wù)主張一個服務(wù)，只做一件事情，專注做好自己的這一塊兒；而不是去混合成業(yè)務(wù)場景，去設(shè)計API。從某種意義上講，我認(rèn)為，一個前端頁面，甚至有可能都不一定有一個后端的微服務(wù)大。所以我不建議把微服務(wù)引進(jìn)前端里面來。
Q6：關(guān)于WebComponent、TypeScript、WebAssmebly
A：關(guān)于WebComponent、TypeScript、WebAssmebly未來的問題，一句話講就是，我也不知道啊。未來的東西真的不太好預(yù)測，但是目前來看，我認(rèn)為這三個東西都是偏向比較積極的，都是高速發(fā)展的，都是快速落地的。但是，你說它會不會真的超過現(xiàn)有的一些東西，它能發(fā)展到什么程度，就很難說了。我建議這三個東西是應(yīng)該被積極對待的，都去學(xué)一下，畢竟可能哪個未來就會成為一塊兒很重要的東西，而且它們也確實能夠解決我們很多前端開發(fā)的問題。
Q7：組件設(shè)計好了之后，怎么樣去給它添加功能？怎么樣去迭代？
A：坦白地講，這是個難題。雖然我可以講出很多聽起來特別有道理的理論。但事實上，曾經(jīng)在淘寶發(fā)生的一件事，就是一個輪播，最后被加了30多個參數(shù)。當(dāng)然，這個背后，當(dāng)然我還是要講一下關(guān)于這個的理論知識。我們設(shè)計組件也是遵循面對象的基本原則，對修改封閉，對擴展開放。所以，如果我們能做好這件事，比如說有個新功能，你就可以選擇繼承，然后包裝這個組件，形成一個新的組件來完成這個新功能。這樣，組件體系就會變豐富，不會有很多的麻煩。
Q8：關(guān)于GraphQL
A：我在以前在淘寶工作的時候，我們的GraphQL也沒能真正落得特別好。而且，據(jù)我了解，GraphQL在Facebook自己那邊，其實落地也不是特別好。我覺得這個理念特別先進(jìn)，叫backend for frontend。我認(rèn)為它是BFF的一個延伸，但是其實很少公司是這么落地的。比如說在淘寶，其實我們落了一個半像不像的一個東西，就是有些API，我們可以通過后端去寫GraphQL來生成出來。最后你前端看到的還是一堆數(shù)據(jù)，但是其實這個和GraphQL原本的設(shè)計不太一樣。
Q9：在開發(fā)公司內(nèi)部組件庫時，有必要去設(shè)計組件間的消息機制嗎？如果有必要，能帶來哪些明顯的優(yōu)勢？
A：其實我不太建議有一個postmessage這樣的機制。我記得在2015年左右，那時候聽阿里的晉升面試，每個人都要講一下他設(shè)計的組件體系和他組件間的消息通訊機制，有用消息池的，有用各種分發(fā)的策略的。但其實這個東西到最后，你這個消息進(jìn)了這樣的消息機制，你debug的鏈路就斷了，消息過去了，你不知道后面執(zhí)行了什么代碼。所以，我不太建議做這種直接的消息機制。但你看現(xiàn)在，F(xiàn)lux、Redux這樣的東西，其實它都是一種變形的消息機制。其實我比較推崇的是vue和angular的雙向綁定。它其實不完全是一種消息機制，當(dāng)你去操縱這個數(shù)據(jù)，數(shù)據(jù)變化以后，所有跟這個數(shù)據(jù)相關(guān)聯(lián)的組件都會產(chǎn)生變化。實際上，這個里面是有消息流轉(zhuǎn)的，你去看vue的源代碼里面，它一定是有消息通知過來，這個代碼變了，那邊去observe這個屬性。這樣其實替代了某種程度上的消息，但它的語義化更好，它不是一個未經(jīng)定義的所謂的消息，告訴你，你自己去拿一個字符串去定義，而是一種給你規(guī)定好了的數(shù)據(jù)變化形的消息，甚至規(guī)定了你應(yīng)該如何響應(yīng)它，我認(rèn)為這種模式能夠減少開發(fā)出錯。
Q10：有vue 頁面首次加載白屏好的方案嗎？
A：vue頁面首次加載白屏，你需要看一看是不是它的模板沒有預(yù)編譯。一般來說，vue首次加載白屏，都是因為在運行時，引用了vue的調(diào)試版本，所以導(dǎo)致它加載白屏，因為它要編譯你的代碼。我們一般來說用vue-cli創(chuàng)建的都是沒有這個問題的。如果你的情況比較特殊，我建議你直接去vue社區(qū)留言，他們很喜歡這樣的例子。如果你有這種真正意義上的會導(dǎo)致它白屏的案例，他們會很積極的幫你去設(shè)計方案去解決，看到底哪兒出了問題。
Q11：能聊聊關(guān)于頁面性能嗎？
A：從工程的角度來看，性能跟組件化其實是兩個方向，所以說性能跟這次組件化分享沒有關(guān)系。但是可以稍微聊一下，凡是工程體系，都需要有一些監(jiān)控手段，評估手段。所以，你做性能的時候，肯定先建立這個標(biāo)準(zhǔn)，能夠知道這個頁面的性能怎么樣，然后再去看怎么去優(yōu)化它。網(wǎng)上有很多關(guān)于性能優(yōu)化的這樣的方法論，還能找到各種各樣很好的性能優(yōu)化的小細(xì)節(jié)，在此就不贅述了。
Q12：傳統(tǒng)的架構(gòu)師大多數(shù)是后端過來的，相對于后端架構(gòu)師，我們前端在架構(gòu)方面怎么能最大的體現(xiàn)價值？或者什么才是一個前端“架構(gòu)師”？
A：這個問題挺不錯的。前端架構(gòu)師面臨的問題，實際上跟別的架構(gòu)師不太一樣。前端是零碎的頁面，大量的重復(fù)性勞動，而不是傳統(tǒng)軟件意義上來講的，模塊間的耦合和復(fù)雜性。所以，前端架構(gòu)師重點關(guān)注的應(yīng)該是復(fù)用，這就跟咱們今天聊的組件化非常相關(guān)了。我原來帶手淘架構(gòu)組的時候，基本上都是在做組件體系的事，先把復(fù)用做上來。
另外，前端架構(gòu)跟服務(wù)端架構(gòu)、客戶端軟件架構(gòu)不太一樣的地方就是，前端架構(gòu)還是可以用一些工具去解決的。比如淘寶特別重視的dajian系統(tǒng)，是我們的工程體系里面的很重要的一環(huán)，可以大量地產(chǎn)出簡單的頁面，不需要經(jīng)過前端，通過模板化或者是模塊化的方法。
Q13：可是angularJS這種臟檢查模式，在一些情況下，影響性能，有要注意改進(jìn)的地方嘛？
A：angularJS的臟檢查模式出來的第一天，我就在噴這個事情，真的影響性能。不過你會看到這個問題，其實是一個技術(shù)問題，是因為angularJS最開始的這個設(shè)計者的技術(shù)不過關(guān)造成的。技術(shù)問題在其影響力足夠大了以后，一定會有人出來解決。比如后面JS標(biāo)準(zhǔn)也出了proxy。所以在angular2，這個問題已經(jīng)得到了很好的處理，只要你去angular社區(qū)逛逛，是可以找到這個問題的答案的。
Q14：有必要向全棧發(fā)展嗎？
A：說實話，目前來看，在中國國內(nèi)，全棧的市場不是特別的看好。另外，我特別不建議你去做node全棧，不是我說我看不起node，反正是我覺得node難。node的局面，可以說是百廢待興。你拿node做server，想拿這個server真正能夠穩(wěn)定地跑到線上，能夠自己重啟，其實要寫的代碼是非常多的。所以只有阿里的那幾位大神，宿遷、樸靈啊...他們在阿里才能搞起一塊兒node這樣的場景。其實他們也很艱難，所以我不建議轉(zhuǎn)node全棧。
如果你拿一個已經(jīng)很火的這種后端語言，比如python、ruby或Java跟JS搭一下去做這個全棧，我覺得肯定是可以。多學(xué)一門手藝肯定是好的，但就看你自己怎么分配精力了。另外還要看全棧是不是在市場上有足夠的崗位。現(xiàn)在來看全棧的崗位，更偏向小公司一些；或者說你自己要創(chuàng)業(yè)，那你搞個全站是很好的。所以我覺得職業(yè)發(fā)展是個人的偏好問題，沒有一個放之四海皆準(zhǔn)的規(guī)則。我也不可能給你一個建議說，你就做全站吧，別做全棧了。其實我自己也是會一點兒服務(wù)端的，但是我肯定不會往全棧去做，因為我覺得精力跟不上。
Q15：電商網(wǎng)站，金額計算有必要前后端都進(jìn)行計算嘛？
A：這個問題問得比較奇怪。一般來說金額計算是要后端進(jìn)行計算的。至少在阿里，我們很少拿前端去做計算一些折扣這樣的事情。這里面主要是從這個風(fēng)險上，去評估一些問題。比如說你客戶端版本更新不上，造成優(yōu)惠錯誤，可能就會產(chǎn)生一些資損。當(dāng)然這個東西沒有絕對一說，比如購物車?yán)锏目們r要不要到服務(wù)端去再繞一圈兒，那我覺得不用。所以我認(rèn)為這個問題還是要分析一下具體情況。
Q16：老師，請教一下，以前面試的時候聽面試官說，前端后期需要了解http協(xié)議制定規(guī)范，還有需要回設(shè)計模式甚至用nodejs成為web全棧，這是成長必須的么？
A：HTTP協(xié)議規(guī)范，我覺得有用。但是，其實你真要去問的話，一般人知道得HTTP狀態(tài)碼，我認(rèn)為不會超過10個。所以知道HTTP協(xié)議的細(xì)節(jié)要求是有點偏高得，這不是必要的，但是我覺得它肯定在某些時候會有用。所以從學(xué)習(xí)的角度來講，我建議你學(xué)。從面試的角度來講，我覺得這是個無理要求，因為你也不知道他要考哪兒。
關(guān)于設(shè)計模式，其實你要知道設(shè)計模式這本書，其實他是為基于類的面向?qū)ο髞砭帉懙摹Ｋ哉f很多模式在JS這邊，要么不需要，要么不能用。比如說這個工廠模式，它解決new的時候，class的東西沒法傳的問題。實際上，在JS里有這個問題嗎？我們的JS構(gòu)造器就可以把class當(dāng)作函數(shù)參數(shù)往里傳，所以根本就不存在工廠模式的這種需求，不管是抽象工廠還是builder，還是不在23模式中的簡單工廠模式，都不需要，我們沒這需求。
Q17：flutter最近很火的，作為前端有必要學(xué)嗎？
A：我覺得你要是什么技術(shù)火學(xué)什么，那估計，你要累死。其實最火的不是flutter，應(yīng)該是區(qū)塊鏈和AI，但你不太可能往那邊轉(zhuǎn)。學(xué)flutter也是一樣的道理。如果覺得你很喜歡flutter，你就去學(xué)。但是你要知道flutter是一個全新的體系，它其實跟我們傳統(tǒng)的前端開發(fā)已經(jīng)有一定的隔離了。我認(rèn)為它會是一個比較小眾的東西，因為我覺得它確實做的很好，所以它能夠有自己的一席之地。
Q18：前端是否應(yīng)該有一套自己的設(shè)計模式？
A：前端的設(shè)計模式是有的，之前有一個比較火的石川就講了一些前端自己的設(shè)計模式。http://shichuan.github.io/javascript-patterns/
但是我們前端其實不太有這個像JOF思維大神一樣的這種人物，所以說我們可能總結(jié)的模式都比較弱。其實前端還是一個很年輕的行業(yè)，所以有一些小的模式——微模式，其實已經(jīng)是很成熟了。但是你說達(dá)到JOF總結(jié)的23模式這種水平的，我覺得客觀上會存在，但是咱們水平不夠，總結(jié)不出來。
Q19：關(guān)于數(shù)據(jù)結(jié)構(gòu)和算法。
A：我覺得大家把數(shù)據(jù)結(jié)構(gòu)和算法想復(fù)雜了。你說for循環(huán)是不是算法，它就是一種簡單的算法。你說數(shù)組是不是數(shù)據(jù)結(jié)構(gòu)，它當(dāng)然是數(shù)據(jù)。在數(shù)據(jù)結(jié)構(gòu)里，數(shù)組叫做順序表，如果你有數(shù)據(jù)結(jié)構(gòu)的書，你就可以找到，它跟鏈表相對。我們?nèi)W(xué)數(shù)據(jù)結(jié)構(gòu)和算法學(xué)的是什么呢？這個其實叫做經(jīng)典數(shù)據(jù)結(jié)構(gòu)和經(jīng)典算法。所以我不特別建議你去一個一個的去啃這些經(jīng)典數(shù)據(jù)結(jié)構(gòu)和經(jīng)典算法。但是我建議你提高自己的數(shù)據(jù)結(jié)構(gòu)和算法的水平。
另一方面，大家有時候認(rèn)為公司出的算法題，覺得是不應(yīng)該，都不需要考前端。但其實，在我看來，我們大部分公司考的那個所謂的算法題，它都是一個簡單的小程序。實際上，我們的代碼跟算法其實沒那么容易分開，他們的邊界是很模糊的。你說你寫一個復(fù)雜一點的小程序，它就是一個算法，你寫一個簡單一點兒的算法，它就是我們?nèi)粘懙囊欢未a，兩個沒區(qū)別。廣義的算法就是你寫的，只要是有邏輯的代碼都叫算法。
Q20：webgl會火嗎？感覺現(xiàn)在招webgl的也不多，學(xué)webgl光學(xué)three.js可以嗎？
A：我覺得這塊作為一種知識儲備，可以去學(xué)一下。當(dāng)然我是比較推薦資深一點的前端，希望尋求突破的時候往這個方向去走一走。如果你本身在前端的基礎(chǔ)，CSS、HTML和JS這些方面都沒有拿到優(yōu)勢的話，你并不面臨瓶頸，你沒有必要往這個方向去發(fā)展。因為你的競爭對手有很多，還有c++一堆大神可能對這邊有興趣，要轉(zhuǎn)過來。
Q21：請問老師，自己公司的app 能在chrome 上模擬注入某段代碼判斷是這個app 么，類似于判斷是微信，是支付寶，是瀏覽器這種??，因為我們很多h5頁面都是內(nèi)嵌在自己app 中的
A：這個問題特別的具體。如果你的webview是你自己寫的，那一定是能。如果你是要到瀏覽器里的話呢，這個也是可以的，你可以注冊一段協(xié)議，然后拉起自己的APP，然后打開了之后，再回來。所以，這個綜上所述就是能，不過你們要是在自己的webview里打開，那就很方便，你只需要用密碼學(xué)手段注冊一個特殊的字符串兒進(jìn)去，然后比如說跟時間有關(guān)的，就加個簽名，然后讓這個去網(wǎng)頁的代碼去判斷這個簽名就可以了。
當(dāng)然呢，大部分的時候，其實我們沒有這么高的要求，比如說淘寶，我們判斷這個頁面是不是在自己的APP里面，其實我們就加了一段UA，沒有我前面說的那個什么簽名之類的奇特的手段。因為我們不需要這種安全性檢查，我們只需要判斷一下是不是。如果你騙我了，就騙我了，也無所謂。
Q22：webgpu要是出來的話webgl現(xiàn)在還有接觸的必要嗎？
A：這個問題，其實我覺得真的挺好的啊。但這個問題，其實我也不太能夠回答。webgpu和webgl的這個事兒背后有很多政治因素，很難研究明白，主要看兩大組織如何角力。所以我的建議是去學(xué)計算機圖形學(xué)，不要把寶押在他們兩個身上。
Q23：webassembly老師講過嗎？怎么看這個東西？
A：webassembly我講過。webassembly現(xiàn)在有很多的問題，但是總體來說，我認(rèn)為是看好的。但是看好到什么程度？其實我剛才說了，我沒法判斷他會不會取代整個JS，雖然我覺得這可能性不大，但也不是沒有。總的來說，我覺得如果你認(rèn)為這個方面能夠解決你的問題，你就可以多投資一點。webassembly漲肯定是會漲，但能漲到多少錢我就不知道了，就像大家買股票一樣的。
Q24：帶前端技術(shù)團(tuán)隊的時候，如何科學(xué)的做績效評定？或者制定一種和公司員工等級獨立開的技術(shù)等級的評定機制？
A：如何評估績效這個問題，是人類有公司以來的一個千古難題。如何衡量一個創(chuàng)造性工種的產(chǎn)出，我可以介紹一下我自己的方法。其實很簡單，就是我們要保證一個初心，在你評估的時候，不要摻雜任何你不應(yīng)該摻雜的東西。比如這個人跟你關(guān)系很好；這個人他最近這個心情不好，剛分手；那個人家里困難...評估績效的時候，主要根據(jù)大家的工作量去評估，事先排好，然后再評估。你不確定的，就互相比比，看看是這個人好還是那個人好。
