Winter | 你不知道的組件化開發:組件化的前世此生

時間 2019-11-24

標籤 winter 不知道組件開發前世此生简体版

原文原文鏈接

這個分享是由極客時間組織的微信羣內分享，本文內容前半部分是winter關於組件的分享，後半部分是Q&A。前端

Q&A部分包含諸如組件構建、GraphQL以及前端架構師等前端相關的各部份內容共25個問題，winter以他老法師的見識分享了獨到的看法。vue

關於組件

引言

今天前端生態裏面，React、Angular和Vue三分天下。雖然這三個框架的定位各有不一樣，可是它們有一個核心的共同點，那就是提供了組件化的能力。W3C也有Web Component的相關草案，也是爲了提供組件化能力。今天咱們就來聊聊組件化是什麼，以及它爲何這麼重要。node

正文

其實組件化思想是一種前端技術很是天然的延伸，若是你使用過HTML，相信你必定有過「我要是能定義一個標籤就行了」這樣的想法。HTML雖然提供了一百多個標籤，可是它們都只能實現一些很是初級的功能。python

可是，HTML自己的目標，是標準化的語義，既然是標準化，跟自定義標籤名就有必定的衝突。因此從前端最先出現的2005年，到如今2019年，咱們一直沒有等到自定義標籤這個功能，至今仍然是Draft狀態。react

不過有同窗會問：自定義標籤也不等於組件化自己啊。沒錯，不過能夠進一步思考，其實咱們須要的並不必定是自定義標籤這樣的一個形式，能夠從軟件工程的通用思想來解釋，組件化能夠拆解爲四個更基本的概念：web

封裝：組件屏蔽了內部的細節，組件的使用者能夠只關心組件的屬性、事件和方法。面試
解耦：組件自己隔離了變化，組件開發者和業務開發者能夠根據組件的約定各自獨立開發和測試。算法
複用：組件將會做爲一種複用單元，被用在多處。chrome
抽象：組件經過屬性和事件、方法等基礎設施，提供了一種描述UI的統一模式，下降了使用者學習的心智成本。小程序

咱們能夠進一步分析，其實組件化並不是前端獨有的一種需求，任何軟件開發過程，或多或少都有那麼一些組件化的需求。而你能夠思考爲何較好的組件化解決方案（三大框架）會出如今2014年左右這個時間點，這是一個回味無窮的問題。而我認爲這個問題的答案，就藏在前端發展的歷史當中。

咱們能夠看下複用、解耦、封裝、抽象這四個概念，很顯然，它們都是爲了大型的、多人協做的軟件開發所準備的。因此我認爲，2014年左右這個時間點，正是前端發展到了一個須要規模化的時間點。

咱們縱觀前端的發展歷程，開始於2005年左右，是特效爲王的時代，前端領域追逐的是炫酷的效果；到了2009年左右，jQuery開始統治前端，這時API易用性和瀏覽器兼容性是最重要的；等到了2012年移動互聯網出現以後，提供組件化方案的「三大框架」逐步佔據了前端重要的生態地位。

接下來咱們深刻具體的技術細節，看看組件化是如何一步步發展的。首先，標準的DOM元素是這樣建立和掛載的：

var element = document.createElement('div')
document.getElementById('container').appendChild(element)
複製代碼

這裏的element是一個對象，可是其實JavaScript（早期）裏面，根本無法建立這樣的對象。一方面也是咱們沒有辦法改變createElement這個函數的行爲。既然API風格無法靠攏DOM原生，那麼就靠攏JS原生吧，因此一些前端開發同窗就萌生了建立一個帶容器的對象的想法：

function MyComponent() {
    this.prop1;
    this.method1;
}
複製代碼

不過，要想掛載又成了難題，普通的JS對象無法被用於appendChild，因此前端工程師就有了兩種思路，第一種是反過來，設計一個appendTo方法，讓組件把本身掛到DOM樹上去。

function MyComponent () {
    this._root = document.createElment('div')
    this.appendTo = function (node) {
        node.appendChild(this._root)
    }
}
複製代碼

