近日，Evrone與Vue.js的作者尤雨溪進行了一次訪談，瞭解他對於無後端與全棧方法、以及Vue.js適用場景的看法，還有他本人如何在工作與生活之間取得平衡。
記者: 嗨Evan，很榮幸你能接受我們的訪談。那就先從一個簡單的問題開始：您的全職工作崗位是由Patreon資助的，大多數人恐怕都沒有這樣的機會。您能聊聊怎樣在工作與生活之間找到平衡，特別是如何避免長期工作帶來的倦怠心理嗎？
尤雨溪：雖然我這份工作看似自己說了算，而且大部分時間也都是待在家裏，但我每天還是會遵照固定的時間表。慶幸我有孩子，所以只要完成了工作內容，我可以馬上陪伴家人。另外，我會在感覺需要的時候給自己安排一段比較長的假期，可能是幾個禮拜。這一點對於上班族來說可能比較困難。
記者: 厲害！Vue 3版本即將發佈，在此之後，您是打算休息一陣子，還是馬上開始規劃Vite build系統的下一個版本？
尤雨溪：我總是存着一大堆工作。在Vite方面，目前的目標就是努力提升穩定性——這是一套新系統，用戶總會在我當初的設計場景之外使用，所以我得花點時間思考項目的下一步要如何發展。關於Vue 3.1，我也已經有了一點想法。但休息是肯定的，給自己充電非常重要！
記者: 您是Google Creative Lab中的創造力技術專家與藝術史專家。在Vue項目當中，您有沒有感覺自己的數學、算法以及數據結構功底有點薄弱？在您看來，是不是隻有學習過計算機科學理論才能成爲程序員？還是說只要能寫出平平無奇但卻易於理解的代碼就可以？
尤雨溪：坦率地講，我遇到的這類問題不太多。我個人覺得Vue或者說大部分前端框架對於數學和算法專業知識的要求不算太高——至少跟數據庫比沒那麼高。我覺得自己在算法或者數據結構方面的確不強，雖然提升這方面能夠肯定會有所幫助，但想要管理好前端框架項目，最重要的還是瞭解用戶、設計出合理的API、建立技術社區並長期維護項目承諾。
我覺得編寫所謂“平平無奇卻易於理解”的代碼沒什麼不好，我不太認同這話裏隱藏的那種貶義傾向。實際上，編寫出這樣的代碼也需要一定經驗，而且好代碼的核心在於執行效率高，而不是令人拍案稱奇的實現思路。沒有接受專業的計算機科學教育當然也能編寫軟件，不過每一位開發者都應該重視專業教育背景帶來的紮實基礎。我個人一直採取比較務實的態度——先開始做事，哪怕做得不好。在做的過程中，我們會找到自己的不足之處，並確定下一階段該從哪些方面提升自己。
記者: 說得好。藉助Nuxt.js與JAMstack等技術方案，開發者得以專注於處理應用程序的前端部分，因爲後端部分只需要直接交給minimal/JS/BaaS即可。您怎麼看待這些“無後端”或者說“全棧”開發方法？
尤雨溪：我覺得這是一種強調以技術推動產品製造的開發思路。開發者們之所以選擇這樣的棧，是因爲它們正適合自己當前構建的產品類型：後端邏輯相對簡單，而前端交互更值得關注。雖然不是什麼萬靈藥，但這類方案確實非常適合特定一部分應用場景。
記者: Vue已經經歷過多次重寫。如果時光可以倒流，您會對現在的年輕人們提出怎樣的技術建議？
尤雨溪：請一定認真思考這個問題：怎麼才能更好地拆分與解耦內部模塊。
記者: 最近幾年來，我們發現JavaScript與TypeScript可以說是齊頭並進。您是怎麼看待這樣的趨勢的？是會最終向核心JavaScript當中添加某些類型，用TypeScript取代JavaScript，還是做出其他選擇？
尤雨溪：我覺得向JS本體中添加類型的可能性不大——因爲JS是一套由社區委員會負責類型設計的系統，而根據TC39委員會的運作方式來看，這事沒戲。另外，TypeScript也不會取代JS，前者只是JS的一個超集。我個人認爲，JS與TS（帶類型的超集）並行發展纔是最合理的未來方向，而且這一點在可預見的未來不會改變。
記者: Vue的用戶羣體已經超過百萬。您認爲衡量技術採用率的最佳方法是什麼？Stack Overflow問題熱度、GitHub星評以及其他公共訪問指標都不錯，但也有不少企業用戶需要在隔離網絡中工作。他們提不出多少問題，但卻實實在在在“使用技術”。我們該怎樣把他們納入到技術普及率的計算中來？
尤雨溪：對於開源軟件來說，覈定採用率確實是個老牌難題了，因爲用戶並沒有義務上報自己的使用情況。而作爲軟件作者，我們也確實沒有可靠的採用率跟蹤方法。也正因爲如此，我才覺得devtools擴展用戶數量應該作爲最可靠的指標，因爲它至少覆蓋到了全體用戶。
記者: 即將發佈的Vue.js 3中包含大量搖樹（Tree Shaking）處理方面的更新。在您看來，爲什麼搖樹處理用了這麼久才正式登陸現代框架？是因爲裏頭有什麼重大阻礙嗎？
尤雨溪：搖樹的工作機制，取決於源代碼的特定構造方式——換句話說，只有在項目起步時就在代碼編寫與API設計中考慮到搖樹機制，才能保證搖樹擁有最好的效果。而現在，我們之所以需要引入大量變更才能實現搖樹友好，就是因爲直接搖樹要麼會影響到API變更、要麼需要進行重大的結構調整（這會帶來嚴重風險）。
記者: Vue 3當中“基於函數的組件API”提案遭到了社區成員們的強烈反對。事後來看，您有哪些值得與其他開發者分享的觀點？
尤雨溪：社區成員們之所以反對，是因爲他們擔心項目管理方會廢棄掉Vue當前的（2.x版本）API，其實我們並沒有這樣的想法。作爲項目作者與維護者，我們一般會在日常工作中與熱心的早期採用者交互，而他們對於新思路的態度往往比普通用戶更開放、更積極，這也導致我們沒能對向下兼容性給予應有的重視。用戶不喜歡自己熟悉的一切被他人硬生生奪走，我已經深切理解到了這一點。
總而言之，最重要的是瞭解用戶需求。但這事並不簡單，有時候我們需要投入大量精力才能獲得可靠的需求信息。傾聽是必須的，綜合各方面訴求才能得出合理的結論。
記者: Vue 的用例範圍非常廣泛，從小型企業到中型代理機構，再到市值數十億美元的上市公司皆在其中。LV公司與美國宇航局也在使用Vue。有哪些使用Vue編寫的高複雜度真實前端案例，給您留下了深刻印象？
尤雨溪：問題在於，大多數“高複雜度真實前端案例”都不開源。我覺得要回答這個問題，大家可以多看看Vue Devtools與Vue CIL UI，雖然它們不屬於典型的面向消費者型Web應用程序，但無疑都屬於由Vue編寫而成的強大界面成果。