尤雨溪:TypeScript不會取代JAVAScript
來源| evrone.com
譯者 | 核子可樂
策劃 | 蔡芳芳
文章轉自:微信公眾號 | 前端之巔
文章連結:尤雨溪:TypeScript不會取代JAVaScript
近日,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 編寫而成的強大介面成果。
原文連結
An interview with the creator of the Vue.js framework Evan You by Evrone
作者:Evrone
連結:Yuvt:C- Script 不會取代 JAVaScript
來源:知乎 | 學致私教