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

[TonyQ (得理饒人)]

※ 引述《as30385438 (LCH)》之銘言：
: 光是在obj後面.一下就會跑出各種method和argument/return type
: 就不知道能避免多少低級錯誤和省下查文件翻code的時間了
: 所以說用TS會拖慢開發速度的人
: 我真的不知道他是在做什麼神奇的專案需要用到諸多JS的神奇特性

        project scan 就是需要時間, 你檔案數多到一個程度, 就是慢.
        webpack 有那麼多 tooltip 再加速效能, 難道是假的.

        說真的, 這段話反過來說也是可以還給你的.
        連自己的 type 跟 convention 都掌握不好的, 是有什麼好靠邀的.


        另外 js 的 autocomplete,
        就算是十五年前我用 aptana 就有 autocomlete,

        真的這麼喜歡有 type 寫個 jsdoc 就好.
        (還是不知道什麼是 jsdoc?)


        是要多聰明才覺得 typescript 是唯一達成 autocomplete 的方法.


        而且我還是那句話, 你今天碰到 ts 世界以外的模組,
        你是要怎麼 autocomplete 跟省時間.

        你高興把自己關進籠子裡面是你的事情,
        但有些人覺得這是找自己麻煩的事情,

        不是你一句神奇專案才花時間可以帶過的.

: 相關的webpack config也只要設定一次, 何樂而不為呢

        是每個專案你都得設一次.

: 當然你可以說, 只要平常規範足夠好, 大家團隊意識夠強
: 加上每個人記憶力超凡, 寫過的每個function是做什麼的都不會忘

        不需要的

: 每個人都是完美的JS programmer不會踩到一些不該踩的坑
: 那當然用JS也不會有太大問題

        一樣是不需要的


        而且寫 ts 還是可以踩雷坑,
        不要講的好像那些 bad pattern 在 ts 可以被語言層防住.

        寫 ts 你不管好還是會有人寫 magic number,
        還是會有人濫用 any, 還是會有人亂切責任跟 function.


        就我在前端是界打滾的經驗, 前端世界要解決的問題,
        最大的挑戰一直就是毫無意義的 include,
        跟缺乏 management 的 codebase.


: 但我們都知道,
: 人 是一定會犯錯的
: 的確, TS不能解決所有問題, 但要把這鍋推給TS就有點詭異了
: 這個邏輯有點像：「反正用了也只是從30分到60分, TS真糞」

        你可以舉例的時候不要一直帶入自己的偏好嗎
        如果是我來舉例的話, 大概就是30分變20分吧, TS真糞.

        這種舉例有什麼意思嗎?


        你喜歡他可以美化他我沒意見, 但今天在討論中,
        你有辦法就舉出真的改善了什麼, 舉案例出來, 有道理的沒人會反駁你.


        但透過這種莫名其妙的比方, 甚至你原文也承認有需要更多設定,
        有設定就有編譯時間耗損, 然後你只是輕描淡寫的說你覺得代價不大.

        但我就是覺得這代價他不願意扛啊

        這什麼亞利安星球反駁法.

: TS本來就是以盡量不破壞JS原有特性下改進JS的可讀性

        嚴格來說, TS 破壞 JS syntax 的一致性,

        但他最後轉回 JS,
        所以你說不破壞JS原有特性我是可以理解.
        (廢話 轉成 js 是要怎麼破壞 js 的一致性)


        但不一致的 syntax 就會造成學習負擔.


        jsx 當初出來也被幹譙過一樣的事情, 但當初大家忍是因為這樣可以換來,
        跟 html 相關的 markup 表達, 確實有助於語意理解.

        但這件事情也不是沒有代價的, 幹譙的聲音一直也都有,
        我角度看這也是 react 遲遲無法一統江湖的核心因素之一.

: 拿any來說, 敝公司的tsconfig中是有設定nonImplicitAny
: 新寫的code中要用上any也必須給reviewer足夠好的理由
: 在prototype偷塞東西這種事情也是沒事不會做

        所以你解決問題的方法是靠 reviewer 把關啊,
        不是靠 TS 幫你把關啊, 你到底是來幫 ts 講話的還是黑 ts 的

: 除了一些很底層的模組, 例如支援mixin之類的

        see?

: 不要因一時貪圖方便造成後續難以維護
: 我認同大大說的, 的確沒有辦法控制整個世界照我們想要的規矩走
: 但這不是我們不能在力所能及的範圍內做到最好的藉口

        我個人覺得所謂的做到最好, 不是學會最屌的強型別,
        而是組織好程式用最低的成本達成目標.

        我說了, 輔助輪再怎麼樣會有輔助效果, 但他不是沒有代價的,
        有些人從一進這個世界就付出這些代價, 自然已經感覺不到代價.


        我前面幾篇都反覆再強調一件事情, 所有工具都有他要解決的目標情境,

        但 JS 世界或許現在的人不太在意,
        偶爾就會看到一些明顯沒這種知識的 application,
        程式碼的組織跟程式碼的龐複程度還是嚴重的影響到下載速度跟體驗.

        特別是 client rendering 的程式.


        今天如果我們談的是 web base 的 ts code,
        跟我們談 node base 的 ts code, node 我會覺得還好,

        web 我就覺得有點浪費.


        我們討論到這裡, 任何一個可能的專案情境都沒舉出來,
        我實在是不知道我們在談什麼.

        我今天談的不是 TS 有多糞,  而是沒掌握 JS 的人到底有啥好說 JS 糞的.


        這當然是個戰文, 但我就想看有多少人可以戰這個議題, 然後講得周全.


        對 TS 的優點講來講去就是 type check,
        剛有個推文寫了,  無法明確定義 type 的是不好的工程師.

        不好意思, 問題被錯置了, 誰跟你說無法定義 type,
        是不需要用這種方式定義 type.

        用相同邏輯, 我才想問,
        不靠 TS 就搞不清楚 type 的, 是能當什麼工程師.


        我從還沒 typescript 的年代就寫了很久的 js 了啦,
        如果今天我們是在 ES6 class 還沒出來的年代,
        (這是當年 typescript 最大的賣點),


        這些倡議我都覺得有些道理, 這個年代,

        我們再用能 autocomplete 來說明這件事情,
        我也是會想問, 啊是寫了多偉大的東西. 需要這樣才能做好.


        命題是想談新手好上手, 還是要談老手(我)對 ts 跟 js 的理解,
        這些最好是講清楚, 不然被開群嘲我也不知道該怎麼救.


        這世界上自以為自己是進步的人很多, 當年 rails 喊的多紅,
        其實 typescript 也曾經吸引過一票人, 後來那些人多數都退坑了.

        這次到底是再來一次, 還是能長久, 我倒是樂於看戲.


        不要急著以為別人都不知道這些事情, 我們是看著規格一路發展過來的...

--

      網頁上拉近距離的幫手              實現 GMail豐富應用的功臣   

        數也數不清的友善使用者體驗      這就是ｊａｖａｓｃｒｉｐｔ

                                                歡迎同好到 AJAX 板一同討論。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.61.209.201 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1605508606.A.97B.html
※ 編輯: TonyQ (210.61.209.201 臺灣), 11/16/2020 14:41:57
推 SmallpTsai: 推這篇
噓 lturtsamuel: 你寫程式只顧自己的type跟convention?都沒有別人的?
team 要有一套自己的 type 跟 conention 啊。
不然咧，使用 ts 也是一種 team principle 啊。
推 netburst:
※ 編輯: TonyQ (61.231.44.97 臺灣), 11/17/2020 10:11:36
推 dophin332: