Vue作者尤雨溪：以匠人的態度不斷打磨完善Vue （圖靈訪談）

訪談物件：

尤雨溪，Vue.js 創作者，Vue Technology創始人，致力於Vue的研究開發。

訪談內容：

你為何選擇從事前端方面的工作？

其實，我本科讀的是藝術史，研究生階段學習Design & Technology，是設計和技術的混合。開始做前端的一個重要原因是，沒有人幫我把設計出來的作品放到網站上給別人欣賞。比如說設計一個網站，但是沒人幫我把設計出來的網站做出來。所以我只能自己做，做著做著就發現做網站本身也很有趣。

做網站的過程中也涉及怎麼寫出好的程式碼，怎樣把設計的作品實現出來，後來慢慢發現我對前端更感興趣，也花費了更多的時間。

前端需要跟使用者打交道，可以說，設計方面的背景其實對你的幫助很多。

肯定是有一定幫助的。

又是什麼原因促使你萌生了開發Vue的想法？

在谷歌工作的時候，我們要做很多介面的原型，要求快速上手，靈活運用。當時用的一些現有框架，比如angular，太笨重了。個人而言，我更傾向於針對我的用力做一個更輕量化的實現，同時也想做一些實驗練練手，研究一下angular到底是如何實現的。所以說，最早Vue是作為一個單純的實驗專案在做。

從2013年7開始，它的增長速度好幾次都超出了我自己的期望，我就想能不能再用點力推一把。每次再推一把，它又超出我的預期，慢慢地就變今天這樣了。

也有很大一部分原因是，我把Vue當作自己的一個作品，以匠人的態度不斷地琢磨完善它。一個版本做出來之後，我會不斷地思考打磨，到現在為止我已經重寫過兩次了。Vue每一次的增長，都會給我更多的動力繼續前行。

但是，谷歌主打angular，不會對你有什麼限制？

谷歌內部並不會強迫你一定要用什麼技術，選擇上還是自由的。當時我所在的團隊也是比較特殊，creative lab以實驗為主，強調速度。對這樣的型別專案來說，angular會引入很多不必要的限制。

就像你剛才說的，Vue的程式碼簡約，上手比較快。但是簡約跟功能其實是矛盾的兩個方面，顧到了簡約，就可能限制功能，增加工具的功能性，程式碼就難免變得繁冗。怎麼樣做到這種魚和熊掌的兼得？

英文裡面有一個詞叫Pragmatism，就是實用主義。在簡潔的同時，Vue也強調使用者實現想做事情的目的。可以說，最早Vue是非常看重這一點的，我們也增加了很多類似於方便性質的API，比如說過濾器。

在早期設計還不是很成熟的時候，我從angular那邊借鑑過來的一些功能並沒有得到充分地考量。一開始感覺應該有作用，就先放了進來。重新迭代的過程中，我發現它們並沒有那麼好，也不如看起來那麼方便。

隨著用力的推廣，Vue開始用於一些更長期的專案。這種情況下，一些短期內方便的功能變得難以維護。所以Vue在輕量和功能之間也發生了變化，從一開始的強調速度，簡單上手，到後面的注重使用者程式碼的可維護性，避免使用者自己掉到自己寫出來的陷阱裡，一直在不斷地轉化。最終的目標是找到一個比較良好的平衡點，維持簡易上手的良好體驗，同時儘可能地避免一時的便易影響長期的可維護性。

眼前利益和長遠利益同時兼顧。

對，比如說Vue 1.0、2.0每次變更、廢棄API的時候，都會有很多討論。很多時候，一些使用者表示說，這麼好用的東西，為什麼要拿掉它？拿掉它的原因，其實是，使用者用它們寫出了一些很匪夷所思的程式碼。我看了之後就覺得，如果這個東西會導致大家寫出這樣的程式碼，可能還是拿掉它比較好一些。

國外的情況不太瞭解，但是國內有一些公司，比如說美團、滴滴、餓了麼等這些網際網路公司，都開始用Vue開發專案，您覺得國外是怎麼樣一個情況？

國外的話，Vue的增長趨勢分兩塊。很多中小型的企業或者是創業公司會使用Vue開發專案。對他們來說，生產力是一個重要的衡量指標，強調週轉效率，快速投入，快速結束專案。同時，培訓新的開發者加入新專案，達到快速上手的水平也是一個很明顯的需求，在這樣的需求下，他們對Vue的採用度會非常高。

另外有一些大公司，像日本的Line還有任天堂，英國的一家大型百貨連鎖公司Sainsburry等也在大規模地使用Vue開發專案。有意思的是，美國主流的大公司，還是比較傾向於用他們自己的矽谷產品。可能源於產業文化的影響，畢竟Google和Facebook的牌子在美國實在是太響了。

Vue的成功給你的生活和技術上帶來哪些改變？

