JSDocでよくね？の過激ver
綾坂こと.icon
著者ブチ切れてて草Summer498.icon
改めて言語化を試みる
たぶん、「型ヒントを得るためにわざわざトランスパイルの手間を挟む必要性を感じない」かなぁ
JSは極論環境構築なしで動くような手軽な言語なのに、そこに手間を足す意義は……？
(ブラウザはみなさんお持ちですよね、という前提)
ESMはCSP(Content-Security-Policy)があると読み込ませるために自分のドメインにコピーする必要があったようなbsahd.icon
今のところそれで十分と感じている
UIはReactをminify+bundle無しでESM読込みすると転送量が爆発するし
コメントでも指摘されているけど、JS+ESM+JSDocが何を示しているのかよくわからなかったtakker.icon
JS+JSDocはともかく、ESMがでてくるのはなにゆえ
bundlerの話か？でもそれは型と関係ないような
あとJS+JSDocはTypeScriptと(declare周りを除いて)同じことができるから、JS+JSDocを採用しているのならTypeScriptを採用しているのとなにもかわらないような
JS+JSDoc+ESMはブラウザで直接動くbsahd.icon
モジュール周り何も知らない状態で言ってるので見当違いならごめん
CommonJSは現代ではまず使わないので関係ないと思いますtakker.icon ほな違うか〜綾坂こと.icon
TSで記述するときでもESMが前提です
Node.js REPLだとCJSだったりbsahd.icon
もっと過激になると型無しのJSになったりwbsahd.icon
intellisenseやドキュメント作成目的ならこれでいいんじゃないの
少し前に出たHyper(nue.js)は型なしのJSで実装されてたwogikaze.icon これは、関心を適切に分離することを意味します。TypeScriptをあらゆる場所で使うという考え方から脱却すれば、本当に重要なことに集中できます。複雑なビジネスロジックのためのシステムプログラミング、洗練されたインターフェースのためのデザインエンジニアリング、シームレスなエクスペリエンスのためのUX開発などです。真の静的型付けは、コアビジネスロジックなど、付加価値を生み出す部分でのみ使用し、プレゼンテーション層は簡潔でセマンティックな状態を維持します。FAQ - Nue 流石にここまで型がないとメソッドの補完もできないし不便
taktamur.icon
自分は型あり言語大好きだし、TypeScriptイイネ！って思ってるから元記事読んで突っ込みたくなったのもあるけど、元記事で言わんとしている事もちょっとわかる気がした。なのでつらつらと感想文。
「JavaScriptの暴れ馬的な面を意識しつつ、楽するためのサポートだけを享受するスタイルの提案」、ってのが元記事の言いたいことかなぁと思った
以下、元記事で共感したところ
めんどくさい
node.jsを使ってTypeScriptで書こうとしたら、設定が複雑奇怪になってソースを書いてるのか設定いじってるのか分からなくなる時がある
→これはDenoとか、別の環境を触ったら印象変わるかもしれない
→少なくとも自分のプライベートでは、node.js + TypeScriptはやりたくない（めんどくさい）
テンプレートを使えばだいぶ改善されるbsahd.icon
半端
TypeScriptの型情報が実行時に消え失せるのはその通りで、Javaとかと比べると半端に見えるかも
テクニック的に回避する方法はあるけど
外部からの入力のバリデーションをちゃんとやらないと、stringにintやundefinedが混ざり込む→実行時エラー
仕様として半端になったなぁと思う箇所もある
（歴史的経緯とか他言語どうなってるとか色々と膨らみそうではある）
code:typescipt
const b:number = a4; // ここでnumber|undefinedになるのを検出して欲しかったなぁ。。 ↑Array#at()だとnumber|undefinedになるんですけどねぇ……綾坂こと.icon
ちょっと困ることはある
JavaScriptはかなりの暴れ馬な言語だと思う。
なんでも出来るが乗り手の力量が求められるようなイメージ
正直自分は乗りこなせる気がしない
TypsScript→JavaScriptにトランスバイルするパターンだと、JavaScriptの暴れ馬的性質が見えなくなって、注意ができなくなってしまう危険性はある、のかも
気軽にチェーンソーを振り回してるようにも見えるかも？
暴れ馬←それはそう綾坂こと.icon
現代JavaScriptには暴れさせずに書くメソッドが確立してきているとは思う (相対的に)平和 綾坂こと.icon
Mijikko.icon
JavaScriptもTypeScriptも双方の特徴を正しく理解していて、その上でJSを選ぶなら仕方ないと思うけど
世の中の大半はTSを知らないでJSを使う人なので、上の記事を読んで安易にJSに飛びつく人がいるとしたら如何なものかと思う
TypeScriptによる恩恵をちゃんと理解しているのに、それらを丸ごと捨ててもいい理由に一切触れていないのが謎すぎる
TypeScriptの最大の魅力は、補完、ジャンプ、インテリセンスといったIDE体験の向上ですね。
これらの魅力があっても、TSは修正コストやビルド時間が長いから使いたくないという意見ならわかる
でもそれなら複数の観点から判断基準を記載すべきであり、記事のように「TSを使うべきではない」という結論に直接持っていかれると理論が飛躍しているように感じられる
IDE体験の向上はめちゃくちゃ大事だと思うけれど、それ本当に捨ててもいいの？
コード解析がしづらくなってかえってメンテナンス性落ちると思うけど大丈夫？ 型情報を明記しないで後続メンバーへの仕事の引き継ぎちゃんとうまくやれる？ 設計書あれば全部問題ないという体で考えていない？
TSを使うとコード改修の際に型定義も変更しなければならないから、結果的に修正コストが増大するはわかる
でもそれでいきなりTSやめるとするのではなく、TSとの向き合い方をもう少し見直した方がいい気がする
単一責務原則とかで工夫して型修正の際の影響範囲を減らすとかできそうだけどな 「それらを丸ごと捨ててもいい理由に一切触れていない」のは「そもそも捨ててないから」だと思う
記事を見た感じはTSの型そのものを否定してJSに回帰しようとしているように見受けられるため、違うかとMijikko.icon
結局TSの型使ってたらJSの柔軟性は得られないので
一部だけ型定義するという話であれば、フレームワークの問題じゃなく運用の話です
(私が補完とジャンプとインテリセンスがそれぞれ何かを間違えていなければこれでいいはず)
IDE体験の向上のためにわざわざトランスパイルの手間まで足す必要性はなくない？みたいな主張をしたい
TSの型やその他機能が本当に必要かどうかの議論はあっていいと思うMijikko.icon
無ければトランスパイル時間を短縮できるメリットがあるので
ビルドに時間がかかるという話もあったけど、具体的に何のこと指してるのかまではちゃんと読んでないMijikko.icon
トランスパイルがJSDoc削除より時間がかかるなら気になるな
処理内容は互いにコードを削除するだけで双方そんなに複雑じゃないだろうから、import typeをただのimportとして書くとかやってなければそんなに変わらない気がする TSは構文解析の手間があるか
Reactなどでバンドルまでの時間がかかると言っているのなら、それはJSでも同じという話になる
tsc以外はビルド時に型を参照しない
tscは型チェックを真面目にやるのもあって激遅
てかnpmでTSのまま公開してるやつそんな無いだろうから、ライブラリやフレームワークまで含めたビルドパフォーマンスはJS/TSでそんなに変わらないはず