第二種比較有意思，是讓組件直接返回一個DOM元素，把方法和自定義屬性掛到這個元素上：

function MyComponent() {
    var root = document.createElement('div')
    root.prop1
    root.method1 = function () {
    //... 
    }
}
複製代碼

雖然從前端全領域來看，組件化到後期（2014年）纔有比較普及的應用，可是早年用這樣的思路實現組件體系的方案並很多，說明組件化在一些公司和領域始終有需求。雖然當時有一些組件化方案沒可以影響行業，可是不能否認它們也還算是不錯的解決方案，好比著名的ExtJS（現已改名爲Sencha），咱們來看看它的組件定義：

MainPanel = function() {
  this.preview = new Ext.Panel({
    id: "preview",
    region: "south"
    // ...
  });
  MainPanel.superclass.constructor.call(this, {
    id: "main-tabs",
    activeTab: 0,
    region: "center"
    // ...
  });

  this.gsm = this.grid.getSelectionModel();

  this.gsm.on(
    "rowselect", function(sm, index, record) {
      // ...
    }, this, { buffer: 250 }
  );

  this.grid.store.on("beforeload", this.preview.clear, this.preview);
  this.grid.store.on("load", this.gsm.selectFirstRow, this.gsm);

  this.grid.on("rowdbclick", this.openTab, this);
};

Ext.extend(MainPanel, Ext.TabPanel, {
  loadFeed: function(feed) {
    // ...
  },
  // ...
  movePreview: function(m, pressed) {
    // ...
  }
});

複製代碼

你能夠看到，這是一個徹底使用JS來實現組件的體系，它定義了嚴格的繼承關係，這樣的方案很好地支撐了ExtJS的前端架構。不過，建立和掛載對象的方式可不止DOM API，還有HTML語言，如何讓前端組件融合進HTML語言呢？

<my-component attr1="..."></my-component>
複製代碼

關於這方面，依賴早期標準的前端技術能夠說幾乎沒有辦法。可是，歷史中總有些遺珠，微軟的IE瀏覽器已經提供了組件化的解決方案，名爲HTML Component，我找了一段很是古老的示例。

<HTML xmlns:PUBLIC="urn:HTMLComponent">
<PUBLIC:PROPERTY NAME="child">
<PUBLIC:ATTACH EVENT="onclick" HANDLER="onclick_handler">
<PUBLIC:ATTACH EVENT="onmouseover" HANDLER="onmouseover_handler">
<PUBLIC:ATTACH EVENT="onmouseout" HANDLER="onmouseout_handler">

<SCRIPT language="JSCript">
    function onmouseover_handler () {
        element.style.color = "red"
    }
    function onmouseout_handler() {
        element.style.color = "black"
    }
    function onclick_handler () {
        // ...
    }
</SCRIPT>
複製代碼

這項技術提供了事件綁定和屬性、方法定義，以及一些生命週期相關的事件，應該說已是一個比較完整的組件化方案了。可是咱們能夠看到後來的結果，它沒有可以進入標準，默默地消失了。用咱們今天的角度來看，它能夠說是生不逢時。

到了「三大框架」出現的時代，由於面向的客戶羣體從少數公司、少數領域變成了廣大前端開發羣衆，也由於一些新技術的出現，讓舊時代組件化無法解決的問題有了新的可能性，這些新的組件化方案都保持了HTML甚至CSS的書寫習慣。

Vue.js採用了JSON的方法描述一個組件：

Vue.component('todo-item', {
    props: ['todo'],
    template: '<li>{{todo.text}}</li>'
})
複製代碼

還提供了SFC（Single File Component，單文件組件）「.vue」文件格式：

<template>
    <div class="example">{{msg}}</div>
</template>

<script>
    export default{
        data () {
            return {
                msg: 'it works'
            }
        }
    }
</script>

<style>
    .example {
        color: red
    }
</style>
複製代碼

React.js發明了JSX，把CSS和HTML都塞進JS文件裏：

class ShopplingList extends React.Component {
    render() {
        return (
            <div className="shopping-list">
                <h1>Shoppling List for {this.props.name}</h1>
                <ul>
                    <li>Instagram</li>
                    <li>whatsApp</li>
                    <li>Oculus</li>
                </ul>
            </div>
        )
    }
}
複製代碼

Angular.js選擇在本來的HTML上擴展，定義組件的方式也是JS class：

export class HeroListComponent implements OnInit {
    heroes: ['hero'];
    selectedHero: hero;

    constructor(private service: HeroService) {}

    ngOnInit() {
        this.heroes = this.service.getHeroes()
    }

    selectHero(hero:hero) {this.selectedHero = hero}
}
複製代碼

咱們能夠看到，現代的組件化方案跟舊時代組件化方案的一個明顯區別就是，如今的組件化方案保留了原有的標記語言部分，而且努力保留了樣式表部分。

雖然技術從舊到新經歷了各類變遷，可是組件化的核心並無變化，咱們的目標仍然是在API設計儘量接近原生的狀況下完成複用、解耦、封裝、抽象的目標，最終服務於開發，提升效率，下降錯誤發生比率。

若是你的公司和前端團隊規模正好面臨須要創建組件化體系，但願你能從今天所分享的歷史中得到一點靈感。

Q&A

1.渣渣提問 我想請問老師，組件的顆粒度什麼樣比較合適？它的包含度又應該是什麼樣的範圍？

組件這個東西，它的粒度是無所謂的，他是一個級聯的結構，因此說你能夠有粗粒度的組件，也能夠有細粒度的組件。我以爲其實替代粒度的這個概念應該是體系這個詞，即如何去設計細粒度的組件，又如何去設計這個粗粒度的組件，最後造成一個很好用的體系。我想用簡單的能夠用，想用複雜的、現成兒的、大塊兒的，也能夠用。

2.tk提問 組件化了還能作SEO麼？

其實你若是對現代的SEO有必定的瞭解的話，你會發現這個東西其實已經走到了一條徹底不同的道路上了，咱們如今不少的SEO方案是服務端專門渲染一套給這個搜索引擎去看的。可是你說組件化，若是說咱們正常的使用各類組件化的技術，他對SEO是否是會有負面影響，我認爲確定是會的，畢竟你用了一個自定義的標籤，瀏覽器是不認識的。可是，其實你們看了咱們那個重學前端的課程，就會發現其實重點不在於這些地方，瀏覽器也有專門的一些標籤兒，專門寫給搜索引擎看。

3.李小剛提問 如何避免過分封裝？

我以爲你們沒有到擔憂過分封裝的時候，你們每每會發生一種狀況就是沒有封裝。固然，這個狀態也會有一個比較危險的狀況，從沒有封裝一下，忽然發現封裝這東西很好用，而後咱們就去過分封裝了，實際上我以爲是應該去了解一些基本的知識，好比說什麼叫對象，爲何這些方法和這些屬性要聚合成一個對象，由於他有一些局部性，你把局部性這個聚合起來就是好的，你把沒有局部性的聚合起來，就拔苗助長。這只是個例子，面向對象的基本原則，其實均可以去學習一下，就不會過分封裝。

4.共性問題 組件化體系設計

其實以前，我也沒有什麼特別的理論思路，有些時候是憑感受。不事後來我有一個朋友也是前同事前下屬勾三股四，跟我說你若是作UI組件的話，能夠去參考那個web accessibility，你去看W3C的標準裏面，它基本上把你人類經常使用的組件規範都總結完了，它自己不是組件，可是去設計組件時以此爲參考是很是好的。

5.stussury_41提問 jsx作組件化後期會不會很差維護？組建自定義部分用插槽好仍是jsx？

用JSX，確定是沒有不可維護這個問題的，我估計大家的業務應該不太可能會比淘寶複雜。淘寶相對來講已是一箇中等偏上的複雜業務了，我在淘寶工做期間，使用JSX去作組件化，這個徹底沒有問題。