最大的影響肯定是，我可以全職開發Vue，也有了時間做2.0的重構。2.0其實是打亂原有的結構，從頭開始，重新構建，底層做了很大的改動。能夠全職開發Vue，一方面源於網上社群的捐助，一方面來自一些其他的來源，收入上維持跟之前工作時的一樣，但自由度的提高讓我可以掌控自己的時間，做自己最想做的事情。

在Meteor工作的時候，有很長一段時間我都很糾結，因為我發現我其實更想做Vue，但是又不得不做公司的事情。雖然也跟公司談過，卻沒有找出一個特別靠譜的結合方案，最後我還是決定自己出來幹。

有些技術人員被業務忙得暈頭轉向，而個人能力得不到提高，尤其是技術方面。他們就很苦惱，不知道是屈從於業務，還是發展自己的技能？

我覺得自己很幸運，可以做自己特別想做的事情。但是，我希望技術人員不要盲目效仿。Vue是一個特例，很多機遇才讓Vue發展到今天的樣子。如果沒有適當的渠道或者一定的經濟支撐的話，我也沒有辦法全職開發Vue。

最近即將上線的2.0，相對於1.0，在功能和效能上有哪些改進？

總體來說，效能方面提升了將近一倍。我們在技術細節上做了很大改動，整個渲染底層完全換掉了，Virtual DOM的採用開啟了很多新的可能，比如說服務端渲染，手動Render Function，以Vue作為執行時結合Weex渲染到原生的客戶端。2.0一方面大幅度提升了效能，一方面擴充了更多使用Vue的場景。

另外，2.0在API上也做了更進一步的精簡。2.0刪掉的API比新增的API要多。之前也說了，Vue在簡潔跟多功能之間不斷尋求平衡，所以1.0裡面的不少“雞肋”功能——既可以用這個方式實現，又可以用那個方式實現，我們狠狠心就拿掉了。

2016年State of JavaScript的調查顯示，Vue的受歡迎程度僅次於React。能否跟大家講講React和Vue在定位和內部實現方式上，有哪些異同點？

雖然兩者在定位上有一些交集，但差異也是很明顯的。Vue的API跟傳統web開發者熟悉的模板契合度更高，比如Vue的單檔案元件是以模板+JavaScript+CSS的組合模式呈現，它跟web現有的HTML、JavaScript、CSS能夠更好地配合。

從使用習慣和思維模式上考慮，對於一個沒有任何Vue和React基礎的web開發者來說， Vue會更友好，更符合他的思維模式。React對於擁有函數語言程式設計背景的開發者以及一些並不是以web為主要開發平臺的開發人員而言，React更容易接受。這並不意味著他們不能接受Vue，Vue和React之間的差異對他們來說就沒有web開發者那麼明顯。可以說，Vue更加註重web開發者的習慣。

實現上，Vue跟React的最大區別在於資料的reactivity，就是反應式系統上。Vue提供反應式的資料，當資料改動時，介面就會自動更新，而React裡面需要呼叫方法SetState。我把兩者分別稱為Push-based和Pull-based。所謂Push-based就是說，改動資料之後，資料本身會把這個改動推送出去，告知渲染系統自動進行渲染。在React裡面，它是一個Pull的形式，使用者要給系統一個明確的訊號說明現在需要重新渲染了，這個系統才會重新渲染。兩者並沒有絕對的優劣之分，更多的也是思維模式和開發習慣的不同。

兩者不是完全互斥的，比如說在React裡面，你也可以用一些第三方的庫像MobX實現Push-based的系統，同時你也可以在Vue2.0裡面，通過一些手段，比如把資料freeze起來，讓資料不再具有反應式特點，或者通過手動呼叫元件更新的方法來做一個pull-based系統。所以兩者並沒有一個絕對的界限，只是預設的傾向性不同而已。

對於一般的技術人員來講，掌握某項技術已經是不小的挑戰，自己如果可以開發出來一個新工具應該說是一種瞻望的高度。你會給他們一些什麼建議用於開發創造新的工具？

我的建議是永遠要保持好奇心。很多人可能忙於應付業務，沒有在業餘時間做任何嘗試探索，也就只能停留在這樣的一個層面。另外，可能有些東西也是不能強求的，比如說我做Vue的時候，很多時候來自自己的興趣。我並沒有強迫自己一定要怎麼樣，是自發的一種渴望，我想去把Vue做得更好，然後就去研究了。

興趣也是一個很重要的因素，就是說，如果有動力想要去做一件事情，你就儘可能地把興趣稍微拔高一點，定一個更高一點的目標，看看能不能把興趣推進一步。技術人員肯定會有自己感興趣的技術方向，大部分在某個技術領域做出一定成就的人，可能都少不了濃厚的興趣驅動。沒有興趣作為原動力的話，很難長久保持一種持續學習，持續研究的狀態。我也不知道這種興趣能不能後天培養，但是多探索、多嘗試，說不定哪天你就發現了新事物。

---

——更多訪談

---

更多精彩，加入圖靈訪談微信！