Re: [討論] 請大家聊聊 JavaScript的缺陷

[TonyQ (得理饒人)]

其實我覺得戰場大家自己拉開的亂七八糟，
我也不過就是逐一回覆，
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 反駁的更是笑話。



-----
Sent from JPTT on my Google Pixel 3 XL.

--
        虛實之間的世界，反抗軍與啟蒙軍的交集
                 帶著 Android 去旅行、去發現

                            在身邊渾然不覺的  另一個世界。
                          全世界，都是我們的  足跡與遊樂場。
        ~  The world around you is not what it seems. ~ http://ingress.tw

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.44.97 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1605577598.A.805.html
→ stopcrying: ts並不阻礙人學習你認為重要的哪些技能，不提那些奇怪
→ stopcrying: 陌生學術名詞，型別系統反映了一種拆解問題的思路ㄚ，
→ stopcrying: 有型別沒有型別的語言都要會，怎麼可以吵那麼多篇
人的學習時間是有限的，你學了 A 就會延後學 B 的時間，我只是在點出這件事情。

當然要說長期來看都是要學的，
這點我沒意見，但不是只有這個方法可以學。

「標示」型別系統只是拆解問題的一環。寫 js 還是有型別，不會因為寫 js   就不寫型別。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:08:20
→ testPtt: 搞不好以後web不再傳文字html,js全部不支援
確實也是有可能，不排除。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:12:03
噓 alihue: 凹
樓上黑的真認真，凡是你不同意的，寫再多字都是凹對吧呵呵
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:22:49
噓 CoNsTaR: 我通篇看下來，你除了講話大聲態度強硬和敢操弄語氣嘲諷
→ CoNsTaR: 人以外
→ CoNsTaR: 論點和打太極拳胡扯有什麼兩樣？
討論區人人得而回之，咬我啊～
→ CoNsTaR: 東扯西西扯東，最後再總結 js 沒問題 js 好棒棒
→ CoNsTaR: 自己這樣扯都不會心虛嗎？
不會啊。
→ dreamnook: 支持ts的感想真的就是單純減少火葬場…XD
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:31:46
噓 alihue: 討論到最後就是貶低別人 認為自己才是真理  沒必要認真跟
→ alihue: 你討論
嗯嗯，免戰牌掛的真溜。沒人不知道你避戰了。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:32:20
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:32:47
→ strlen: 沒有 今天是因爲主角是JS才戰得起來 換成python Java c++
→ strlen:  是沒什麼人要戰的 每個語言當然都有缺點跟弱項 但JS真他
→ strlen: 媽太扯
java 還是有 scala/groovy 之爭啊，人多就會有派系。XDD
→ lturtsamuel: vue跟angular都不用轉譯嗎 在三框架出來前大家難道都
→ lturtsamuel: 不做uglify嗎
uglify 不會在開發期做，我們這裡討論的是「開發成本」。
我以為我前文已經寫過，這篇就沒特別寫了.....

另外 react 因為xml 的 spec 轉譯成本特別高(不少)，以上說明。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:42:12
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:44:27
→ strlen: 那你發一篇s/g有什麼缺陷啊 肯定沒人理你 因為沒人用 哈
應該還會有幾個老人講，馬的我用 java 就好，陪你們搞一堆 groovy 跟動態類別，在那邊吃我的 meta class 空間。XDDD
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:47:11
→ lturtsamuel: angular在html寫一堆js你跟我說成本比較少...？
開發時降低轉譯成本，在瀏覽器有增加運算成本。
兩個成本誰高誰低各有見解，但兩個是不同的東西。
推 ldkrsi: 因為提到了現代programmer的政治不正確的點 所以反彈
→ ldkrsi: 特別大wwwwww
→ lturtsamuel: 我以為重點是轉譯製造的複雜度和設置成本 開發途中其
→ lturtsamuel: 實增量編譯都不會多慢 你專案如果大的增量編譯還慢到
→ lturtsamuel: 靠北 那是你專案架構的問題 不會因為捨棄react就變好
增量編譯不慢，但除非你程式永遠不 shutdown ，不然你還是得處理中間的編譯成本。

我們對開發時間是很敏感的。

至於你說專案肥本身會影響編譯時間，沒錯，但增加一個不小的乘數一樣會讓總數變大。

網路上不少脫離 ts 的討論抱怨的都是 compile slow 。

我在提醒的是這個部分。
噓 for5566: 程式語言的發展方向就是往把成本損耗轉到機器上讓開發者
→ for5566: 更容易用的方向走啊，一直在講轉譯耗損怎麼不會去寫組合
→ for5566: 語言？或直接2進位，保證耗損最低
更容易用應該也包括開發時間的降低，我從頭到尾在意的都是「開發時間」。