6.vey提問 前端微服務對比組件化，使用場景和優劣如何？

應該說微服務這個概念，它自己就是從後端來的一個純粹的概念，我還沒見過誰在前端要搞這個微服務，由於微服務這個詞對前端頁面的這個維度來講有點大，通常來講前端是沒有服務這個東西的，那就更況且說這個裏面再衍生出來微服務這個東西。微服務的主張是咱們一個服務只作一件事情，專一作好本身的這一部分。而不是去混合業務場景設計這個API。從某種意義上說，我認爲一個前端頁面，甚至有可能都不必定有後端的一個微服務大。因此我不建議把微服務引進前端裏面來。

7.lynn-上海-前端提問 請問老師，以前封裝好的組件，隨着項目迭代功能不全，如何添加功能儘可能減小對其餘使用過該組件的影響？

這個組件設計好了以後，如何去給他添加功能、如何去迭代。坦白地說，這是個難題。雖然我能夠講出不少聽起來特別有道理的理論。但事實上，曾經在淘寶發生的一件事是一個輪播最後被加了30多個參數。固然我仍是要講一下這個理論知識，咱們設計組件也是遵循面向對象的這個基本原則，對修改封閉、對擴展開放。那好比說你有新功能，你就能夠選擇繼承，或者是包裝這個組件，造成一個新的組件來完成你的新功能，這樣組件體系就會變豐富，不會有不少的麻煩。

8.關於將來的問題 Web Components | TypeScript | Webassembly

一句話講就是我不知道，這個將來的東西不太好預測。可是目前來看，我認爲這三個東西都是偏向比較積極，都是高速發展且快速落地的。可是你說他會不會真的超過現有的一些東西，他能發展到什麼程度，這個我就很差說了。那我建議這三個東西是應該積極對待，都去學一下。不必定哪一個將來就會成爲一起很重要的東西，另外，他們也確實可以解決咱們不少前端開發的問題。

9.lx提問 winter老師您好：我司正在使用GraphQL接口，請問winter老師在您的前端生涯中，GraphQL結合react進行組件化開發有沒有很棒的實例場景？

其實提及來比較慚愧，我之前在淘寶工做的時候，咱們的 GraphQL也沒有真正落實的特別好，並且據我瞭解，這個在Facebook本身那邊 GraphQL，落實的也不是特別好。我以爲這個理念特別的先進，這個叫BackEnd For FrontEnd，我以爲他是BFF的一個延伸，可是其實不多公司是這麼落實的，好比說在淘寶，其實咱們落了一個半像不像的這樣的一個東西，就是咱們那有些API，咱們能夠經過後端去寫 GraphQL來生成出來。最後你前端看到的仍是一堆數據，可是其實這個 GraphQL本來的設計不太同樣。

10.農夫-北京-前端開發提問 老師您好，在開發公司內部組件庫時，有必要去設計組件間的消息機制嗎？若是有必要，能帶來哪些明顯的優點？

其實我不太建議postMessage這樣的機制，我記得其實在前三四年吧，大概2015年左右的時候，那時候聽阿里的晉升面試，每一個人都要講一下他設計的組件體系和他中間的這個消息通信機制，有用一個消息池的、有用這個各類分發的策略的，其實這個很差，這個東西最後都會變成這個消息進了這個東西以後，你debug的鏈路就斷了，消息過去了，你不知道後面執行什麼代碼，因此我不太建議作這種直接的消息機制。但其實你看如今的Flux、Redux，這樣的東西，其實它都是一種變形的消息機制。我比較推崇的是Vue Angular的這個雙向綁定，他不徹底是一種消息機制，那麼你去操縱這個數據，這個數據變了之後，全部跟這個數據相關聯的這個組件，它都產生了一個變化，實際上這個裏面是有消息流轉的，你去看Vue的源代碼。他必定是有消息通知過來，這個代碼變了，那邊去observe這個屬性。這個其實替代了某種程度上的消息，可是他的語義化更好，他不是一個未經定義的消息告訴你，你本身去拿一個字符串去定義，而是一種給你規定好了的，這叫數據變化性的消息，甚至它規定了你應該如何響應他，我認爲這種模式可以減小開發出錯。

