「LLMは私よりもa11yの慣習を理解してるんじゃないかな。」いや、他の人たちがやってたんだよ。彼らが書いたことをLLMが時々使えるだけ。彼らがもう書かなくなったら、どうなるの？ > 「もっと多くの人が何かを作るのは素晴らしいことで、もしその中に遅かったりアクセスしづらかったりするものがあっても、それは人々が選ぶべきトレードオフだと思う。」それには同意するよ。みんなが増えるのはいいことだし、他の条件が同じならね。「AI」がすべてに浸透して、改善が明らかになったら、状況や感情はかなり違ってくると思う。でもそれでも、人々はその仕事をすることで「作られた」知識を持つ権利はないよね。もし帰属や報酬が真剣に取り組まれたら、あなたがその資料を作るために支払った人たちの資料だけで学ぶことができるなら、CSSを学ぶのがもっと早くて安くなるかもしれない。

問題は、アクセシビリティ、直感性、互換性、レスポンシブ性、スケーラビリティ、アーキテクチャ、パフォーマンス、そして他のあまり目に見えない「先進的」なUX/ソフトウェア開発の部分をマスターするのが常に難しいことだよね。超高レベルのフレームワークや今のLLMは、これらを台無しにして、すぐに半端なMVPを出すのをさらに簡単にしてしまった。だから「許容できる」と「まとも」の間のギャップが広がってる。 「まとも」を目指す人は、「許容できる」を推進する人たちと競うのがますます難しくなってきてる。そういう推進は理解できるし、MVPが利益を生むから、細かい部分はせいぜい「顧客満足度を上げる」だけだし（最近は、顧客なんて誰が気にするの？）。最終的には、もっと過労になって、ソフトウェアの質が急激に低下するか、仕事の満足度も下がるかもしれない。私の（残念ながら経験談だけど）例として、時々壊れたウェブサイトを修正したり、邪魔な要素をdevツールやuBlockで取り除いたりすることが増えてきた。ここにいる他の人たちも同じことをしているって聞いたよ（https://news.ycombinator.com/item?id=47042747）。これは、私が訪れるウェブサイトの基本的な機能を復元するためにやってること。昔はこんなことは必要なかったし、Flashや初期のウェブブラウザにはそもそもそんなオプションすらなかった。もう一つ、あまり経験談ではない例として、https://news.ycombinator.com/item?id=47390945 こういうカットで節約されたお金のほとんどが、ヒエラルキーの最上部にしか利益をもたらさないって気づくと、さらに悪化するよね。

以前はフロントエンド開発で生計を立ててたけど、クセや特異性を知るのは職人としての負担だったよ。確かに、参入障壁が高くなることもあったけど、そのせいで壊れたウェブサイトがたくさん生まれたし、楽しいことでも報われることでもなかった。元の著者はAIがコーディングの技術を低下させるという強い主張を持っていると思うけど、具体例はあまり説得力がないね。

その通り。どの「私たちの技術が失われている」って記事も同じように暗い形をしてる。もうそれだけでうんざりだけど、途中で自分自身に反論してることも多い。例えばこの文：> でも、どの詳細が「重要でない」と見なされるかは、非常に重要で時には主観的な決定だよね。そして最終的には、詳細は常に漏れ出てくる。そう、つまりこの新しい技術は深い技術的理解を報いるって言ってるわけで、避けられないからね。私も同意するよ。なんでこの全体のトーンが「AIが私の技術を安い商品にしてる」って感じなの？ウェブサイトは10年前よりも技術的にずっと良くなってるよ。機能が豊富で、速くて、SSL/a11y/レスポンシブ性が強いデフォルトになってる。コンテンツミルやSEO、ニュースサイトは、広告や企業のインセンティブの別のひどい失敗モードだよ。それはReactのせいじゃない！

これは主に偶発的な複雑さだ。そうなの？ここではCSSを嫌うのが楽しい趣味みたいだけど、実際には人々が使える良いリッチなユーザーインターフェースを作るのが本質的に難しい問題なんじゃないかな。確かに、ブラウザは後方互換性や複数の実装を維持する必要があって少し難しいけど、ウェブプラットフォームの他の制約に対処するためのより良いUIフレームワークや言語はまだ見たことがないよ。

「フロントエンドの失われた10年」は、a11yやセマンティックHTMLとは関係ないよ。元のトークでは、Reactやその仲間たちのせいでパフォーマンスがひどくなったって主張していて、それが2GB以上のRAMを消費するElectron CRUDアプリが生まれた理由なんだ。