後期語言的目標跟策略，根據目的不同，但多數語言都有在降低開發時間這點試著做出各種

討論開發時間本來就是高階語言的目標跟特性之一，重點是你要解決什麼問題。

如同我在我最早回文第一篇的第一行跟第一行，先定義問題。
→ BoXeX: 其實就前端被強迫用js  爭議才那麼大  就算用啥ts的也不可
→ BoXeX: 能不學js   所以討厭js的我直接不寫前端  完美
→ testPtt: 我直接學blazor
噓 yeurus: 而且還說大家都沒經歷不需要轉譯的時代，哪來的自信？不需
→ yeurus: 要轉譯的時代不就搞了個jQuery來解決API不相容問題在，現
→ yeurus: 在jQuery呢？
jQuery 就我印象所及，沒有讓我每次啟動專案都要等兩秒以上的編譯時間啊。

jQuery 就下載成本跟 eval 成本，再搭配普及到翻的 cdn ，拿來跟webapck 搭配 tsx 比?


另外 jquery 是為了 browser 的一致性，不是為了讓你寫起來可以組織更大的程式碼。

(好啦 jquery plugin 那段勉強算，但當年的契約也非常嚴格，基本上是不想要疊太多層。)

早期真要說的話，大一點的專案，會 merge js 跟 ugly ，但 again ，這些是在 production layer ，client layer 還是用 require 之類的非同步載入方案處理。

後來 require 跟 common js 在 node 插手以後的大一統就先不論。

但今天討論的是開發體驗，降低開發時間的耗損跟取捨，一直是個重要課題，不能草率的假設有耗損也沒關係，
也不是說有耗損就一定不能用。


而是每件事情都有代價，算清楚代價划不划算。

※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 11:34:37
推 x123356: JS很爛(X) 爛的人寫什麼語言都爛(O)
→ yeurus: 你是看不懂嘲諷？不需要轉譯的jQuery這麼好，怎麼大家都不
→ yeurus: 繼續用？現在三大frameworks哪個是不需要轉譯的？而且處理
→ yeurus: API相容性問題主流也變成babel了
轉譯成本不一樣啊，我原文要講的一直都是轉譯換來的代價是什麼。

然後你沒發現我只挑 jsx 出來講就是因為他的轉譯成本特別高。

但我還是寫 react ，因為他的元件架構我最認同寫起來對我最快，整體可以降低成本。

講有損耗這種算的出來的東西，也要這麼囉嗦。

別的不談 babel 你 polifill 到哪一板，就會嚴重影響編譯時間了。

哪個團隊不是在這類編譯成本的降低煞費苦心。

你說代價你願意付我沒問題，
你說大家都在付所以不是問題，我就想問，你的時間不是時間嗎？

→ x123356: 以為強型別語言就都沒事的人真的滿幸福的
→ strlen: 就是不是沒事 大家都有事 JS事特多
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 11:40:56
→ iterator: 若在80年代,比起C語言,你應該是大聲疾呼組合語言那派的
→ iterator: 若在90年代,比起C++,你應該是大聲疾呼C語言那派的..
不會啊, 在 2020 年我還是推 react 啊, 只是不推你 ts.

在 2008 年我推 jQuery (2008 coscup 演講), 在 2011 年我推 require (多場 meetup),
2012 年我推前端專職化(JSDC), 在 2014年我推 react,webpack, polymer. (jstw)

2014 年我就在用 react 寫 SSR.

我也會推有理想性進步性的東西, 只是你的進步跟我的進步不一樣而已.

重點還是 cost & revenue.

噓 meowyih: 雖然你叫人咬你, 但網路上咬不到, 所以噓一個, 說真的你
→ meowyih: 是不是真的太閒了啊? 一頁15篇文有5篇是你的 = =a
歡迎噓, 但大家都不發文怪我囉,
你發一篇文把我的文章擠出去, 我就少一篇啦.

你們寫文章可能很難吧, 我信手捻來都文章呢. 更何況裡面還有一篇別人灌水的. XD
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 12:13:43
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 12:14:12
→ king22649: 最近確實很頻繁
→ iterator: 那時候也都有類似的說法, 其實是差不多的.
→ iterator: 當然論點也都有他的理由, 也的確都說得通
推 superpai: 編譯時間你買 M1 就沒了，根本不需要在意
這個理由我十年前買 SSD 時就用過了 用了十年SSD了現在對這些細節還是很敏感啊(怒)

