Vue 做者尤雨溪：以匠人的態度不斷打磨完善 Vue

本文僅用於學習和交流目的。非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/art...

訪談對象

尤雨溪，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作得更好，而後就去研究了。

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

---

——更多訪談

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