「深い専門知識」が実は多くの人にとって非常に不便だったと感じているのは私だけじゃないと思う。そして、「深い専門知識」を無視してハックや怠惰な抽象化を積み重ねて、現代の数MBのフレームワークやElectronに至る便利さが、逆行だと感じているのも私だけじゃないと思う。ユーザーのコンピュータやメモリの利用状況、劣化した体験、無駄な帯域幅、80億人あたりの追加エネルギーコスト、環境への影響なんて誰も気にしないよね。> もっと多くの人がものを作るのは明らかに良いことだが、公共インフラを作るのが「明らかに良い」って言えるの？それが悪い道路や橋、失敗するシステムを意味するなら？ソフトウェアも同じことが言えるし、ほとんどのことに当てはまるよ。

「LLMは私よりもa11yの規約を理解していると思う」と反論したいね。あんたがa11yを学ぶために時間を投資してないからそう思うだけで、それは普通のことだよ。LLMは、特定の分野を深く理解していなくても、統計的に平均的な出力で人を感心させるのが得意なんだ。俺の意見としては、自分が評価できないLLMのタスクを見過ごすべきじゃないと思う。1. それに、評価する必要もないんだ！時間は限られてるし、アクセシビリティは広範だし、基準もたくさんあるし、スクリーンリーダーは使いにくいこともあるからね。だけど人間には常識があって、気にかけることができる。気にかける人間がテストしてインタラクションを考えるのに匹敵するa11yのトレーニングデータが十分にあるとは思えない。残念ながら、人間のソフトウェアQAは今、絶滅の危機に瀕してる。

「もっと多くの人が何かを作るのは素晴らしいことだ」と言うけど、それがどうして素晴らしいの？例えば、今のSteamでは毎年何千ものゲームがリリースされてるけど、その多くは誰もプレイしないようなゴミみたいなものなんだ。だから、実際の質の高いものが埋もれてしまうこともある。アプリストアでも同じことが起きてる。機会を制限するゲートキーピングは悪いけど、質に関するゲートキーピングはとても良いことだと思う。ソフトウェアに対して気を使って専門知識を持った人に書いてほしいと思うのは、俺にとっては素直に良いことだ。今、人々は成熟したソフトウェア製品の衰退をvibecodingのせいにしてるけど、それが公平かどうかは別として（俺はしばしば不公平だと思う）。「AIファースト」企業が質の低いブランドとして見られる可能性もあると思う。すでにゲームでは、AIが使われたかどうかを開示しなければならないことがあって、使われていたら信頼性がかなり損なわれるんだ。

これは主に偶発的な複雑さだね。ウェブが存在する独自のエコシステムの副産物であって、むしろポジティブだよ！バックエンド開発と比べてみて。もし「データベースのインデックスはすごく不便で、作る必要はない」と言ったら、笑い飛ばされるだろうし、それは正当な理由だよ。でも、開発者が「CSSを学ぶ気はない」と言ったら、みんな頷くんだよね。

1. こういう議論は、AI以前にはこの種の仕事が質の高い製品に専念する熟練の職人によって行われていたという考えに基づいているように思える。実際に業界で働いていた人なら、そんなことはなかったって分かるはず。これは「壁の中のもう一つのレンガ」って感じだね。最低限の要件を満たして成功を宣言するためのプレッシャーはすでにたくさんあった。今は、そのプレッシャーが越えられないものに見える。

AIの前は、この種の仕事のほとんどが質の高い成果物に専念する熟練の職人によって行われていたという考え 一部の人はキャリアの中でそういう時期があったかもしれないけど、AIの前にそれが消えたのには同意するよ。

その通り。jQueryやBootstrapが登場する前のウェブは、めちゃくちゃでコーディングするのが楽しくなかった。低品質のものが当たり前だったのは、あの頃のことだね。

そうだね。そして、フラッシュはジョブズが「フラッシュはバッテリーを食ってるから、次のiPhoneではサポートしない」ってステージに出てくるまで終わらなかった。そうなったらフラッシュは消えていった。どうやら誰も革新的なフロントエンドを必要としなくなったみたいだね ¯_(ツ)_/¯ この手のものにはブレーキがないから、ただ坂を転がり続けて、最終的には止まるまで続くんだ。それは自己増殖するプロセスだよ。

どんなデザイナーでも開いてインタラクティブなウェブサイトを作れる、CSSやHTMLの知識は不要。 ただし、その「どんなデザイナー」もActionScriptについてはそれなりの知識が必要だったから、Flashはただの魔法やキラキラじゃなかったよ。私もその一人だったから知ってる。必要に迫られてActionScriptを学んだけど、実際にはASを扱う前にHTML/CSS/JSを学んでたんだ。

良いニュースは、HTMLがキャンバスで復活するかもしれないってことだね :)