11.新哥~Lewis提問 有vue 頁面首次加載白屏好的方案嗎？

你看一看你是不模板沒有預編譯。通常來講，這個Vue首次加載白屏，都是由於在運行時引了那個Vue的那個調試版本，因此說致使他有加載白屏，由於他要編譯你的代碼。咱們通常來講用Vue CLI建立的都是沒有這個問題的，若是你的狀況比較特殊，我建議你直接去Vue項目裏面留言，Vue社區他很喜歡這樣的例子，你若是有這種真正意義上的會致使它白屏的案例，他會很積極的幫你去設計方案去解決。

12.共性問題頁面性能

其實在工程的角度來看，性能跟組件化實際上是兩個方向，因此說跟我們組件化沒有關係，可是能夠稍微講一下。凡是工程體系，都是要有一些監控手段和評估手段。因此你作性能的話，確定先建這個標準，可以知道這個頁面的性能怎麼樣，而後再去看如何優化。若是說你看我買了個人這個重學前端這個課，這裏面有講到一些關於性能優化的這樣的一個方法論。其實網上自己相關的知識也是不少的，細節其實不重要，網上都能找到各類各樣很好的性能優化的小細節。

13.peter提問 傳統的架構師大多數是後端過來的，相對於後端架構師，咱們前端在架構方面怎麼能最大的體現價值？或者什麼纔是一個前端「架構師」？

其實前端架構師面臨的問題，實際上跟別的架構師不太同樣。前端是零碎的頁面大量的重複性勞動，而不是傳統軟件意義上的模塊間的耦合和複雜性。因此前端架構重點關注的是複用，這個就跟我們今天的組件化很是的相關了，因此我原來帶手淘的架構組，基本上都是在作這個組件體系的事，先把複用作上來。

另外還有一點是，前端架構跟別的架構師，好比服務端架構師、客戶端軟件架構是不太同樣的，就是這咱們前端架構仍是能夠用一些工具去解決的。好比說，淘寶有一個特別重視的系統，叫搭建系統。這是咱們的工程體系裏面的很重要的一環，能夠大量的產出這種簡單的頁面，不須要通過前端，經過模板化或者是模塊化的方法。其實組件化就是複用的一個很重要的話題。

14.許凱旋提問 但是angularJS這種髒檢查模式，在一些狀況下，影響性能，有要注意改進的地方嘛？

我從他出來的第一天就在噴這個事情。不過你會看到，這個問題其實他是一個技術問題，這是由這個Angular.js最開始的這個設計者的這個技術不過關形成的。那對於技術問題，當這個東西影響力足夠大了之後，必定會有人給他解決，好比說後面這個JS標準也出了proxy。後面在Angular2上，這個問題也獲得了很好的處理。因此你去Angular社區能夠找到這個東西的答案。

15.lester-深圳-前端開發提問 老師，前端開發人員有必要向全棧方向發展麼，若是作全棧技術選擇上有什麼建議沒？

說實話，目前來看在國內全棧的市場不是特別的看好。另外，我特別不建議你去作Node全棧，不是說我看不起Node，反而是我以爲Node難。Node這個局面能夠說是百廢待興，你去拿Node作前端，看起來是一個server，其實你想把這個server真正可以跑到線上穩定且可以本身重啓，你要寫的代碼實際上是很是多的。因此只有阿里的那幾位大神，蘇千樸靈，他們在阿里能搞起一塊Node這樣的場景，其實他們也很艱難，因此我不建議通常人去往Node全棧轉。那你拿一個已經很火的這種後端語言，好比python、Ruby或者是Java，跟JS搭一下去作這個全棧，你說可不能夠，我以爲確定是能夠。畢竟手藝活，多學一門確定是好的，就看你本身怎麼分配精力了。另外就是這個全棧，是否是在市場上有足夠的崗位，如今來看全棧的崗位偏向小公司一些。或者說你本身要創業，那你搞個全棧這個是很好的。因此我以爲這個事情自己，就是職業發展以及我的的偏好問題。沒有一個放之四海皆準的規則。我也不可能給你一個建議，說你就作全棧或者別作全棧了。其實我本身也是會一點兒服務端，可是我確定不會往全棧去作，由於我以爲這個精力跟不上。

