近期VUE做者尤雨溪發文闡述了Vue 3的設計過程,其中專門用一段落說明了切換到TypeScript開發的緣由,尤大也在不一樣場合屢次提到了TypeScript的優點,並總結說「真香」。前端
簡單來講,VUE 3使用TypeScript做爲開發語言有如下幾點:vue
關於TypeScript的優勢有太多文章了,這裏只從SpreadJS項目實際講講SpreadJS爲什麼選擇了TS,以及TS爲SpreadJS帶來了什麼。程序員
其實早在TypeScript還在RC版本時,SpreadJS團隊已經使用TS了。當時在Visual Studio使用TS的確是爲了讓.NET 程序員寫JavaScript,同時因爲歷史緣由SpreadJS的早期一部分代碼是直接從Spread .NET 版本移植而來,不少.NET代碼複製過來就能用,節省了很大的遷移工做量,也保證了遷移到前端的代碼質量。可是因爲早期TS編譯出來的JavaScript代碼過於冗餘,致使SpreadJS發佈包過於臃腫,同時從.NET遷移過來的代碼並不符合前端JS的風格,在開發人員的反對聲中,SpreadJS用純JavaScript進行了重構。設計模式
切換到JS後架構團隊仍然對TS持續關注,隨着TS的升級優化,項目構建工具的優化,團隊能夠有效的控制TS編譯成JS代碼的大小,SpreadJS在V11 SP2從新擁抱TS。安全
SpreadJS再次選擇TypeScript做爲開發語言主要有如下幾點:閉包
「類型系統對於SpreadJS這種規模的項目是十分必要的」!和VUE的緣由同樣,重構在開發過程當中時刻發生,在靜態類型檢測的支持下調整一個模塊中接口或者屬性名稱變得十分安全快捷,同時有Visual Code的配合,屬性或者變量改名只須要一個F2進行rename便可完成。架構
SpreadJS是多團隊模塊化開發,一些基礎模塊多項目共用。靜態類型的API對開發和最終用戶都是友好的,每次爲了糾結接口中options是否帶「s」而去查詢文檔對開發人員是十分痛苦的,有了Interface,不須要開發文檔開發也能夠方便的使用基礎模塊。框架
SpreadJS的設計是面向對象的,咱們經常使用的Picture是從FloatingObject繼承,CellType中有核心的基類Base CellType。在前端項目工程化的過程當中,OOP和設計模式的使用是必然的,TypeScript讓這些都變得更加簡單。舉例來講,屬性、方法的做用域對於組件開發是很是重要的,在JS中封裝私有變量須要使用閉包,大量的閉包在代碼中十分不友好,而在TS中直接使用private修飾符便可。frontend
首先我實現想不出不用Visual Code的理由,再加上VSCode對TS的深度支持,以及Chrome支持TS的直接調試,一切都變得瓜熟蒂落。模塊化
看起來SpreadJS使用TypeScript的理由十分簡單,固然也有其餘緣由,但正是這些簡單的理由讓SpreadJS的開發團隊效率提高了40%,項目更易維護,模塊功能更易拓展、測試。SpreadJS在開發過程當中經歷了JS和TS的相互切換,用實踐證實了TS對項目帶來的積極影響。
固然任何事情都有兩面性,那麼對於不用TypeScript的幾個常見理由SpreadJS是如何解決的:
做爲SpreadJS的開發,ES6須要學習嗎,OOP須要學習嗎,設計模式須要學習嗎?都須要,那TS還難嗎,學不會嗎?
SpreadJS項目須要靜態的類型檢查!
的確如此,項目投入了一個迭代週期進行TS的重構,可是這樣作是值得的。當時,TS已經嚴格遵循 ECMAScript 規範,同時自己項目面向對象的設計,在轉換過程當中無需大量的設計重構,更多的是類和接口的聲明以及類型的轉換,來消除掉編譯器提示的錯誤。
過去多是比較大的問題,可是隨着社區生態的創建,流行的JS庫都有@types的支持,Babel 7也支持了TS。好比SpreadJS使用到的jszip和pdfkit都有對應的d.ts。若是您想用的庫還沒TS的支持,那可能它好久沒人用了。
總結來講,若是您在開發像VUE、SpreadJS同樣的底層框架或者基礎組件;使用三大框架開發SPA項目;項目由多團隊分多模塊共同開發,那麼是時候擁抱TypeScript了。