- Primo v3.2 は、サイトをローカルファイルとサーバーデータベースの行の両方で表現し、エージェントがコードを修正しつつ、非技術系の編集者が同じサイトをブラウザで編集できるようにする
- 開発者は Svelteコンポーネント とYAMLファイルでページ・コンテンツ・設定・ルートを扱い、
primo push でサーバーのリレーショナルデータベースと同期する
- ブラウザエディタはレンダリングされたページ上でのテキスト編集、ブロックのドラッグ＆ドロップ、カスタムページタイプとフィールドを提供し、フォーム中心のCMS画面への依存を減らす
- 主な対象は 非技術系編集者向けのカスタムサイトを引き渡す必要がある開発者・フリーランサー・エージェンシー で、スターター12種と40以上のブロックを提供する
- コンテンツはPocketBaseベースの SQLite に保存され、コードはユーザーのリポジトリに残り、MITライセンスと
primo pull の静的エクスポートによってサービス依存を抑えられる
ファイルとデータベースを併用するCMSモデル
- Primo v3.2 は2019年から続くオープンソースCMSで、サイト全体をファイルとデータベース行の両方で同時に表現する
- ローカルファイルはエージェントが直接修正し、サーバーデータベースは人がブラウザで視覚的に編集する対象として使われる
- 基本的な流れは、エージェントでサイトを作成し、その後クライアントや知人にブラウザ編集権限を渡す方式である
- 例では
claude が価格ページタイプを作成し、pages/pricing.yaml、blocks/pricing-tiers/component.svelte を書いた後、primo push で3つのファイルをデプロイする
- デプロイ後、ユーザーはブラウザで価格ティアの文言や価格を直接修正できる
エージェントが扱うローカルファイル構造
primo pull はサイト全体を 通常のファイル としてダウンロードする
- コンポーネント、ページ、コンテンツ、設定、ルートが含まれる
- ブロックはSvelteコンポーネントで、コンテンツと設定はYAMLである
- 新しいサイトをスキャフォールドすることも、既存サイトをダウンロードすることもできる
- Claude Code、Cursor、CodexのようなCLIエージェントは、リポジトリ全体を対象に修正する
- Next.jsやSvelteKitのコードベースを扱うように、コードベース全体を編集する流れである
- 例のコマンドは
$ claude "redesign the pricing page" である
primo push は変更されたファイルをサーバーの リレーショナルデータベース と同期する
- クライアントはブラウザで同じサイトをレンダリング済みページ上から編集する
- ブロックが宣言したフィールドは編集可能なフィールドとして公開される
レンダリングされたページ上で編集するCMS
- エディタはレンダリングされたページ上で動作し、別個のCMSタブやフォームビューを標準の編集体験として要求しない
- ブロックが宣言したすべてのフィールドは、クリック可能な領域とラベルとして表示される
- レンダラーが読むのと同じモデルを使い、別個の変換レイヤーはない
- オンページ編集 は、レンダリングされたページのテキストをクリックしてそのまま入力する方式である
- ドラッグ＆ドロップブロック により、ページツリー内でブロックを並べ替え、追加、削除し、変更内容をそのままソースに記録する
- カスタムページタイプ は、ページの形を一度定義しておけば、クライアントがそのモデルを壊さずに必要なだけページを作成できるようにする
- カスタムフィールド は、テキスト、リッチテキスト、画像、リンク、数値、グループ、リピーターをサポートする
- リアルタイムコラボレーション は、複数人が同じページを同時に編集できる機能で、ライブのプレゼンス表示と競合のない編集を含む
- 構造化されたフォームビューは、ページ上に表示されないSEO、メタデータ、リピーター、非表示設定のようなフィールドに使われる
カスタムサイト制作者向けのスターターとブロック
- Primoは 非技術系編集者向けのカスタムサイト を作る開発者、フリーランサー、エージェンシーを対象としている
- マーケットプレイスは、クライアントの種類別スターターと一般的なセクションブロックを提供する
- レストラン、コーチ、ポートフォリオ、ローカルサービス向けスターターが例として挙げられている
- 提供規模はスターター12種と40以上のブロックである
- 各スターターは 自己完結型サイト である
- Svelteコンポーネントとタイプフィールドを含む
- リポジトリとしてスキャフォールドされる
- フレームワークロックインや隠れたランタイムはない
- ユーザーはスターターをフォークして修正・デプロイしたり、独自のスターターやブロックをキュレーションしたりできる
WordPress・Headless CMS・サイトビルダーとの違い
- WordPressはクライアントが編集可能なサイトを提供するが、コンテンツとPHPテーマが絡み合う構造として比較される
- Headless CMSはコード構造をきれいに保てるが、スキーマは別個の管理画面にある
- サイトビルダーはドラッグ＆ドロップを提供するが、成果物をプラットフォームから借りる形になる点と対比される
- Primoが強調する違いは、1つのソースをチームとエージェントが一緒に編集する点である
- コードの所在はSvelteファイルとユーザーのリポジトリである
- クライアントの編集場所はレンダリングされたページである
- スキーマは
.svelte の隣にある fields.yaml に置く
- エージェントはサイト全体をファイルとして編集できる
- ホスティングとライセンスはself-hostとMITとして提示される
データ所有権と運用状況
- コンテンツはPocketBaseを通じて SQLite に保存され、コードはユーザーのリポジトリに残る
primo pull はいつでもコードとコンテンツの静的エクスポートを提供する- PrimoはMITライセンスで、プロジェクトが消えても動作中のコードと構築済みサイトはそのまま動き続けるとしている
- 運用状況は 7年目のv3.2 で、プロダクションサイトの事例として、エージェンシーのクライアント案件、小規模コマースストア、ドキュメントサイト、自社マーケティングページがある
- エージェントは新製品ではなく、2019年から維持されてきた同じモデルの新しいクライアントとして扱われる
Payload、TinaCMS、Sanity Studioとの比較とReactサポート
- Payloadはheadless CMSで、スキーマが管理画面にあり、コンテンツをAPI経由で取得する構造である
- TinaCMSはMarkdownファイルの前段にGitベースのエディタを置く方式として比較される
- Sanity Studioはホスト型コンテンツレイク上のReactベース管理画面である
- Primoでは、エディタとレンダラーが同じSvelteファイルとデータベース行を読み、その間にAPI変換レイヤーは存在しない
- Reactは現時点でPrimoブロックではサポートされていない
- PrimoはSvelteのコンパイル時アプローチを中心に作られており、この構造によってブロックはエディタとレンダラーが直接読めるファイルになる
- Primoブロック内部でのReactサポートはロードマップにない
- ロードマップには
primo integrate <framework> がある
- 既存の SvelteKit アプリの上にPrimoを載せる方式が先に来る
- その後に Astro が言及され、Next.js は要望事項として残っている
- この方向では、プロダクションコンポーネントはそのフレームワーク側に残り、Primoはコンテンツとエディタのみを担当する
ブロック構造とCLI認証
- ブロックは同じ場所に置かれた2つのファイルで構成される
- コンポーネントはレンダリングを担当する
- スキーマはエディタにどのフィールドがあるかを知らせる
- 例の
blocks/hero/fields.yaml では headline、subheadline、cta フィールドを宣言している
headline と subheadline は textcta は link
- CLI認証は環境変数の
PRIMO_TOKEN を読む方式である
- トークンはサイトごとに管理画面で生成する
primo pull <host> はプロジェクトを複製するprimo push は変更されたファイルだけをアップロードする
- 認証は編集者が使うものと同じで、別個のAPIインターフェースを学ぶ必要がない
- HTTPS経由ですべてのPrimoインスタンスで動作し、self-hostedインスタンスも含まれる
開始コマンド
npx primo-cli init my-workspace
- 作成後、
workspace ready と server.yaml written の状態が表示される
- ライセンスと価格に関する文言は MIT、オープンソース、永久無料として提示される
1件のコメント
Hacker Newsのコメント
ドラッグ＆ドロップ式のCMSエディタはデモでは魅力的に見えるが、社内で似たようなエディタを運用してみると、終わりのないアップデート地獄だった
「テキストを右揃えにして青色にできますか？」のような要望が次々に出てきて、結局は各ブロックに属性が増え続ける
実際のコンテンツ作成者はうまく使いこなせないことが多く、出来上がりも概して満足のいくものになりにくい
教育を増やせば改善するかもしれないが、自由度とブランドアイデンティティの維持の間のトレードオフは残り続ける
うちの場合はヘッドレスCMSのほうが良いアプローチに見える。コンテンツだけを提供し、少数の専門家がデザインに合わせてコードで実装する形のほうがよいが、誰もがそこまでの余裕を持てるわけではないので、こうしたCMSにも確かな居場所はある
数か月前、クライアントのECサイトを改修する際にMaglevで編集可能なセクション／ブロックを作り、編集体験そのものは良かった
ただ、リリース後にクライアントがHTML/CSSをほんの基礎だけ知っているマーケティング担当者を採用し、その人に対して、HTML/CSSを自分で書くのではなく必要なセクションは開発者に作らせるべきだと納得してもらうのに苦労した
Primoのように開発者向けエディタを入れる方法もあるだろうが、長年の経験から言って、クライアントにサイトのHTML/CSSを直接触らせたいとは思わない
「壊したら費用を払ってください」という関係にもしたくない
もっと広く見れば、どんなCMSでも同じ問題がある。Webflowサイトが壊れた会社を助けたこともあるが、デザイナーが作ったあとにマーケティング担当者がUIを「改善」しようとして全部壊してしまった、典型的なケースだった
作れるコンポーネントの数には限界がある
理想的には、クライアントがコードなしでHTMLを簡単に変更できるCMSが必要だ。そうすれば高速に読み込めて、SEOにも有利で、開発者が車輪の再発明をしなくて済む
だからVersoly(https://versoly.com/)を作った。背景色を変えたり新しいセクションを追加したりするたびに、なぜ毎回開発者に連絡しなければならないのかと思ったからだ
ただ、どんなCMSを使っても、コンテンツ編集者がテキストを右揃えにして青くしたがる問題はやはり残るのではないかと思う
まだ正式なドキュメントはほとんどないが、興味があれば最初のページを見て、使う価値がありそうか見てもらえるとうれしい
一般的なフィードバックや、実体験から得た学びも聞いてみたい
https://brick-cms.com/
GitHub:
https://github.com/primocms/primo
過去の議論:
https://news.ycombinator.com/item?id=23820201
https://news.ycombinator.com/item?id=25301040
元の投稿者の別アカウントと思われる場所で、テキスト付きのShow HN:
https://news.ycombinator.com/item?id=36801101
SSGは静的サイトジェネレーター(Static Site Generator)の意味だと思われるが、少しでも特定分野から外れると、読む人にわかりやすく書こうとする配慮が必要ではないかと思う
Web開発をしている自分でさえ、この略語を読み解くのに一瞬考え込んだ
それでも、まだ知らないユーザーには省略せずに書いたほうが親切かもしれない
ブログ記事やレビューのような連続的な動的コンテンツを扱える、こういうツールがあればいいと思う
多くの人がWordPressに張り付いているが、カスタマイズやテーマは悪夢に近い
当時は、ブログを簡単に作るほぼ唯一の方法のひとつだった
問題は、標準的な範囲を少しでも外れた瞬間に、突然WordPress内部構造について深い知識が必要になることだ
約3年前、HNがオープンソースCMSのPrimoをフロントページに載せてくれて（https://news.ycombinator.com/item?id=23820201）、そのおかげでパンデミックのまっただ中に快適なリモート勤務の仕事を辞め、これにフルタイムで取り組むようになった。
その後、貯金を使い果たし、
primo.afドメインをTalibanに奪われ、妻に開発者兼デザイナーになって手伝ってもらうよう説得もした。それでも、ここまで作ってきたものを誇りに思っているし、人々がWeb開発を学び、個人サイトを立ち上げ、クライアントサイトを管理する助けになっているのを見ると、このアプローチの力強さとシンプルさへの確信がさらに深まった。
今日パブリックベータとして公開するPrimo 2は、ページ上でのコンテンツ編集やページビルディングなどを提供する。
Primoは、Webサイト制作そのものと、非技術系ユーザーには管理が難しいという現実にうんざりして作り始めた。
フリーランス案件では壊れやすいWordPressテーマ、ダッシュボード操作、プラグインの組み合わせに悩まされ、エージェンシー開発者としてはモノリシックなCMSやメタフレームワーク／ヘッドレスCMSはランディングページや紹介サイトには過剰だと感じていた。
コーディング講師としては、学生たちがCLI、API、パッケージマネージャー、バンドラ、フレームワーク、メタフレームワークに直面して、Webを活用すること自体に尻込みする姿を見てきた。
ブログ、ランディングページ、紹介サイトのような一般的なWebサイトを、作成・管理・開発・ホスティングするための、簡素でアクセスしやすい道筋がなかった。
Primoは基本的にはコンテンツを簡単に管理できるCMSだが、ページビルディング、コード編集、静的サイト生成、GitHubへのデプロイ／ホスティングまでを1つのインターフェースにまとめている。
ブロックはSvelte、つまりHTML/CSS/JSで書かれるため、レスポンシブでスタイルもカプセル化されている。
静的サイトなので、サーバーレスのコスト・セキュリティ・拡張性・速度の利点も得られる。
Primoは、SquareWixFlow系のWYSIWYGデザインコントロールを好む人向けというより、HTML/CSS/JavaScriptでサイトを完全に制御しつつ、自分や非技術系の友人・クライアント・共同作業者には非常にシンプルなコンテンツ編集体験を提供したい人のためのツールだ。
ノーコードツールや独占的なプラットフォームに息苦しさを感じつつ、コードの力は保ったままで、もっとシンプルなものを求める人を対象にしている。
さらに言えば、PrimoはWebを個人の手に残そうとする試みでもある。
Web出版をより身近なものにすることで技術リテラシーを高め、人々がブラックボックスや壁に囲まれた庭園へ安易に追いやられず、自由な表現を自分の手にできるようになることを願っている。
ただし、コンテンツ管理システムには問題があった。一般的な静的サイトジェネレーターのように、フォルダにMarkdownファイルを入れればテンプレートに従って記事やブログ投稿が生成される方式を期待していた。
一時期はPrimoリポジトリをforkして、データベース項目をファイル／フォルダ構造に変換するカスタム方式を実装したが、逆方向の処理が厄介そうだったので別の道を選び、このガイドに触発されて自分でMarkdown静的サイトジェネレーターを作った： https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
自分のユースケースは想定ターゲットではないかもしれないが、プロジェクトがデータベースに書き込まれる代わりに動的なファイル／フォルダ構造として保存され、普通のSvelteKitプロジェクトのように編集・バージョン管理できるなら、素晴らしい製品になると思う。
本質的には、コンポーネントライブラリと専用UIを備えたSvelteベースの静的サイト生成フレームワークになるということだ。
primo.afドメインをTalibanに奪われたというくだりを見て、昔はAfghanistanの外からでもAfghanドメインを登録できたのだと初めて知った。フォーラムも良くて、気になっていた質問のいくつかにはすでに答えがあった。
長年WordPressを使ってきて、最近Svelteを触り始めたところだが、これは本当に探していたものに近い。
これを作るために注がれた努力には大いに敬意を表したい。
良いプロジェクトだが、「セルフホスティング」をするのにSupabaseアカウントが必要なのは少し残念だ。
Supabaseに接続できる特定のホスティングサービスでしか動かないように見え、ページコンテンツもGitHubから取得するよう促している。
だから実際にはセルフホストできるCMSというより、特定のサービス提供者と一緒に動かすCMSに近く見える。
目標は、人々が自分のサーバーをできるだけ簡単に立ち上げられるようにすることだったので、そうしたサービスに接続する形になった。
ただ、バックエンドを切り離して本当に自前でホスティングできるようにする作業は進めている。
本当に必要な外部サービスはGitHubだけで、将来的にはGitLabのような他のプロバイダーも追加できそうだ。
良いプロジェクトだが、正直なところ今では開発者にもユーザーにも、JavaScriptを減らす、あるいはJavaScriptなしのやり方のほうが良いと感じる段階に来ている。
昔のブログをZola（https://www.getzola.org）で生成する新しいブログへ移行中で、React/Gatsbyで新しく作ったポートフォリオサイトも、性能差が大きすぎるのでまたZolaで作り直している。
ときどきJavaScriptをオフにしてWebを閲覧することもあるが、その状態でサイトがまったく動かなかったり、読み込みすらできなかったりするなら大きな欠点だ。
以前のサイトではjQueryを使っていてそれなりに苛立たしかったし、Reactのようなものを使ってみるのは悪夢だった。
内部的にはSvelteコンパイラを使っている。
2010年にStiqrというサイトジェネレーターを作ったのが、もう10年以上も前のことだなんてほとんど信じられない。
サイトはもう運営されていないが、YouTubeの動画にその痕跡を見ることができる。
https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s
当時の2010年はレスポンシブデザインが台頭してきた時期で、そのためプロジェクトをやめることになったが、近い将来のWebサイト制作のあり方は今でもこういう方向だと信じている
ドラッグ＆ドロップ／ブロック方式とSvelteの組み合わせは本当にすばらしいが、自分にはスペクトラムの間違った側にあるツールに見える。
これはオンラインエディタでブロックをカスタマイズするビジュアルWebサイトビルダーだ。
自分が欲しいのは、オフラインで自分のツールを使って作ったSvelte Webサイトに対して、クライアントがテキストを追加・変更したり、ちょっとした調整をしたりできるオンラインインターフェースだ。
あるインターフェース標準に合わせてサイトを作ればPrimoがそれを読み取れて、クライアントはビジュアルインターフェースで修正できる、という形だとうれしい。
大きな修正はまた自分のところに戻ってきて、自分はオフラインのワークフローの速さと自由を維持できる。
ヘッドレスCMSが必要だと言えるのかもしれないが、使ったものはどれも過剰に複雑で、設定とメンテナンスだけでも大きな頭痛の種だった。
特定のフィールドを作らない限り、たとえば画像を円形にするか四角形にするかといった視覚面は編集できない。
ローカルIDEを使えないのが問題なら、現時点ではSvelteコンポーネントをバニラJavaScriptにバンドルしてPrimoブロックに取り込み、フィールド経由でデータを渡すことができる。
ただし、安定するまでは本番で使う前に数週間待ったほうがよい。
あなたが説明したやり方は、実際のところ自分がクライアント案件を進める方法とほとんど同じだ。コードをすべて書き、たいていは別の案件のブロックを再利用したうえで、クライアントが初日から最小限のトレーニングだけで編集できるサイトを引き渡している
「ブロックのカスタマイズ」にテキスト変更が含まれていないという意味なのか、それともクライアントに渡すには可能な操作が十分に制限されていないという意味なのか気になる。
通常のページマークアップの中にドラッグ＆ドロップで管理されるセクションを挿入でき、Svelteを含むほとんどのフレームワークをサポートしているように見える
設定はFTPで行えばよい