16.但願提問 電商網站，金額計算有必要先後端都進行計算嘛？

這個問題比較奇怪。我以爲通常來講是要後端進行計算的。至少在阿里咱們不多拿前端去計算一些折扣這樣的事情。這裏面的主要緣由是從這個風險上去評估的，有一些東西，好比說客戶端版本更新不上，從而形成一些優惠錯誤，可能就會產生一些資損。固然這個事不是絕對的，購物車裏的總價，你要不要到服務端去再繞一圈，那我以爲不用。因此我以爲這個仍是要分析一下具體狀況。

17.lynn-上海-前端 老師，請教一下，之前面試的時候聽面試官說，前端後期須要瞭解http協議制定規範，還有須要回設計模式甚至用nodejs成爲web全棧，這是成長必須的麼？

HTTP規範我以爲有用，可是其實你真要去問的話，你能知道幾個HTTP狀態碼？我以爲通常人不會超過十個，因此你說這個誰知道HTTP協議的細節。我以爲要求有點偏高，這不是必要的知識。可是我以爲他確定在某些時候會有用，因此從學習的角度來說我建議你學。那你說從面試的角度來說，我以爲這個是一個無理要求，由於你也不知道他要考哪兒。而後對於設計模式，其實你要知道這個設計模式這本書，他是爲基於類的面向對象來編寫的。因此說不少模式在JS這邊，早就已經要麼不須要，要麼不能用。好比說這個工廠模式，他們要解決的問題是在new的時候，class的這個東西你無法傳的問題。那實際上你說在JS裏有這個問題嗎，咱們的JS構造器就能夠看成函數參數往裏傳，因此根本就不存在工廠模式的這種需求，無論是抽象工廠仍是這個builder，仍是這甚至是不在23模式中的簡單工廠模式，都不須要，咱們沒這需求。

18.凱提問 flutter最近很火的，做爲前端有必要學嗎？

我以爲要是什麼技術火學什麼，那估計你要累死，其實最火的不是flutter，最火的是區塊鏈和AI。但你不太可能往那邊轉，去學flutter也是同樣的道理，你若是以爲這塊兒你很喜歡，你就轉過去學。可是你要知道fluter是一個全新的體系，他其實跟咱們傳統的前端開發，已經有必定的隔離了。我是認爲它會是一個小衆的東西，可是我以爲他確實作的很好，因此必定他可以有本身的一席之地。

19.pandaTsui提問 前端是否是應該有一套本身的設計模式？

有的。以前有一個比較火的石川講過前端本身的模式。可是咱們前端其實不太有像GOF四位大神同樣的這種人物，因此說咱們可能總結的模式都比較弱，這個裏面是包含個人。咱們前端仍是一個很年輕的行業，有一些小的模式微模式，其實已是很成熟的。可是達到這個GOF總結的這個23模式這種水平的，我以爲客觀上會存在，可是我以爲我們水平不夠還總結不出來。

20.共性問題 數據結構與算法

其實我以爲你們把這個數據結構和算法想複雜了，你寫For循環是否是算法，它就是一種簡單的算法對吧，那你寫這個數組他是否是數據結構，固然也是數據結構。在數據結構裏，這個玩意叫作順序表，若是你有數據結構的書，是能找到的。他跟鏈表相對，因此你去學數據結構和算法學的是什麼，這個叫作經典數據結構和經典算法。我不是特別建議你去一個一個的去啃這些經典數據結構和經典算法。可是我建議你提升本身的數據結構和算法的水平。另外一個，其實你們有些時候會把一些公司出的算法題，以爲這是不該該考的前端都不須要。在我看來，咱們大部分公司考的所謂的算法題，他都是一個簡單的小程序，咱們的代碼跟算法沒那麼容易分開，他很模糊。你說你寫一個複雜一點的小程序，他就是一個算法，你寫一個簡單一點的算法，他就是咱們平常寫的一段代碼，其實這兩個沒區別，廣義的算法就是全部你寫的只要是有邏輯的都叫算法。

