當我們在TypeScript和純JavaScript之間猶豫不決時，究竟該考慮哪些關鍵因素？
這些年下來，寫程式的時候常常卡在一個點，好像不少人都會掙扎：到底要單純用 JavaScript 就好，還是該考慮把 TypeScript 拉進開發流程？慢慢摸索之後，會發現兩者其實各有各的妙處。雖然選哪一個，有時候真的跟專案型態、團隊習慣甚至當下流行什麼都有關，不過如果把焦點拉回效率、維護或將來能不能擴充這些事情上，其實理解 TypeScript 跟 JavaScript 的差別還挺關鍵。
說起來也怪，網路剛開始紅起來那陣子，JavaScript 幾乎就是那種「無所不在」的存在。幾乎沒有哪個做前端的不碰它，就算後端或移動裝置也偶爾能看到它的影子。現在連物聯網搞不好都可以跑 JS。有些朋友說，只要是能跑程式的平台，大概都有支援 JavaScript 的環境。至於設計資料結構什麼的，各家瀏覽器和伺服器支援又不太一樣，有時候甚至會讓人懷疑是不是每次跨平台都得自己想辦法兜起來。
JavaScript 這語言嘛，靈活性倒是真的高，在很多地方橫著走沒問題。不過，要不要特地去學 TypeScript？這問題一直繞在不少開發者心裡頭。有時大家覺得反正 JS 到處都能執行，也不用裝額外東西。但隨著應用規模變大，一些以前沒注意到的小細節、維護上的麻煩，好像就浮出檯面了。畢竟不是每個專案都是只寫一兩個腳本檔案收工，有時企業級應用光是功能就堆了好幾倍，那種狀況下，選工具可就不僅僅只是「誰比較紅」而已。
所以啦，如果你剛好在考慮到底該往哪邊走，不妨多想一下手邊專案現在跟未來會遇到哪些挑戰。有人說，每種語言都是為了解決某類問題生出來的，而 JS 之所以到現在還能活躍，很大程度就在於它適應力夠強。不過怎麼取捨，有時得看你重視哪些層面才有答案。
說起來也怪，網路剛開始紅起來那陣子，JavaScript 幾乎就是那種「無所不在」的存在。幾乎沒有哪個做前端的不碰它，就算後端或移動裝置也偶爾能看到它的影子。現在連物聯網搞不好都可以跑 JS。有些朋友說，只要是能跑程式的平台，大概都有支援 JavaScript 的環境。至於設計資料結構什麼的，各家瀏覽器和伺服器支援又不太一樣，有時候甚至會讓人懷疑是不是每次跨平台都得自己想辦法兜起來。
JavaScript 這語言嘛，靈活性倒是真的高，在很多地方橫著走沒問題。不過，要不要特地去學 TypeScript？這問題一直繞在不少開發者心裡頭。有時大家覺得反正 JS 到處都能執行，也不用裝額外東西。但隨著應用規模變大，一些以前沒注意到的小細節、維護上的麻煩，好像就浮出檯面了。畢竟不是每個專案都是只寫一兩個腳本檔案收工，有時企業級應用光是功能就堆了好幾倍，那種狀況下，選工具可就不僅僅只是「誰比較紅」而已。
所以啦，如果你剛好在考慮到底該往哪邊走，不妨多想一下手邊專案現在跟未來會遇到哪些挑戰。有人說，每種語言都是為了解決某類問題生出來的，而 JS 之所以到現在還能活躍，很大程度就在於它適應力夠強。不過怎麼取捨，有時得看你重視哪些層面才有答案。
原文出處: https://www.kantti.net/tw/column/1520/typescript-vs-javascript
JavaScript憑什麼成為網頁開發的萬金油？讓我們聊聊它的天生優勢
說到 JavaScript，開發時不太需要搞那些複雜的環境設定，有時候只要隨手寫一段就能跑起來。有些人覺得這對於臨時要做個小功能或原型挺方便，畢竟省下不少前置作業。也有人提過，這種動態語言在處理需求還模糊、邊寫邊改的階段，靈活度表現得比某些靜態語言好上許多。變數類型、物件結構，大概隨時都能動一動，不太會有明確限制。
其實近年來 JavaScript 的社群感覺越來越熱絡，不少討論串和線上資源好像都找得到答案。大公司甚至有提供大量支援，不過細節各地可能略有差異。講到生態圈，市面上流行的那些框架（像 React、Vue 或 Node）幾乎都是圍繞著它打轉。不管是做前端還是後端，好像都有人選擇用 JavaScript 來搭建專案。有朋友跟我說，他們團隊之前在一些雲服務或者不同瀏覽器之間切換，其實沒遇到什麼特別大的阻礙。
另外，有些小案子如果時間很趕，大家普遍認為直接把程式碼貼上去運行就可以了，也不需要經過太多額外流程。有時候準備工作花費的時間可能比真正寫功能還久，那這種省事方式似乎比較受青睞。整體而言，用 JavaScript 構建東西，在某些情境下的確減少了繁瑣步驟，但每個專案適合與否還是看需求本身啦。
其實近年來 JavaScript 的社群感覺越來越熱絡，不少討論串和線上資源好像都找得到答案。大公司甚至有提供大量支援，不過細節各地可能略有差異。講到生態圈，市面上流行的那些框架（像 React、Vue 或 Node）幾乎都是圍繞著它打轉。不管是做前端還是後端，好像都有人選擇用 JavaScript 來搭建專案。有朋友跟我說，他們團隊之前在一些雲服務或者不同瀏覽器之間切換，其實沒遇到什麼特別大的阻礙。
另外，有些小案子如果時間很趕，大家普遍認為直接把程式碼貼上去運行就可以了，也不需要經過太多額外流程。有時候準備工作花費的時間可能比真正寫功能還久，那這種省事方式似乎比較受青睞。整體而言，用 JavaScript 構建東西，在某些情境下的確減少了繁瑣步驟，但每個專案適合與否還是看需求本身啦。
寫小專案飛快但做大系統就頭痛？揭開JavaScript的 scalability 致命傷
JavaScript這玩意兒，靈活度算是挺高的，但一旦專案變大，好像很多細節就會開始跑出來。曾經聽過有團隊在開發環境裡測試時都覺得沒啥問題，結果某個小組件到了正式上線才爆出奇怪的例外狀況，這其實不算太稀奇。尤其是當程式碼已經累積到幾十萬行、分工又分得蠻細，事情往往就很難說全盤掌握。
還有一點，大致上也有人注意到：因為JavaScript本身沒什麼嚴謹型別的概念，調錯過程有時候真的讓人感覺卡住。新手加入團隊，如果碰到那種變數型別亂跑或哪裡少打一個字母的情況，常常要花不少時間才能找到症結點。維護起來，好像也比預期多了不少麻煩。有些老手會拿JSDoc之類東西硬湊一個「類型標註」，但跟TypeScript那套比起來，還是有種補丁湊合、不太踏實的感覺。
至於說安全性吧，畢竟沒有明確型別規範，有時候錯誤資訊又藏得很深，不小心混進去一些奇怪資料，也許短時間內根本不會被發現。雖然偶爾有人會說「這樣比較彈性啦」，但換個角度看，好像也帶來潛在風險——特別是在那些人多手雜的大型開發案裡面。
總歸一句，JavaScript並不是完全不能用，只是在某些情境下，比如多人協作、程式碼量已經膨脹到七八倍甚至更多時，它原本的自由反而會變成一種負擔吧？
還有一點，大致上也有人注意到：因為JavaScript本身沒什麼嚴謹型別的概念，調錯過程有時候真的讓人感覺卡住。新手加入團隊，如果碰到那種變數型別亂跑或哪裡少打一個字母的情況，常常要花不少時間才能找到症結點。維護起來，好像也比預期多了不少麻煩。有些老手會拿JSDoc之類東西硬湊一個「類型標註」，但跟TypeScript那套比起來，還是有種補丁湊合、不太踏實的感覺。
至於說安全性吧，畢竟沒有明確型別規範，有時候錯誤資訊又藏得很深，不小心混進去一些奇怪資料，也許短時間內根本不會被發現。雖然偶爾有人會說「這樣比較彈性啦」，但換個角度看，好像也帶來潛在風險——特別是在那些人多手雜的大型開發案裡面。
總歸一句，JavaScript並不是完全不能用，只是在某些情境下，比如多人協作、程式碼量已經膨脹到七八倍甚至更多時，它原本的自由反而會變成一種負擔吧？
半夜被runtime error驚醒？沒有型別安全讓debug變成惡夢
TypeScript這個東西，其實也不是最近才出現的。有人說它是從JavaScript那邊長出來的，畢竟本質上兩者很像，不過TypeScript多加了靜態型別，這點讓它在一些大型系統裡好像挺有發揮空間。有段時間，討論度突然高起來，幾乎每次聊到複雜專案、要升級或維護什麼的時候，都會有人提到它。不過，如果只把焦點放在「安全」這件事，好像又太單薄。其實用了一陣子之後，有些人慢慢覺得，TypeScript可能還能順便提升開發體驗和團隊效率——當然前提是大家能習慣這套規則。
至於說優點嘛，有時候最常被拿出來講的是那種「靜態型別」帶來的早期錯誤提示。例如：你寫完一堆程式碼，還沒跑之前，有些問題就已經被找出來了。我自己以前遇過幾次那種查錯查到天荒地老的情況，如果當初用的是TypeScript，好像真的可以省下不少麻煩。而且型別明確以後，團隊裡溝通也比較不容易鬧誤會——有時候一句話到底什麼意思，用型別標註清楚很多。
另外一個蠻常聽到的觀察是：大家覺得TypeScript寫起來比純JavaScript容易懂。那些型別註解有點像簡易文件吧？你看一下大概就知道變數是幹嘛用的。相較之下，以前用純JavaScript時偶爾會一頭霧水，不知道某個物件到底該傳什麼進去。
還有就是重構啦——如果你以前玩過純JS的大專案，你應該懂那種改動代碼時心裡總有點忐忑。有些朋友說，用TS之後再修修改改感覺比較踏實，好像少了不少恐慌感。不過話又說回來，也不是所有人都馬上接受這一套啦，有些舊案子可能還是不想動。總之，大致上就是這樣。如果硬要總結，好像很難一句話講完……
至於說優點嘛，有時候最常被拿出來講的是那種「靜態型別」帶來的早期錯誤提示。例如：你寫完一堆程式碼，還沒跑之前，有些問題就已經被找出來了。我自己以前遇過幾次那種查錯查到天荒地老的情況，如果當初用的是TypeScript，好像真的可以省下不少麻煩。而且型別明確以後，團隊裡溝通也比較不容易鬧誤會——有時候一句話到底什麼意思，用型別標註清楚很多。
另外一個蠻常聽到的觀察是：大家覺得TypeScript寫起來比純JavaScript容易懂。那些型別註解有點像簡易文件吧？你看一下大概就知道變數是幹嘛用的。相較之下，以前用純JavaScript時偶爾會一頭霧水，不知道某個物件到底該傳什麼進去。
還有就是重構啦——如果你以前玩過純JS的大專案，你應該懂那種改動代碼時心裡總有點忐忑。有些朋友說，用TS之後再修修改改感覺比較踏實，好像少了不少恐慌感。不過話又說回來，也不是所有人都馬上接受這一套啦，有些舊案子可能還是不想動。總之，大致上就是這樣。如果硬要總結，好像很難一句話講完……
TypeScript如何用靜態型別在編譯階段就攔下愚蠢錯誤？
說到 TypeScript 跟原生 JavaScript，怎麼選好像還得看情境。有些人會說，JavaScript 用起來很快，彈性又夠，尤其做那種小型專案、臨時要試點什麼功能的時候，好像就蠻合適。畢竟這個語言的生態圈大得驚人，到處都有人在用。
不過，如果專案慢慢長大了——像那種開發團隊有七八個人以上的狀況，有些工程師會建議考慮 TypeScript，主要是因為它多了型別檢查，也比較容易跟 IDE 做整合。這樣一來，好像哪裡打錯字或傳錯參數，都能提早被發現，比較不會拖到後面才爆出問題。當然，也不是說用了 TypeScript 就能保證萬無一失，只是維護起來好像順手一點。
其實兩種寫法各有利弊啦。有聽過有些團隊覺得，用 TypeScript 雖然初期花點時間學，但之後程式碼維護、協作都舒服不少。不過也有人覺得純 JavaScript 比較靈活，有時候趕進度也方便。反正每個語言都有自己的限制和優勢，大致上就是根據需求跟未來可能擴充的規模去評估。
最後只能說，如果是在那種大家一起合作、而且希望程式長遠下去比較穩定，其實 TypeScript 可能帶來的幫助還蠻明顯。但這也不是絕對答案啦，每個情境可能結果都不同。有些細節恐怕還要再多觀察才知道適不適合自己用。
不過，如果專案慢慢長大了——像那種開發團隊有七八個人以上的狀況，有些工程師會建議考慮 TypeScript，主要是因為它多了型別檢查，也比較容易跟 IDE 做整合。這樣一來，好像哪裡打錯字或傳錯參數，都能提早被發現，比較不會拖到後面才爆出問題。當然，也不是說用了 TypeScript 就能保證萬無一失，只是維護起來好像順手一點。
其實兩種寫法各有利弊啦。有聽過有些團隊覺得，用 TypeScript 雖然初期花點時間學，但之後程式碼維護、協作都舒服不少。不過也有人覺得純 JavaScript 比較靈活，有時候趕進度也方便。反正每個語言都有自己的限制和優勢，大致上就是根據需求跟未來可能擴充的規模去評估。
最後只能說，如果是在那種大家一起合作、而且希望程式長遠下去比較穩定，其實 TypeScript 可能帶來的幫助還蠻明顯。但這也不是絕對答案啦，每個情境可能結果都不同。有些細節恐怕還要再多觀察才知道適不適合自己用。
重構程式碼就像拆炸彈？TypeScript的自動檢查讓你安全剪線
有些開發者在重構程式碼時，會擔心一不小心就把某些地方弄壞。可是在 TypeScript 裡頭，好像比較少人這麼焦慮。這語言本身工具挺多的，重構過程中，編譯器常常會馬上提醒你哪裡怪怪的，哪裡不一致。這樣一來，好像能減少那種「到最後才發現問題」的機率——至少在不少長期專案裡，這點算是被蠻多人提起過的。畢竟那些會一直變動、拉長時間開發的大型系統，一旦出錯可就麻煩。
TypeScript 支援當今流行的 JavaScript 特性，像 async/await 啦、模組系統、箭頭函數什麼的，大多都有了，而且還加上一些原生 JS 沒有的小玩意，比如裝飾器或 enum。說也奇妙，新版 JS 的東西，只要出得不是太突然，大概用不了多久 TypeScript 也跟著支援了，所以語言本身好像還算緊貼潮流。
工具和 IDE 部分呢？現在有些新一點的編輯器，比方 Visual Studio Code 這類，被說對 TypeScript 的支援滿到位。自動補全、型別提示之類看起來都很順手，有時候還能直接跳轉到型別階層。有的人覺得，用 TypeScript 寫程式工作起來比單純用 JavaScript 輕鬆一些，也可能更有效率。
社群方面倒是沒什麼疑慮——近幾年 TypeScript 使用者人數好像越來越多，整個生態圈也變得熱鬧。不少知名 JS 函式庫與框架都有自己的 TS 型別定義檔，所以老專案如果想慢慢導入 TypeScript，其實困難度沒想像中高。React、Angular 或 Vue.js 這三大家，目前基本上都直接內建 TS 支援，用它們做前端 UI 開發成了一種趨勢，但不是唯一選擇啦。如果細究下去，每個人的使用經驗其實都會有差異，不一定每個場景都適合，但大致上情況就是如此。
TypeScript 支援當今流行的 JavaScript 特性，像 async/await 啦、模組系統、箭頭函數什麼的，大多都有了，而且還加上一些原生 JS 沒有的小玩意，比如裝飾器或 enum。說也奇妙，新版 JS 的東西，只要出得不是太突然，大概用不了多久 TypeScript 也跟著支援了，所以語言本身好像還算緊貼潮流。
工具和 IDE 部分呢？現在有些新一點的編輯器，比方 Visual Studio Code 這類，被說對 TypeScript 的支援滿到位。自動補全、型別提示之類看起來都很順手，有時候還能直接跳轉到型別階層。有的人覺得，用 TypeScript 寫程式工作起來比單純用 JavaScript 輕鬆一些，也可能更有效率。
社群方面倒是沒什麼疑慮——近幾年 TypeScript 使用者人數好像越來越多，整個生態圈也變得熱鬧。不少知名 JS 函式庫與框架都有自己的 TS 型別定義檔，所以老專案如果想慢慢導入 TypeScript，其實困難度沒想像中高。React、Angular 或 Vue.js 這三大家，目前基本上都直接內建 TS 支援，用它們做前端 UI 開發成了一種趨勢，但不是唯一選擇啦。如果細究下去，每個人的使用經驗其實都會有差異，不一定每個場景都適合，但大致上情況就是如此。
現代IDE遇上TypeScript會擦出什麼火花？工具鏈支援簡直太犯規
說到 TypeScript，有些人一開始轉換過去的時候，常常會遇到一種不太好形容的陣痛期。尤其在規模偏小、趕進度的專案裡，環境設定這件事就有點麻煩了。雖然安裝那些開發工具本身沒什麼困難，可是第一次要調整型別、加上額外設定，其實滿花時間——甚至有人覺得那段摸索期拖長不少。也不是說每個人都會卡很久，不過對於剛接觸 TypeScript 的新手來講，那種陌生感大概幾天內都甩不掉。
還有一件事，型別系統在大型專案下確實有它的安全優勢，但如果只是寫寫幾頁的小功能，像這類案子要求速度比較多時，有時候反而會被搞得綁手綁腳。多出來定義介面、維護型別那些動作，讓部分開發者覺得：「其實用 JavaScript 直接上場更快吧？」這想法好像越來越多人偶爾會提。
至於那種型別上的嚴格限制，本意是希望減少錯誤啦，可現實中總有些狀況特別尷尬。有些解法用純 JavaScript 反而簡單俐落，用 TypeScript 卻變得複雜許多。有的人最後乾脆妥協，用上一些像 any 之類的方式繞過限制，但這樣一來，好像又失去了原本強調安全性的那層保護。所以這到底算不算問題，大概跟團隊習慣與專案需求都有關。
另外不得不提，TypeScript 畢竟還是要經過編譯才能跑在瀏覽器或伺服器上。雖說現在很多新工具把這流程包起來，不太需要自己操心細節，但總歸是一道必經步驟。在某些案子裡，那點多出來的打包編譯時間，也許對進度沒有什麼影響；可遇到檔案數量暴增或專案體積膨脹時，每次建置就可能拉長一些流程。如果只是在做臨時測試或快速迭代，這階段似乎顯得有點多餘，不少人也曾討論該不該為此額外付出精力。
其實每種技術選擇都有自己的適用情境。有觀察指出 TypeScript 在追求穩定性和結構化管理的大型系統下效果相對明顯，但當需求偏向靈活與速度、且內容較單純的開發場景，就未必每個人都認為值得投入那麼多前置準備——大家對此看法目前還挺分歧的。
還有一件事，型別系統在大型專案下確實有它的安全優勢，但如果只是寫寫幾頁的小功能，像這類案子要求速度比較多時，有時候反而會被搞得綁手綁腳。多出來定義介面、維護型別那些動作，讓部分開發者覺得：「其實用 JavaScript 直接上場更快吧？」這想法好像越來越多人偶爾會提。
至於那種型別上的嚴格限制，本意是希望減少錯誤啦，可現實中總有些狀況特別尷尬。有些解法用純 JavaScript 反而簡單俐落，用 TypeScript 卻變得複雜許多。有的人最後乾脆妥協，用上一些像 any 之類的方式繞過限制，但這樣一來，好像又失去了原本強調安全性的那層保護。所以這到底算不算問題，大概跟團隊習慣與專案需求都有關。
另外不得不提，TypeScript 畢竟還是要經過編譯才能跑在瀏覽器或伺服器上。雖說現在很多新工具把這流程包起來，不太需要自己操心細節，但總歸是一道必經步驟。在某些案子裡，那點多出來的打包編譯時間，也許對進度沒有什麼影響；可遇到檔案數量暴增或專案體積膨脹時，每次建置就可能拉長一些流程。如果只是在做臨時測試或快速迭代，這階段似乎顯得有點多餘，不少人也曾討論該不該為此額外付出精力。
其實每種技術選擇都有自己的適用情境。有觀察指出 TypeScript 在追求穩定性和結構化管理的大型系統下效果相對明顯，但當需求偏向靈活與速度、且內容較單純的開發場景，就未必每個人都認為值得投入那麼多前置準備——大家對此看法目前還挺分歧的。
新手學TypeScript真的會卡關嗎？談談那些讓人卻步的學習成本
有時候，當一個專案規模變得很大，團隊裡參與的人數也不是兩三位而已，這種情境下，TypeScript 似乎就變得不可或缺。有人說，如果開發工作是長時間持續、經年累月那種——比方說一個產品會一直做下去，不斷有人加入，又要維護又要升級——TypeScript 的型別系統和它在重構上的便利性，好像可以幫忙把技術債的風險壓低不少。這麼做，也許能讓日後維護沒那麼頭痛，錯誤率聽說也會下降。
另外，有些專案裡面涉及到的商業邏輯特別複雜，演算法算來算去，一不留神就搞混了資料格式或者傳錯參數。遇到這樣的狀況，用 TypeScript 就有機會減少問題發生。畢竟它的靜態型別，大概能在你還沒跑程式前，就先提醒哪邊可能怪怪的。
不過話說回來，也不是每個場景都非得選 TypeScript 不可，只是在那些成員很多又打算長久維運、或是規則難度偏高的系統，它被認為比較適合投入。如果只是短期小東西，也許大家還是用 JavaScript 順手點吧。
另外，有些專案裡面涉及到的商業邏輯特別複雜，演算法算來算去，一不留神就搞混了資料格式或者傳錯參數。遇到這樣的狀況，用 TypeScript 就有機會減少問題發生。畢竟它的靜態型別，大概能在你還沒跑程式前，就先提醒哪邊可能怪怪的。
不過話說回來，也不是每個場景都非得選 TypeScript 不可，只是在那些成員很多又打算長久維運、或是規則難度偏高的系統，它被認為比較適合投入。如果只是短期小東西，也許大家還是用 JavaScript 順手點吧。
什麼情況下你其實該繼續用JavaScript？這些情境TypeScript反而礙事
有時候，當只是在弄點試驗性質的小東西，比方說一個簡單的腳本或是原型，JavaScript好像就比較適合。這種場合通常不太需要後續維護，也很難說什麼時候才會考慮擴展規模，所以省掉那些設定、轉譯流程，看起來更省事。小專案裡，TypeScript帶來的那些結構和嚴謹度，有時候反而讓人覺得步驟多了些，不一定划算。
其實在某些場景下，比如伺服器端有些腳本，需要很動態去改變型別，就會發現JavaScript的靈活性挺方便。偶爾遇到那種必須在執行時調整資料型態的情況，用JS寫反倒少些阻礙，好像沒什麼包袱。
如果只是想快速做個概念展示，甚至一次性的臨時任務，大概也不會有人堅持非要用TypeScript不可。畢竟直接寫JS不用經過編譯，也不用花時間搞環境設定，速度自然快上不少。有的人應該碰過這樣的狀況，就是一切講求效率或臨時交差，那種時候大致上還是JavaScript比較順手。不過具體怎麼選，其實還是得看需求跟習慣啦。
其實在某些場景下，比如伺服器端有些腳本，需要很動態去改變型別，就會發現JavaScript的靈活性挺方便。偶爾遇到那種必須在執行時調整資料型態的情況，用JS寫反倒少些阻礙，好像沒什麼包袱。
如果只是想快速做個概念展示，甚至一次性的臨時任務，大概也不會有人堅持非要用TypeScript不可。畢竟直接寫JS不用經過編譯，也不用花時間搞環境設定，速度自然快上不少。有的人應該碰過這樣的狀況，就是一切講求效率或臨時交差，那種時候大致上還是JavaScript比較順手。不過具體怎麼選，其實還是得看需求跟習慣啦。
最終抉擇指南：根據專案規模與團隊組成來決定技術選型
嗯……怎麼說呢，選擇 TypeScript 還是 JavaScript，其實有時候也不是那麼絕對。好像大家都會討論這兩個工具誰比較合適，不過，聽一些工程師分享過自己的經驗——尤其是在處理那種結構複雜、規模不小、打算維護一段時間以上的系統，他們往往會考慮用 TypeScript，主要是因為它的型別機制能多多少少帶來一點安全感。不過話說回來，有人覺得如果只是臨時做個什麼功能，大約幾週甚至更短期內要交付的小案子，用原生 JS 反而還省事，也沒太大負擔。有時候其實連自己都分不清楚到底該偏向哪邊，只能說沒有一定要怎樣啦。有些中等規模的專案，可能就很難一刀切；但總體感覺下來，好像在時間有限又不是特別龐大的情境，多數人還是習慣直接用 JS，比較快進入狀況。當然啦，每個人的想法和經歷都不同，也有人曾經在明明只剩下不到一半工期的時候硬轉 TS，就看團隊需求吧。
