まさに自分が必要で作ろうとしていたものなのに、これを作ってくれたんですね……。Claude Code Maxを使っていますが、複数のプロジェクトを同時に開発する際に本当に必要だったソフトウェアです。

Django、お誕生日おめでとう！

日本語訳は以下のとおりです。
https://roy-jung.github.io/250701-history-of-js/

大幅に向上した、優れている、正確だということを、数値で示してほしかったですね。

韓国はどのように違うのでしょうか

ディスク容量の無駄の問題 についてはかなり共感せざるを得ないですね...
AKS を運用していますが、コンテナイメージ容量が 1GB を超える Python アプリを見るたびに頭が痛くなります。
今はとりあえず Dockerfile を持ってきて自分で容量を削って上げ直していて、500MB 以下にできなければそのまま諦めます（笑）

うわあ…！ 最初に使ったとき、Pythonだからという理由で使っていたプロジェクトだったのですが…
長い時間が経ちましたね！
また使える環境で働けたらいいですね :) ふふふ
副業ででもやってみようかな…

Claude 4 が出た時点で Claude 3 と比較するのは、ほとんど詐欺ではないですか…

韓国時間の7時0分ごろから約50分ほど停止状態でしたが、今は正常に動作していますね
CMD> nslookup news.hada.io 1.1.1.1

私もDNSサーバーにアクセスできないというAndroidのプッシュ通知がずっと表示されていました。
しばらくGoogle DNSに退避しました。
https://developers.google.com/speed/public-dns/…

うわ…

そうですね、目的が何なのか、なぜそれをやるべきなのかを深く掘り下げるほど、明確な解決策が見えてくる気がします

好意的に読んでくださってありがとうございます！

ありがとうございます、良いお話でした！

とんでもなくコスパのいいマシン1台あればいけそう？ とんでもなく大きい法律事務所なら買って使うでしょうね。 でも工場の機械を24時間回すみたいにね、笑

ポルシェの価格しか考えず、維持費、ガソリン代、保険などはまったく考えていない人

元の文章の意図は、単に複雑化したJSフレームワークだけを批判することではありません。
便宜上、上にある韓国語訳のリンクから引用します。

> 今では、単に見出しを1つ変えるだけでも、4人のエンジニア、3つのフレームワーク、そしてCI/CDパイプラインが必要です。Webページを公開することが、異常なほど複雑になってしまいました。

> そうして徐々に、Webは公開前にコンパイルしなければならないものになりました。ユーザーがそれを必要としているからではありません。開発者がモダンに感じたがっていたからです。

> すべてが開発者のために最適化され、その他のあらゆる人にとっては敵対的です。

> 私たちはもはや複雑さを単に我慢しているのではなく、当然のものと見なしています。すべてのサイトにビルド工程、バンドラー、ハイドレーション戦略、ルーティングレイヤー、APIレイヤー、デザインシステム、そして巧妙なキャッシュ無効化ロジックが必要だと想定しています。マイクロサービスで構築し、エッジネットワークでホスティングし、単純なコンテンツを届けるためにパイプラインをデプロイしています。

> 私たちはWordPressのようなプラットフォームの機能を作り直していますが、その結果は10倍重く、しかも使い勝手ははるかに悪くなっています。さらに悪いことに、新しいレイヤーが増えるたびに、新たなバグ、新たな互換性の問題、新たな認知的負担が持ち込まれます。今や私たちは、単にホームページをオンラインに載せるためだけに、ハイドレーションロジックとキャッシュ戦略、そしてビルドパイプラインを保守しています。

> コンポーネントライブラリに十分な柔軟性がないため、マーケティングキャンペーンは遅れます。分析レイヤーがハイドレーション戦略と互換性がないため、A/Bテストは中止されます。コンテンツの更新は、ビルドを何日も待たなければなりません。基本的なSEO調整はバックログに埋もれてしまいます。

> マーケターは、チケットを起票しなければコピーを更新したり実験を実行したりできません。コンテンツをプレビューしたり、レイアウトをテストしたり、ページを公開したりすることもできません。あらゆる変更は、開発者、パイプライン、承認、再ビルドを経なければなりません。