「ちょっとしたJSの知識（ActionScriptとして再ブランド化）」っていうのは、笑っちゃうくらい不正確だよ。Flashでパフォーマンスが良くて耐久性のあるレスポンシブなGUIを作るには、ASの深い理解とその quirks が必要だった。Adobe Airのような自己完結型の実行可能ファイルを出荷する際には、考慮すべきレイヤーがあったし、Flash以外にも他のIDEやコンパイラがあった。フォント、フレーム、ビットマップとベクターグラフィックス、音声や動画の埋め込みの扱い方など、完全なプラットフォームで、ブラウザ戦争と同じくらい複雑な戦場だった。2010年代にAS3駆動のアプリ開発を「ちょっとしたJSの知識」と片付けるのは、実際にその場にいたのか疑わしい。私はその場にいたけど、そんなことは起きてなかったよ。

それは本当だし、CやUnixの慣習の束も似たようなもので、古いからこそ慣れてる部分もあるよね。

ウェブ開発のための常識的なメンタルモデル。 自分で矛盾してるよ。「地雷原...のエッジケース...」なのか、それとも常識的なモデルなのか、どっちかだよ。両方はない。まだエッジケースの地雷原にいると思うし、すべてを解決したわけじゃない。フロントエンドを構築するための技術がクリーンで予測可能で、歴史的な負担がないわけじゃない。私たちがやったのは、これらの基礎的な間違いや不整合を上塗りしただけで、解決したわけじゃない。ReactはHTMLがUIツールキットとして設計されていなかった事実を解決しないし、Next.jsはJavaScriptが設計ミスだらけで、安全で理にかなった言語になれないことを解決しない。Tailwindも、スタイリングされることを想定していないマークアップにCSSが無造作に導入された問題を解決しない。結局、今のLLMは、上塗りの下にある恐怖の「知識」を持ってるだけで、99%の例が前の層のひび割れを修正するための上塗りに過ぎない時代の例から訓練された統計モデルなんだ。

あなたの無知が見えちゃってるよ。もっと色々あるんだから。次のjsの専門家にインタビューしたけど、他に何もできない人が多すぎた。それはスキルじゃなくて、ただの知識で、今では自由に手に入るものなんだ。

同意だね、TFAは存在しなかった黄金時代の喪失を嘆いてる。俺もその時代にいたけど、IE6専用のシンプルなJSがバグだらけのjQueryに取って代わられ、さらにメンテナンスが難しいAngular SPAに変わり、最終的には巨大なReactコードベースに置き換わったんだ。

でも、その漏れた抽象化がどのタワー、レベル、部屋にあるのかを理解するのは、LLMには見えないかもしれないけど、すごく価値のあるスキルなんだよね。委員会が完璧に設計したわけじゃないからって、全部忘れて本を閉じて機械に計算させるのはダメだと思う。ちなみに、俺は後者をやってるから、彼らが何を間違えてるかは分かるけど、メンテナンスが難しいゴチャゴチャなものを作る気にはならない。フロントエンドのスキルは、エージェントが暴走するたびに本当に役立つんだ。

面白いのは、基本的なデザインシステムやCSSを設定すると、AIが生成したフロントエンドコードがうまくフィットするってこと。でも、ほとんどの人はその基本的な手間すらかけてないんだよね。丸みを帯びた角は、まだまだ定義されてないものに感染しているトレンドのように思える。

フロントエンドを諦めるのではなく、AIの新しい効率を活用してリソースを解放し、フロントエンドをさらに進めるべきだと思う。バックエンドも同じ。世界は、今よりももっと多くのソフトウェアを必要としてるんだ。

ソフトウェアの目的は、人間の意志を機械が理解できる状態にエンコードすることだよ。ここでの不満は、自動化することでエンコードされるものが本当に望んでいるものじゃなくなるリスクがあるってこと。

一方で、後からフレームワークを使うのは標準化を試みる良い方法だったと思う。誰も使い方を知らない自家製のGUIなんて、逆に不利だしね。個人的には「大きすぎる」と感じるもの（Nuxt/Next）は拒否してるけど、Vueは好きだな。今はほとんどJavaScriptを排除したいから、サーバーサイドのテンプレートを使ったHTMXやAlpineタイプのソリューションに向かってる。技術は少ない方がいいと思ってる。カスタムコードを一行も追加する前から、ウェブアプリにいろんな無駄があった時期があったからね。

2000年代初頭には、ウェブ開発者たちは手作業で全てをコーディングするのに疲れていて、自動化を求めてたんだよね。フレームワークやCMSを探してた。2004年には、シンプルなアプローチでサイトを作ったんだ。ディレクトリツリーにテキストを置いて、PHPが改行の代わりにタグを追加してHTMLに挿入するって感じ。あの頃の選択肢は、重いCMSしかなかった。で、ひどいPHPフレームワークを2つ経てDjangoにたどり着いたんだ。Djangoみたいなフレームワークは、もっと段階的な移行で、ずっと扱いやすかったよ。もちろん、さらに進めてオブジェクトにバージョン管理を追加すると、すごく難しくなって、動作が保証されなくなることもあったけど、それ以外は、そういう態度は似てると思う。