→ stopcrying: 不幸身為全能接盤俠，legacy js code 清不完，薪情沒
→ stopcrying: 你好，下班還要自修 PL ，哪有時間寫文章 lol
→ gn01838335: 我覺得你的損耗論點要不要補充一下。你很多是主觀認
→ gn01838335: 定，並非軟體工程類的認知。人月神話，軟件工程之類
→ gn01838335: 的都和你相反
→ gn01838335: 重構這本書也是
你可以寫你的論點是什麼, 但舉幾本書好像不算論點.
這幾本書我都不是沒讀過, 你要不要明確的指出是哪一章的哪一個論點衝突.

※ 編輯: TonyQ (210.61.209.201 臺灣), 11/17/2020 13:10:54
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/17/2020 13:11:53
噓 CoNsTaR: 要你提出論點什麼都講不出來，反而反過來要別人舉例
→ CoNsTaR: 這不是 csfgsj 的招式嗎？你怎麼可以偷用
我文中的例子舉的數量，
比這串人所有提到的總數還多。
※ 編輯: TonyQ (223.137.174.34 臺灣), 11/17/2020 13:40:52
→ CoNsTaR: 可能我資質駑鈍，只看到自說自話從東講到西又講回東，觀
→ CoNsTaR: 察舉證分析結論通通沒看到，大概是我的問題吧 Q
我也覺得是你的問題，看起來我們有共識了。
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 14:20:38
推 s106667: 推
→ samuel1988: 重構就很大部分強調type的重要性你把type當耗損論點
→ samuel1988: 哪來的？
重構強調 type 的重要性，關標示 type 有成本屁事。
紅綠燈很重要，代表蓋紅綠燈不用錢喔。
紅綠燈很重要也沒每個路口都蓋啊。
※ 編輯: TonyQ (223.136.191.168 臺灣), 11/17/2020 19:53:39
噓 Lushen: 還小的時候覺得你蠻厲害的
孩子，該長大了(< 這是你想要的回應嗎？)
→ Lushen: 到 30 以後的表現還是只有自己休學可以拿來說嘴
→ Lushen: 以自我為中心的人 QQ
如果你可以舉得出 ts 超棒棒的情境，
你就比我厲害了。

我寫文分享從來就只為了寫給有興趣看的人，
不是讓人覺得我厲害的 。

你們看我文我沒收門票錢，
自然也不用付你們評論費，你說對吧。

看的不爽，寫篇好一點的反駁，
好歹我文章寫的出來，你的文章還在路上。

社群討論是用不同意見論戰的，不是用嘴炮回文的。

噓 Lushen: 問題從來不是你爽就好 事實就是需要團隊合作
對團隊合作這幾個字，你們實踐在哪我不清楚，
但這幾年我的心思倒是都在這幾個字上了。

就是因為重視團隊合作，才更需要一套可以快速訓練上手的 principle，
而不是語法蜜糖。

說 ts 就可以讓舊人避坑，照這說法，
csharp 跟 java 不就都沒坑了。


→ Lushen: 你寫 JS 很久可以熟各種 best (坑) practice 好棒棒
→ Lushen: 重點是你很難短時間教會一個新人所有 JS 遺留下來的坑
是你做不到或放棄做到，別假設我做不到。
→ Lushen: TS 的編譯器可以教你做人 帶團隊這麼久還不明白(?
我覺得是你帶團隊不夠久才不明白，能教會大家做人，
可能 pornhub 都還比較有貢獻一點。
TS 的編輯器會讓你以為自己避開了這些坑，直到你再度的踩進去。

→ pttworld: 下面幾篇谷歌臉書微軟文跟這裡比較真是諷刺啊
→ stopcrying: 欸，你崇拜的 capita 在學 Rust 、跟青年人打成一片，
→ stopcrying: 你在這裡跟人戰工具與慣例，還要抓圖曬在 fb
是說先不說小明我對他評價高的從來也都不是他的開發技巧,
啊是說這裡的人討論事情是怎樣, 好好的講話是不行嗎?

動不動烙年紀, 烙朋友, 烙經歷, 啊是回不了正題了是不是.

such a good response . 有夠有格調的回應.
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/18/2020 13:50:50
噓 alihue: 你的回應一直貶低別人和硬凹不就超有格調?
我一向習慣在戰場上用別人的招式跟對手辯論.

啊一個一直嚷嚷著不用認真, 躲在旁邊噓文,
連這蠢浮點數都要瞎跟的......

不是我要貶低誰, 而是......
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/18/2020 19:25:53
推 lemontea0328: JS很爛(X) 爛的人寫什麼語言都爛(O)
推 dophin332: 謝謝分享