Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
    2022/04/06 12:07
  
  
    mizchi
  
  
    書いた
  
    2022/04/06 12:17
  
  
    potato4d
  
  
    わかる〜〜って感じの話を良い感じに言語化してくれていてすごく良かった
  
    2022/04/06 12:43
  
  
    gonta616
  
  
    ふむふむ
  
    2022/04/06 12:44
  
  
    dfk3
  
  
    最近はnodejsで遊んでいるが、javascriptを使って非同期処理、コールバック、ハンドラ登録を組み合わせると、変数のスコープとか寿命とかの把握が極めて難解になる。
  
    2022/04/06 13:37
  
  
    berlysia
  
  
    "政情不安によるサプライチェーンアタックの現実的なリスクの高まりによって、ライブラリ間の依存はより減っていく方向に進むだろう" これがちょっと注視してるとこだなあ
  
    2022/04/06 13:37
  
  
    fukken
  
  
    "現状、モダンな JS のプロジェクトで苦労するのは必ずといっていいほど webpack, eslint, jest, typescript(tsconfig.json) の設定の組み合わせである" npmパッケージの依存先のパッケージとか、いい感じに重複排除して枝刈りしてほしい
  
    2022/04/06 13:39
  
  
    rgfx
  
  
    はい
  
    2022/04/06 13:46
  
  
    kako-jun
  
  
    "よく練られた TypeScript の型を提供してあるライブラリをみんなが使うのが一番安定したTSの使い方で、それが機能しているのが React 界隈で、機能してないのが xxx" ←私もそれが理由でxxxからReactに乗り換えてしまった……
  
    2022/04/06 14:15
  
  
    n314
  
  
    何年か前に、JavaScriptのデファクトスタンダードがコロコロ変わる時代は終わって今は定番が決まっているという記事を読んだ記憶があるんだけど、それももう終わったのかな?
  
    2022/04/06 14:39
  
  
    otoan52
  
  
    最強ポジションだけど、なんだかんだ課題は多いのよね。堅い方はRustが次世代のポジション築いてる感じするけど、柔らかい方はTSがスタンダードに成ったばかりの段階で次は見えてない。と思ってる。
  
    2022/04/06 14:43
  
  
    sudow
  
  
    “というわけで、TypeScript がよくて、 npm が混乱期で、Deno は負債をまだ被っておらず、 wasm は特定ユースケースを除いて選択肢にない、という現状です。”良いまとめ
  
    2022/04/06 15:05
  
  
    circled
  
  
    一昔前はcoffee script、今はTypeScript。ここから導き出されることは、、、みんな本当はJavaScriptが嫌いなのに使っていると言うこと。
  
    2022/04/06 15:22
  
  
    ultimatebreak
  
  
    内容よりもよく書けるなあこの文章と関心した
  
    2022/04/06 15:36
  
  
    isdh
  
  
    最近は歌を送り合うのが流行りっぽいので平安時代
  
    2022/04/06 15:56
  
  
    yarumato
  
  
    “フロントエンドwasmメインは10年後に30%と見る。まだ選択肢にない。TypeScriptは、よく練られた型を提供してあるライブラリをみなが使うのが一番安定した使い方で、それが機能しているのがReact界隈”
  
    2022/04/06 16:23
  
  
    pwatermark
  
  
    だいたい同じ感想で、Denoがどう転ぶかによって世界が変わる可能性があるのでDenoを脇目に追いかけつつ、Rustを勉強し始めた所
  
    2022/04/06 16:35
  
  
    zyzy
  
  
    自由度がある分結局型をちゃんと使ってくれる文化圏を選ぶ必要性があるという
  
    2022/04/06 17:34
  
  
    xlc
  
  
    実装する側としては枯れているものを使う。私はCJSで十分で何の不満もないです。EMSが安定したらそのとき声をかけてくださいな。だいたいnpmにあるモジュールだってclassではなくprototypeなヤツがまだ主流だもんな。
  
    2022/04/06 18:09
  
  
    baronhorse
  
  
    “政情不安によるサプライチェーンアタックの現実的なリスク” 大袈裟笑
  
    2022/04/06 18:13
  
  
    jsoizo
  
  
    “現状、モダンな JS のプロジェクトで苦労するのは必ずといっていいほど webpack, eslint, jest, typescript(tsconfig.json) の設定の組み合わせである。” romeに頑張っていただくしかないな
  
    2022/04/06 18:14
  
  
    kabisuke
  
  
    フロントエンド側の人からすればromeが目指した世界を渇望してるんだけど、denoがなんとかしてくれそうでしてくれなくてまだかな〜となっている。。。アプリに集中したい。。。
  
    2022/04/06 18:47
  
  
    als_uz
  
  
    ROXまつり湯もいいですよ
  
    2022/04/06 19:06
  
  
    kxkx5150
  
  
    なんかマンネリ感あるなら、新しい言語やるとすごい勉強になる。関数型ならOCamlで入門してHaskellとか。rustはrust-analyzerが頼りになるしおすすめ。rustは参照を持った構造体でライフタイムが出てくるのが第一の壁だと思う。
  
    2022/04/06 19:10
  
  
    zgmf-x20a
  
  
    ラプラスの箱みたいなもの?(違
  
    2022/04/06 20:14
  
  
    fn7
  
  
    CoffeeScript懐かしい。
  
    2022/04/06 20:22
  
  
    oooooooo
  
  
    “webpack => vite jest => vitest prettier => deno fmt eslint => deno lint typescript(解析以外) => esbuild”
  
    2022/04/06 20:49
  
  
    Ryo_K
  
  
    “他人のコードを型が通ってるから信頼できるかというと、できない。そういう言語であると思う。熟練度がそのまま安定性に直結する”
  
    2022/04/06 21:22
  
  
    srng
  
  
    こんなにTS全盛になるとはなあ。MSがTS出してきたころは皆は結構馬鹿にする人が多かった印象
  
    2022/04/06 21:40
  
  
    nicht-sein
  
  
    わかるわかる、と読んだけれど、きっとこの方の技術力は私なんて足元にも及ばないほどの高みなんだろうなー、「わかるー」なんてノリで読んじゃいけなかったのかもとか思いつつ思うだけ
  
    2022/04/06 22:22
  
  
    koba789
  
  
    だいたい同じ感想。流石の解像度という感じ
  
    2022/04/06 22:24
  
  
    udzura
  
  
    “10年後に 30% ぐらい” 想像より高い確率の見積りだ…
  
    2022/04/06 22:25
  
  
    gabill
  
  
    Web Componentsの普及によって既成のUI部品の使い回しが容易になり抽象化が進めば、そもそもフロントエンドに複雑さがそこまで必要か、みたいになんないかなぁ。フロントの痛みの多くはUIの再発明にあるような気がする。
  
    2022/04/06 22:25
  
  
    weakref
  
  
    トレンドばかり追うと技術的負債が増えるという当然の結果。そして、技術的負債を作りこんだ戦犯は大抵退職している。
  
    2022/04/06 22:31
  
  
    mattn
  
  
    js/ts 界は新陳代謝を体現するプラットフォームなので傷んで行くものに慈悲はない。
  
    2022/04/07 00:26
  
  
    hdampty7
  
  
    柔らかすぎると大きなものを組めないからTSで硬くして使うっていう今のフロントの現状は滑稽だけれども、硬けりゃ加工にそれだけコストがかかるという物理世界と同じなんだろうなぁ、そこら辺は。
  
    2022/04/07 00:45
  
  
    carrier_pigeon
  
  
    フロント界隈って過去の良い技術(railsのcocとかgems、型付けetc)を無理やりブラウザ(JS/HTML)に持ち込んで動かそうとしてイケテルイケテナイ繰り返してて地獄味を感じるんだよねぇ。全てはブラウザが悪い。wasmはよ。
  
    2022/04/07 01:31
  
  
    libra_x1
  
  
    どんな道具を使おうがイケてなく使うこともできるし、到達目標がないと一生砂漠をうろつくような状態にもなるからな。ノンポリにはNode.jsはいい選択肢だと思う。
  
    2022/04/07 09:58
  
  
    GEROMAX
  
  
    そうなのか
  
    2022/04/07 10:46
  
  
    sigwyg
  
  
    オープンソースの敗北みたいになりつつあるのやだなーと思いつつ、つよつよエンジニアが業務時間に開発してるアプリに勝つ(メジャーを獲る)のは難しいよなー、など
  
    2022/04/07 11:31
  
  
    vvakame
  
  
     mizchiくんが書いたこの手の記事にflowの名が出なくなったの時代を感じる
  
    2022/04/07 12:17
  
  
    manaten
  
  
    “他人が書くものを使う分には不満だが” どの言語にもエキスパートからすると使わないほうがいい機能やイディオムがあるから、tsがというよりやばやばエンジニアと仕事するのがやばいという話な気もするなあこれは
  
    2022/04/07 12:38
  
  
    amagitakayosi
  
  
    ほぼ同意。「フロントエンドをwasmで書く」については、UnityみたいなリッチなIDEが出て来ないと10年後も厳しいのではという気がしている(というか出てきてほしい)
  
    2022/04/07 14:21
  
  
    mas-higa
  
  
    なるほど
  
    2022/04/08 14:23
  
  
    umai_bow
  
  
    “映画レディ・プレイヤーワンのジェームス・ハリデイのモデルにもなったであろう node の OSS スター substack” マジ?まあでもsubstackが活躍してた頃のJS界隈が一番好きかも。Browserifyが未来を切り開いた
  
    2022/04/08 18:47
  
  
    iwasiman
  
  
    こちらもJS界隈の歴史が分かる記事。wasmの未来ってまだまだ先っぽいんですね。
  
    2022/04/09 16:58
  
  
    rryu
  
  
    ビルドシステムまだ安定してないのか。コードを書いてブラウザで確認するだけという開発者体験の実現とブラウザがESモジュールに対応したという前提条件の変化によるものっぽいが…