ディスカッション (11件)
WordPressのプラグインに起因するセキュリティ脆弱性は、多くの開発者にとって長年の悩みでした。そんな中、WordPressの「精神的後継」を自称する新プロジェクト『EmDash』が登場しました。このツールは、プラグイン周りのセキュリティ課題を根本から解決することに特化しており、より安全で堅牢なWebサイト構築を目指しています。
新しいCMSの名前はEmDash。WordPressの精神的後継を目指していて、すべてTypeScriptで書かれている。サーバーレスだけど、自前のハードウェアや好きなプラットフォームでも動かせる。プラグインはDynamic Workers経由で安全なサンドボックス(Isolate)内で実行されるから、WordPressのプラグインアーキテクチャが抱える根本的なセキュリティ問題を解決できる。内部では、コンテンツ重視のサイト向けに最速を誇るWebフレームワーク、Astroが使われているんだ。
個人的には、CMSが向かうべき方向性と真逆な気がする。もっとシンプルに、「Webサイト」の原点に立ち返るべきだよ。どこでも動く静的ファイルなら高速だし、キャッシュも効くし、サーバーサイドレンダリングのサイトよりずっと扱いやすい。
まあ、そうしないと彼らの「Workers」という自社製品が売れないだろうから、なぜこういう設計にしたのかはなんとなく察しがつく。少なくとも、自社技術のドッグフーディングにはなるだろうね。
「根本的なセキュリティ問題」を本当に解決できているのかは怪しいけど、まあそれはこれから見ていくしかないかな。
WordPressの価値って、コード自体にはないと思う。最近学習しているけど、内部構造にはあまり感心しなかった。WordPressが価値あるのは、そのエコシステムとサポート力のおかげだよ。10年後もWordPressは確実に残っているはず。EmDashのサポート計画はどうなってるの?コミットを見ていると、ほとんど一人の開発者がやっているように見えるけど。
追記:エイプリルフールのジョークかと思った、恥ずかしい。
追記2:どうやらジョークじゃないみたい。
「x402はインターネットネイティブな支払いのためのオープンで中立的な標準。誰でも簡単に課金でき、クライアントは必要な時に必要な分だけ支払える。エージェントのようなクライアントがHTTPリクエストを送り、HTTP 402 Payment Requiredを受け取ると、クライアントはその場で支払いを行い、サーバーがコンテンツへのアクセスを許可する」
面白いね。Cloudflareは、エージェントが所有者からデビットカードを渡されて、コンテンツをスクレイピングするため、あるいは所有者の代わりに商品を購入するために、自律的にマイクロペイメントを送る未来を想定しているわけか。どう感じるかは別として、興味深いコンセプトであるのは間違いない。
ちょっと失礼、訪問ごとに10セントを要求するHTTP 402 Payment Requiredを返すハニーポットを設置してくる……。昔の「サイトの100万ピクセルを1ドルで売る」ビジネスの次世代版って感じだな。
Cloudflareが支援するWordPressの精神的後継なんて理論上は最高に聞こえるけど、目玉機能のDynamic Workersによるプラグイン分離はCloudflareのランタイムでしか動かないんだよな。他のホストで動かせば、セキュリティモデルという存在意義を失った単なるTypeScript製のCMSに過ぎない。オープンソースだけど、アーキテクチャとしては特定の環境にロックインされている状態だ。
真面目な質問なんだけど、なんでみんなAIでコーディングするプロジェクトにまだJavaScriptを使ってるの?今は本物の言語を使って、直感的にアプリを作れる時代だよ。
わざわざインタープリタ言語みたいな、肥大化しがちで特殊な言語を使う理由なんてないはず。インタープリタ言語が使われていた唯一の理由は、コンパイルなしでファイルを修正してすぐ実行できることだったけど、今やコンパイルは一瞬だし、新しい言語を習得する苦労だってない。AIに「Goでアプリを書いて」と言えば喜んでやってくれる。実行すればメモリ使用量もディスク容量も少なくて済むし、コードもシンプルでレビューもしやすい。配布だって「ファイルをコピーするだけ」で完結する。
インタープリタ言語は、コンパイルや配布という「ポータビリティ」のステップをスキップできて、面倒なmacOSのコード署名を回避できるっていうメリットは認めるよ。でもGoならクロスコンパイルはめちゃくちゃ簡単だし、ユーザー側でも自己署名アプリの隔離解除はそこまで難しくないはずなんだけど。
(残念ながら)WordPressの開発者として言うと、これはWPにおける最大の悩みの種を解決してくれそう。それはプラグインのセキュリティじゃなくて、プラグインのアーキテクチャ全体の話。WPはプラグインをコンテンツとして扱っていて、アップロードした画像と文字通り同じトップレベルの wp-content ディレクトリに置かれるんだ。これのせいでCI/CDとかが地獄になる。でもEmDashのプラグインは単なるTSモジュールだから、設定がどこかのDBに入るにしても、作業はずっと楽になるはず。
これはかなり面白いね。10年ほど断続的にWordPressに関わってきたけど、このプロジェクトは「TypeScript」と「Workerプラグイン」という2点で完全に的を射ていると思う。最近、WPのセキュリティ(というか欠如)についてよく考えるんだ。WPでは悪意のあるプラグインがDBや環境変数にアクセスできたり、画面にテキストを表示できたりする(XSSを考えればわかるよね)。幸いなことに、よく設計されたプラグインシステムならこれら全ての課題を軽減できるはず。個人的な趣味でHotsauceCMS( https://github.com/hotsauce-team/hotsauce )っていう、EmDashに少し似たヘッドレスCMSを作ってるんだ。まだ開発初期段階だけどシェアしておくよ。・NodeJSまたはDeno Workerプラグインをオプションで選べるようにした。ファーストパーティプラグインはインプロセス処理の速度を活かせるし、他のプラグインはWorkerで実行できる。きめ細かな権限管理にはDeno Workerが使えるよ。・依存関係を徹底的に最小化した。Dependabotの通知やnpmのサプライチェーン攻撃にはもううんざりだからね。このCMSは依存関係が4つだけで、推移的依存はゼロだよ。・Drizzleのスキーマファーストで、ヘッドレス構成。DB構造を完全にコントロールできるし、ファイルアップロードみたいな機能のためにスキーマ内でcmsヒントを使える。・DBに依存しないから、DrizzleがサポートするDB(Postgres、MySQL、SQLite)なら何でも動く。・ヘッドレスだからフロントエンドは自由。自分はReactなしのJSXが好みだけど、何でもあり。HotsauceCMSについてフィードバック大歓迎。何か見落としてるかな、方向性は合ってると思う?とにかく、EmDashおめでとう。今後数ヶ月でどうなっていくか楽しみにしてるよ。
つまりこれは、テーマやプラグインがあって、ページや投稿、タグ、カテゴリーを公開できるっていう点でWordPressに「似ている」だけのCMSってこと?でも世の中には似たようなCMSがたくさんあるし、WordPressのテーマやプラグインをそのままインストールできるわけじゃないから、WordPressとの「互換性」もないよね。なんでわざわざWordPressと比較してるのかよくわからないな。これは似たような機能を提供している、数あるCMSの一つに過ぎないんじゃないかな。
個人的には、Cloudflareはちょっと狙いがズレてる気がする。WordPressがこれだけ普及してるのは、昔はWebサイトを作るのに一番簡単な方法だったからだよね。そのおかげでエンジニアのネットワーク効果が生まれて、今でもWebサイトの40%を占めるほど定着してる。Reactも同じ。Typescriptサイトの大半がReactとNextJSで書かれているのは、その周りのネットワーク効果のおかげ。セキュリティは大事だけど、今のリスクを許容しているWordPressエンジニアの何人が、わざわざこれに乗り換えるだろうね?正直、多くないと思う。2026年になってもWordPressで開発してる人って、新しい技術を学ぶのが好きなタイプじゃないだろうし。それに、これからWebサイトを作ろうとしている一般のユーザーが、WixやSquarespaceじゃなくてこれを選ぶかな?使いやすそうには見えないから、期待はできないな。新しいWordPressになるためのネットワーク効果はどこから生まれるんだろうね。Vinextは頑張り続ければ成功するかもしれない。Vercelから離れたいと思ってる層は結構いるし(エコシステムが安定したらTanstackに移行する人が多そう)。でも、WordPressユーザーが本当に離れたいと思っているかどうかは疑問だね。本当に成功させたいなら、Squarespace、Wix、Shopifyなんかよりも簡単、高速、安価、そして柔軟であるっていう、もっと別の切り口が必要だと思う。
彼らのNext.jsに関する記事からの引用だけど、これ気に入ってるよ。
ソフトウェアにおける抽象化のほとんどは、人間が助けを必要とするために存在する...。どの抽象化が真に基礎となるもので、どれが単に人間の認知を補助するための松葉杖に過ぎないのかは、まだ明らかではない... 我々はAPIコントラクトとビルドツール、そしてAIモデルを使い、AIがその間の全てを書いた。