如果擺上一桌好菜，我立馬就會思考我先吃哪個菜，哪個菜我喜歡吃多吃點，哪個菜沒吃過我要嘗嘗，哪個菜不喜歡吃看都不會看一眼；如果出去旅遊，我也會想我去過哪裏，沒去過那裏，我最想去哪裏；如果讓我技術選型，不好意思我只是個切圖仔我不會，領導覺得該選什麽技術棧我就用什麽技術棧。
由於自己沒有充分地思考，一直依賴於領導，引發了各種慘案。
背景
時間：大約2017年前後
地點：某互聯網公司
任務：選擇前端 UI 元件庫
技術棧：Vue
2017 年那個時候的 Vue 的 Star 還沒有那麽的多，但是特別受到國內中小公司的青睞，文件是中文的，特別容易讀懂，Vue 的生態基本都是由自家維護，比如 Vue Router、Vuex 都是原班人馬去維護，這一點減少了前端們對於各種技術選型的困惑；然而與之相反，Vue UI 輪子則需要進行對比挑選了，當時就有兩大 UI 庫： IView（2016.11）、Element（2016.12） ，當時 ant-design-vue（2018.4） 還沒有出現，更別提 acro design（2021.11） 。IView 和 Element 都很好，但是當時的選擇在現在看來是否正確呢？肯定很多人選錯了，最後在一條錯誤的道路上越陷越深，留下了深深的技術債。
領導毫不猶豫地選擇了 IView，現在看來都有很多人詬病的 UI 庫，為什麽會選擇它？因為當時只有兩個選擇， 非 Element 即 IView ，留給大家思考橫向對比的機會不多。就像現在行情不好，僧多粥少，這樣往往就能夠選擇到水平更好的人才，而當時的情況就是選擇很少，橫向對比也不充分，很容易選錯，而且一旦選錯後面連改過的機會都沒有，一旦選擇了某個 UI 庫那麽就不可能重頭再來了，這也是選擇的代價，目前也沒有哪一種辦法能夠平滑在不同 UI 庫之間來回切換，所以說現在把技術選型搞透也還有幾分用武之地，如果一旦前端大一統比如說瀏覽器層面啥都給實作了的話，那個時候就真的不需要什麽選型了。
劫難
時間：2023 年
地點：某互聯網公司
主人公：我
任務：入職開始做需求
來這裏之前我從來沒有用過 IView，我當然不知道它好不好用，但是當我看到字裏行間的 render 函式時我就覺得這是 UI 庫層面出了問題吧。首先不說大家的水平如何，一個新的 UI 庫，我當然是先看它的官方文件，照著官方文件去寫，那準沒有錯吧？
學過 Vue 的朋友們都知道，render 函式就是底層建立 VNode 的函式，是一個非常底層的方法，既然 UI 庫是對基礎元件的封裝，它應該只暴露給我們上層的介面，應該將底層的一些方法封裝起來，更方便給開發者使用，當你發現 data 中有 100 行甚至更多的 render 函式時，內心是多麽的崩潰啊！
其次就是官方文件，以前我都是用Mac開發，沒有感覺，但是當我切換到Windows開發之後，我發現IView 的文件真的沒法用；IView 文件大部份為左右布局，右邊是範例程式碼，但是有時候範例程式碼超過一屏，這樣的話在Windows上就要先捲動到底部去尋找捲軸，捲動之後再劃到上面看程式碼，並且捲軸捲動的地方還有bug，非常不好用。
所以我便誕生了一個想法：能不能穿越回去幫領導做一下技術選型呢？
元件庫技術選型
時間：2024 年某個深夜
地點：家裏
任務：我要穿越回 2017 年（當時還是 Vue2，Vue2 是 2016 年發版的），改變當時的 UI 庫，但是在此之前我必須學會技術選型啊
選擇一個庫，技術團隊和官網是門面，也是第一印象 。雖然不能把這個作為決定性因素，但也很重要。
Element：餓了麽團隊，應該是屬於是名牌團隊了，IView：基本上屬於個人開發者； Element 官網做了響應式設計，IView也做了響應式，但是不支持移動端。不是說 IView 的作者不牛，而是 Element 背後的團隊太強大，所以這一波 Element 略勝一籌。
其次就是使用成本，學習成本要盡可能小，照顧到大部份團隊同學 ，不能把人人都當做技術大佬，這樣的庫當然是不成熟的，我們看使用成本就是看一些中後台高頻的元件的使用方式，接入方式是否便捷。那麽中後台有哪些高頻元件呢？
首當其沖的一定是 Table 元件 ：對於 Table 元件如何渲染，iView 和 Element 采用的是兩種思路，iView 采用的是類 React 語法，而 Element 才是采用的 Vue 的語法，為什麽這麽說，我們來看一看：
iView早期版本直接使用 render 函式渲染，這樣做有什麽好處呢？就是 能夠結合 babel 使用 jsx 語法；但是顯然這一步學習成本較高，大部份同學就直接按照官網的 render 函式去寫了，產生了很多難以維護的程式碼 ，這裏就不列舉了，一旦表格項操作較多，render 函式能夠上百甚至幾百行。而 Element 使用 el-table-column 元件來表達列，這樣做好處多多，首先 既能夠支持在模版上直接寫，也能夠透過陣列進行遍歷，靈活度較高。
另外 scoped-slots 本來就是 Vue 這個 DSL 的一個特性，這屬於充分利用語言特性的操作了。 對於 Table 元件而言，我個人更偏向於 Element 。
再看 Form 元件： ：就Form元件而言，Element 與 Iview 差不多，而且都缺少一個功能就是校驗出錯之後跳轉到第一個出錯的表單元件上，這個需要進一步封裝。
最後再看看 DatePicker 元件： ：DatePicker 元件最頭疼的一個問題就是返回的是 Date 物件而且輸入也必須是 Date 物件，隔壁的 Antd 就完美地解決了這個問題，其實這個問題也比較好解決，自己可以定義一個計算內容，然後對 YYYY-MM-DD 型別的日期進行一個轉化，但是如果元件層面就解決了那是不是更加完美呢？還是因為團隊同學大家水平參差不齊的緣故，有大部份同學不會考慮這樣轉化，每次都是直接定義一個 Date 物件，然後送出之前轉化為字串，回顯的時候又從字串轉化為 Date 物件，增加了很多不必要的程式碼。
有了這一個前提，再來看看 IView 和 Element，只有 Element 提供了這個功能，甚至還支持時間戳：
總而言之， Element 在細節的完善方面還是略勝一籌的 ，而 IView 則需要自己的進一步封裝。 看一個元件庫的使用成本，首先需要看自己使用的場景是 b 端還是 c 端，比方說文中是對 b 端進行元件庫選型，那麽可以先調研一些使用頻率高的元件例如 Table、Form、DatePicker、日期區間元件、Select、級聯元件、Upload、彈窗元件等等
可能還有的同學想要去比較一下元件庫的大小、主題客製、Star 數量、社群活躍度方面，但是依我看來這些對於是否選擇這個元件庫只能起輔助作用，真正起決定性作用的還是其使用成本的大小，也就是其元件本身提供的能力是否強大
穿越
回顧一下，元件庫選型的幾個方面：元件庫壓縮後體積、主題客製、Star 數量、社群活躍度，這幾個方面都不重要；重要的是另外幾個方面： 背後的技術團隊和官網的體驗、元件的使用成本 。帶著這些理由就可以穿越回去說服老板選擇 Element 了......
補充一點：可能本文有點事後諸葛亮了，因為頁面 UI 看起來還是 viewUI 更勝一籌，Element 界面實在是有苦難言，而 viewUI 開發體驗差這都比不上第一印象分。
作者：螞小蟻
連結：https://juejin.cn/post/7360143810599223350