21.何澤明提問 WebGL會火嗎？感受如今招WebGL的也很少，學WebGL光學three.js能夠嗎？

我我的很是看好WebGL，這跟three.js實際上是兩種東西。我以爲這塊兒，做爲一種知識儲備，能夠去作一下，固然我是比較推薦資深一點的前端，但願尋求突破的時候往這個方向去走一走。若是你本身自己在前端基礎的CSS HTML JS這些地方都沒有拿到優點的話，你不面臨瓶頸就沒有必要往這個方向去發展。由於你的競爭對手有不少，還有一堆C++大神可能對這邊有興趣要轉過來。

22.夏晗默提問 請問老師，本身公司的app 能在chrome 上模擬注入某段代碼判斷是這個app 麼，相似於判斷是微信、是支付寶仍是瀏覽器這種，由於咱們不少h5頁面都是內嵌在本身app 中的。

若是你的webview是你本身寫的，那必定是能。若是你是要到瀏覽器裏的話，這個也是能夠的。你能夠註冊一段協議，而後拉起本身的APP。打開了以後再回來，因此這個綜合的結論是能，不過大家要是打開在本身的webview裏，那就很方便。你只須要用密碼學手段註冊一個特殊的字符串進去，而後讓這個好比說跟時間有關的，而後加個簽名，而後讓網頁的代碼去判斷這個簽名就能夠了。固然大部分的時候，其實咱們沒有這麼高的要求，好比說這個淘寶，咱們判斷這個頁面。是否是在本身的APP裏面，其實咱們就加了一段UA，沒有我前面說的簽名之類的奇特的手段，由於咱們不須要這種安全性檢查，咱們只須要判斷一下是否是。就是你騙我了就騙我了，也無所謂。

23.半月含雪雨提問 WebGPU要是出來的話WebGL如今還有接觸的必要嗎？

這個問題關鍵是我也不太可以回答，就是WebGPU跟WebGL，由於這個事背後有不少政治因素。W3C應該是想推Web GPU，那他們跟Khronos這個標準化組織有一個競爭關係，因此這塊其實不是技術問題，我也研究不太明白啊，也可能沒人能研究明白。就看他們兩大組織如何較力。因此個人建議是你去學計算機圖形學，不要把寶押在他們兩個身上。

24.tk提問 WebAssembly老師講過嗎？怎麼看這個東西？

我講過這個WebAssemmbly如今有不少的問題，可是整體來說我認爲他是一個看好的東西，可是看好到什麼程度，其實我剛纔講了，我無法判斷他會不會取代到把整個JS都取代了，我以爲這可能性不大，但也不是沒有，可是總的來講，我以爲若是你以爲這個地方可以解決你的問題，你能夠多投資一點。這個東西長，確定是會長。能漲到多少錢我就不知道了，跟買股票同樣對吧。

25.peter提問 帶前端技術團隊的時候，如何科學的作績效評定？或者制定一種和公司員工等級獨立開的技術等級的評定機制？

這是人類有公司以來的一個千古難題，叫作如何衡量一個創造性工種的產出。我能夠介紹一下我本身的方法，其實很簡單。首先，要保證一個初心，就是你評估的時候，不要摻雜任何你不該該摻雜的東西。好比這我的跟你關係很好，這我的他最近剛分手心情很差，那我的家裏困難。你評估績效的時候，你根據你們的工做量去評估，另外先排好，而後再評估。你不肯定的，大家互相比比，你認爲這我的好仍是那我的好。