其實我覺得戰場大家自己拉開的亂七八糟，
我也不過就是逐一回覆，
autocomplete 我也說了根本不是語言的重點，
是其他人重視，這樣可以說你們在討論缺陷，
我在討論 autocomplete 我也覺得是有趣。
另外，其實我回文在討論的，還是應用上的優點跟缺點，
單論「程式語言學」的優點跟缺點，
weak type 跟 strong type 本來就是各有信徒，
這個我覺得再吵十年也不會有結果，
十年前這個爭論就在，十年後恐怕還是在。
另外有些人不懂我對轉譯耗損的看法，
我只能說大家沒經歷過不需要轉譯的年代，
認知基礎是有差別的。
轉譯的差別是，es6 在很多地方都已邁入原生支援，而 ts 則否。
目前轉譯除了 import 跟 react 的 jsx/tsx 需求以外，
很多東西是可以不靠轉譯的。
而 import 如果跑在 node ，
那就更不需要轉譯，我在看的是長線規格。
我還是那句話，
沒經歷過不需要轉譯的人，很難理解轉譯的耗損。
當然老古板被認為這是吹毛求疵，我也覺得可以理解。
ts 如果有一天可以進 ecma stanard ，或是 browser native support，
這件事情會很棒，但還遠的很。
(要說的話，更希望的是 import 在 web，
能有更穩定的實作，等了十年了不知道有沒有等到。
web standard 在 loading，
包括 http2 在內一直都很有野心，
但這題大家目前共識都是把成本花在前面一次打包，
我覺得這應該還是一個過度做法，總有一天會被改掉的。)
國外抨擊 typescrip 給 developer 有 false sense of security.
多數人無法反對，而且回到最後本質，
原因還是 developer mindset。
ts 無法幫助你本質上直接上升生產力，
就跟 VAR 也沒辦法讓你速成一個專案一樣。
當你要進入一個世界，
那個世界就是有著各種不同的問題。
typescript 讓你體會一種安全跟安心感，
但那種安全跟安心感，不是真實的。
換言之，要用 typescript 不用 typescript，
我覺得是無所謂，重點是 coding sense 。
覺得 typescript 寫起來比較爽，ok go。
但別忘了他本質還是 js ，不管strong type 看起來多漂亮，
當別人要打要摸要用的時候，終究還是會出問題。
另外當 ecma script 有新的 spec ，
世界有新的 move 時，要有點耐心跟上這個世界。
有些人對這個論點可能會覺得，
啊如果 js 跟 ts 都要學怎麼寫 code，
為什麼我要特別找 ts 麻煩。
因為，js 要學的東西，
包含 callback 包含 promise async await ，
包含 error handing，fetch or request ，
避免 magic number ，避免 bad code pattern 。
更高階的要處理記憶力耗損跟運算量瓶頸。
這些東西，都需要時間關注，
使用 ts 這類工具，有時候會給新手一個錯覺是，
我就跟著使用說明書走就好。
其實包括 VAR 在內都有這個問題。
提出這個問題會讓人覺得說，好像在說這些工具都不要用，
但說真的，我覺得真正重要的是，
拿掉這些輔助跟限制，
還能寫出穩定的程式碼準則( coding principle)。
因為語言層的轉換還是會很頻繁的，
今日你覺得 ts 好，或許明日他們覺得 dart 更好。
諸如此類。
幾個不同層次的命題要分開看：
1. team :
對於 team 來說，
share type definition 是不是一個有幫助的事情，是。
但定義 type 則是個耗損，
這兩個權衡過是不是有幫助的，
這取決於團隊的平均能力。
在團隊裡面，每個要做的事情都是耗損，
但別誤會，有耗損不代表不值得做，只是要計算結果。
舉例，如果在一個只是反覆使用既有工具的環境，
如只用某些已經支援 ts 的 VAR 等核心環境，
自己幾乎不需要寫類別跟操作，
那這種耗損降到最低，結果升到最大化，自然就很有幫助。
如我前文講的，
討論這事情要看要解決的問題是什麼。
這句話老是被忽略不知道是舉不了例子還是怎樣。
但 team & code 多到一個階段，
即使是 java 這種 strong type，
我就看過印度人還是可以寫出，
methld1~7 這種莫名其妙的定義的。
這些就得用 coding principle 來約束，
事實上程式碼準則比環境要求更值得學，
但討論度從以前到現在都很低。
在這個年代很多人覺得過 lint 就是有遵守準則，
但 lint 只能處理機器語意，不能處理閱讀語意。
這幾篇你會看到我對 ts 評論者的敵意，
主要在於，當我們主觀推崇 ts 是更好的語言。
一樣的事情發生在 VAR 上，
我們引誘新手去學習這些東西，用掉他們的專注力。
學到的卻不是讓程式碼寫的更好的技巧，
而是某些高負債高學習曲線的東西。
而那些讓程式碼寫的更好的技巧，
則被埋在這些學習過程裡面。
type 這回事對老人家來說，並不是什麼太大的問題，
我們是用自己對 application 的經驗補完這些認知。
yes , 要說新手沒有這種認知我同意,
但要對老人開我們無法掌握 type 的地圖砲，
我覺得好像也是有些太有自信。
對新手，我覺得 ts 或 js ，跟著 team 用就好，
但不需要 ts 有比 js 高人一等的錯覺。
大家在處理得還是 web 的 layout/event /traffic，
戰場是 browser ，不是 type 。
browser 上的鐵律就是包含引用在內，少寫一點程式碼就是快。
所以以前大家在挑核心引用都是千挑萬選，
只挑最核心的東西，不會多拿。
這年頭因為 VAR 引入的關係，
複雜度越來越高，coding base 也越來越肥，
我還是那句話，感覺不到代價不代表代價不存在。
一個專案會多到 type 是個問題，
就過去經驗，通常是複雜度已經到真的太高的程度了。
這是一種天然的抑制器。
而這種時候通常我的目標會是降低複雜度，
來讓需要記得的事情比較少。
js 世界最煩的事情是，
前面無腦寫的爽，往往後面都是火葬場。
每一個函式把上下游看清楚，
記在心理，本來就很重要。
總之，要用不用是個人選擇，但凡事都有代價。
這裡的討論真是越來越無趣了，
都是精神論等級的，
「我用了 ts 以後，團隊的 quality 都覺得好一點了呢！」。
好好的就案例範圍分析適用性不是很好嗎？
反正黑的人就黑，反黑的人就反黑，文章會高來高去是因為，
沒有對手可以讓我們捉對廝殺進入具體的案例探討。
如果覺得沒有人看得懂，寫細節又何必？
反過來說，支持 ts 的又在這串中寫了什麼？
反駁的也都是軟趴趴的，前面拿 double 反駁的更是笑話。