2026/02/18 18:42
私は魔法が好きではありません。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
(推測を除外したもの)
要約
著者は、ソフトウェアは最大限の透明性で構築されるべきだと主張します。つまり、手作業で直接理解できるコードのみを使用し、ライブラリ・フレームワーク・AIツールなどの隠れた抽象化は避けるべきです。彼はテクノロジーの「マジック」なマーケティングが嫌いで、読みやすく変更可能なコードを好みます。シームレスなUXデザインはユーザーのエージェンシーを侵食するため、明確で保守しやすいコードを書いてコントロールを保持します。
実際には、彼はプロジェクト The Session で外部依存性を2つの有名な JavaScript ライブラリに限定し、npm パッケージや React のようなフレームワークは拒否しています。これらの階層的依存関係は実際に何が起きているかを曖昧にするためです。彼は大規模言語モデル（LLM）によるコード生成器を、隠れた複雑性の極端な形態―「トルボチャージド npm」を増幅したものと見なしています。
将来を描く中で、彼はコーディングを綿密な職人技（“編み込み”）として残し、速度よりも保守性を重視することを想像します。また、開発者が不透明なフレームワークや AI ツールに抵抗する姿勢を強調しています。この立場は、コードの各行を完全に理解し、「マジック」解決策への警戒心を持ち、最小限の抽象化を好むことを示しています。
本文
2026年2月17日
私は魔法が好きではありません。
「手品」や幻術のことではなく、技術を売り込むために使われるような「マーケティング用の魔法」のことです。単にうまく機能するだけ――それを考える余裕はほとんどないでしょう。
私は以前からシームレス設計とシームフル設計について書いてきました。シームレスさはしばしばUXの究極的な目標として語られます。「考えなくていい！」という姿勢ですが、その代償としてエージェンシーが削減されるのです。
フロントエンド開発に関して、私の魔法への不信は完全なるコントロールフェイクへと変わります。
私は自分で書いて理解したコード以外を使うのが好きではありません。避けられない場合もあります。The Session ではインタラクティブマップを表示するために1つ、楽譜を生成するためにもう1つの JavaScript ライブラリを使用しています。依存関係としては非常に良いものですが、それでも完全に理解していないものに依存する感覚が好きではありません。
npm でクライアントサイド JavaScript をインストールし、さらにその JavaScript が別の JavaScript に依存し、という連鎖を想像すると胃が痛くなります。多くのフロントエンド開発者が日常的にコードベースへの信頼投げ入れを正常化していることには驚きます。
ライブラリには懐疑的ですが、フレームワークには完全にアレルギーです。
しばしば「ライブラリ」と「フレームワーク」を区別しないのですが、この文脈では重要な違いがあります。ライブラリは他人のコードを自分のコードから呼び出すもの、フレームワークは他人のコードが自分のコードを呼び出す構造です。
React を例に挙げましょう。使うにはそのイディオム、アプローチ、構文を採用しなければならず、単なる JavaScript の片断を落とす以上の依存レベルがあります。
私は常にクライアントサイド React を避けてきました。エンドユーザーへの直接的な害（過剰設計で膨大なページロード時間）と、ブラウザとの間に置く余分な抽象化層が嫌いです。
抽象化について話すと誰かは必ず「コンピュータには常に何らかの抽象化レイヤーがある」と指摘します。バイナリで書かないなら、追加のレイヤーが不快だと言えるわけではありません。
私はそれを理解しつつも線を引きます。フロントエンド開発においては、できるだけ生の HTML・CSS・JavaScript に近づくこと――ユーザーがブラウザで実際に受け取るものです。
私のコントロールフェイクは一般的ではありませんし、商業的でも実用的でもないと自覚しています。数年にわたり職場でクライアントプロジェクトのフロントエンド開発をやめました。主に遅いから――速い開発者に仕事を任せた方がいい――、そして React への嫌悪感が理由です。React が必要なプロジェクトは触れませんでした。
これを書いているのは、フロントエンド開発でキャリアを目指すなら私の不変かつ不信仰的姿勢を採用しないほうがよいことを示したいからです。
幸運なことに、私はクライアント業務以外でもフロントエンド開発が続いています。自分のウェブサイトと The Session で遊び、Clearleft のイベント向けに手作りサイトを構築する機会もあります――長くて難しくても。
一方、実世界では抽象化は積み重なっています。開発者は大規模言語モデル（LLM）を使ってコード生成できるようになりました。良いコードもあれば悪いコードもあります。使用前にチェックすべきですが、一部の開発者はそのまま本番環境へ投げ込んでいます。
それは私にとって不安要因ですし、npm も同様です。本当に違うのでしょうか？ npm では他人のコードを直接呼び出します。LLM ではまず全世界のコードを取り込み、膨大なトークナイズ処理を行い、必要に応じて部分的に提供します。ある意味、大規模言語モデルのコーディングツールは「より多くの抽象化層」を持つターボチャージド npm のようなものです。
私には合わないが、実用的で商業環境では機能する理由を理解しています。アリスが言ったように：
ニットはコードを書く未来だ。誰も急いで安くて速いジャンパーを作るために編むわけではなく、クラフトを愛しているから編むのです。手書きでコードを書く未来は満足感を得られるでしょうが、それはソフトウェアを書きやすい最も安価・迅速な方法ではありません。
そしてデイブが指摘するように：
今、私たちは「呪文」のような魔法の言葉をコードベースに持っています。時には機能し、時には効果を測る実用的手段もないまま使われます。それらは命令と同時に祈りでもあります。
私は震えます！しかし再びこれは新しいことではありません。私たちは誰も触れずにいる神秘的なアーケインコードを見てきました――webpack などです。本質的にはコード自体より理解が問題です。一人の開発者の頭にあってその人物が去った場合、コードは危険になり、ほとんど触れない方が良いでしょう。
これはメンテナンス地獄です。そこで私は抽象化、特に大規模言語モデルへの嫌悪を感じます。長期プロジェクト（数十年の寿命）であるこのウェブサイトと The Session では、メンテナンスが最優先事項です。
大規模言語モデルのコーディングツールは本当に魔法です。
私は魔法が好きではありません。