> マーケター、コンテンツ編集者、SEO担当者、デザイナー――彼らは皆、このプロセスから排除されています。今では簡単な作業でさえ、技術的な流暢さが必要だからです。titleタグを変えたいと言えばエンジニアに相談するよう言われ、キャンペーンを公開したいと言えば、チケットを起票して2スプリント待てと言われるでしょう。

> すべては開発チームを通じて流れます。つまり、開発チームが何が重要か、何がリリースされるか、何が優先順位を無期限に下げられるかを決めるということです。そして彼らが複雑さを増せば増すほど、彼らはより不可欠になっていきます。

韓国の会社には当てはまらなさそう

元記事が指摘する「Webの過度な複雑さ」という問題には共感します。しかし、その原因を開発者文化やフレームワークの濫用だけに帰する診断には同意しがたいです。今日のWebの複雑さは、かなりの部分で「ビジネスモデル」が求める必然的な機能とセキュリティの影でもあるからです。この点を欠いたままでは、片手落ちの診断にとどまるほかありません。

Webはもはや「無料の展示館」ではありません。今日では公共サイトを除く大半のWebサービスは、収益創出を目的としています。したがって、技術選択における核心的な問いは「このコードは純粋か？」ではなく、「この技術は私たちのビジネスを成功させるか？」であるべきです。

この観点から見ると、元記事が理想として描く「軽量なコンテンツWeb」は、現実のビジネス要件という壁に突き当たります。たとえば、コンテンツを販売するビジネスは、単純な静的ページだけでは運営できません。有料サブスクリプションや決済を処理するには、ユーザー認証、購読状態の確認、権限管理といった状態ベースのロジックが必要であり、コンテンツ保護のためには違法コピーや不正アクセスを防ぐリアルタイムのトークン検証などのセキュリティ層が不可欠です。さらに、パーソナライズやA/Bテストを通じてユーザー体験とコンバージョン率を高めるには、動的なデータ処理も求められます。

これらはすべて「洗練されたアプリケーション」の領域であり、フレームワークはそれを実装するための現実的な道具です。

もちろん、すべての複雑さが正当化されるわけではありません。私たちは複雑さを二つに分けて考えるべきです。

• 必然的な複雑さ: ビジネス機能（認証、決済、パーソナライズなど）を実装するために生じる、ROIが明確な複雑さです。これは受け入れるべきコストです。

• 偶発的な複雑さ: 開発の都合や過度な技術的抽象化によって生じる不要な複雑さです。これは継続的に測定し、取り除くべき技術的負債であり無駄です。

成功しているサービスは、この二つを区別して現実的なアーキテクチャを構築します。つまり、マーケティングやSEOが重要な最前線はできるだけ軽くし、重要な取引やパーソナライズ機能が必要な内部領域はフレームワークベースで安定性を確保するというハイブリッド戦略によって、速度と機能性という二兎をともに追っています。

元記事は、ユーザー体験悪化の原因をフレームワーク文化にだけ集中させ、「収益モデルがもたらした必然的な要求」を排除しました。この点を除外してWeb開発を論じるのは、客のテーブルに「速くておいしい料理」を出すことだけを語りながら、肝心のその料理を作る複雑な厨房や代金を受け取るレジの存在をないものとするのと変わりません。

Webが重いからといって、やみくもにフレームワークを捨てることはできません。ビジネスが求める機能をどれだけ効率的に、最小のコストで実装し、ユーザーに価値を届けるかが論点であるべきだと思います。

ストリーミング機能が必要なチャットボットのようなサービスでは、同時処理時に Prefill の処理が decode にまで影響してしまい、VRAM に余裕があってもユーザー目線では性能が大きく低下しているように見えることがありました。

チャンク Prefill 関連のオプションや、vLLM で実験的に提供されている Disaggregated Prefilling 機能も適用してみましたが、それでも新しいリクエストが入ると、既存の生成中の回答がぶつぶつ途切れる現象があり、初心者開発者の立場としては GPU やノードを増やす方法以外に、最も効率的な方法があるのか気になっています。