5 ポイント 投稿者 GN⁺ 2025-07-31 | 3件のコメント | WhatsAppで共有
  • 低抽象化・低ボイラープレート(low-ceremony)をベースに、Rubyエコシステム向けのシンプルで強力なWebフレームワークとして、コントローラやRESTリソースの概念を使わず、ページ・フォーム・単一アクション中心の構造を提供
  • サーバーサイドレンダリングHTML、JS/CSSの直接記述、OpenTelemetry連携、Sequel・OptionParserなどの現代的なRubyツールを内蔵し、インストールと開発が数分以内で可能
  • クラスベース構造、実際の型ベースのセッション・フォーム・パラメータ管理、動的メソッド・ハッシュの使用を最小化することで、明確なコード・自動ドキュメント化を志向
  • 最新のWebプラットフォーム活用: サーバー・クライアント検証の統合、BrutJS(Web Components)、esbuildでCSSバンドル・ハッシュ化、セキュリティポリシーとDB設計の基礎を強化
  • YAMLを最小限に抑え、Ruby/Hashベースの設定と明確なネーミング・役割分離を採用し、不要な抽象化やパターンを強要せずRubyとブラウザ技術を楽しく活用することを目標としている

Brutフレームワーク主要な特徴

完全に新しい構造 – コントローラなしのページ中心

  • コントローラ、RESTリソース、ルートアクションの代わりにクラスベースのページ、フォーム、単一アクションハンドラーで構成
  • HTMLはサーバー側で直接作成し、JS/CSSは自由に記述可能
  • 例: 時間表示ページは TimePage < AppPage で直接定義

現代的なWebプラットフォームを積極的に活用

  • サーバー・クライアント検証統合のフォームUX
  • BrutJS(Web Componentsライブラリ)でHTMLの漸進的拡張をサポート
  • esbuildでCSSのバンドルとハッシュ化を行い、PostCSSやSASSなしで簡潔に処理

開発生産性・基盤の内蔵

  • OpenTelemetryベースのインストルメント、Sequelベースのデータアクセス、OptionParserベースのコマンドライン自動化
  • 基本的なセキュリティポリシー、DBカラム・外部キーのデフォルト値・インデックス、常時タイムゾーン対応の時刻、簡易なロケール(Localization)
  • RSpecテスト、Faker/FactoryBotによるデータ生成、PhlexでHTML生成

YAMLの排除、明確な設定構造

  • I18nはRuby Hashベース、動的設定はdotenvで管理(YAMLはほぼ使用しない)
  • docker-composeのみ例外的にYAMLを使用

不要な抽象化やパターンの強制なし

  • ネーミング・構造が明確(例: WidgetsPage/widgetsにアクセス)
  • データ層(DB::Widget)とドメイン層(Widget)を完全に分離可能
  • コントローラ概念はなく、望む方法でビジネスロジックを実装可能
  • 複雑な関数型パターン、モナド、Procなどを強要しない

開発体験・柔軟性

  • RSpecなど現代Rubyエコシステムのツールをデフォルトで内蔵
  • Phlex(HTML)、Faker/FactoryBot、Sequel、OpenTelemetryなどの主要ライブラリを積極的に活用
  • 繰り返されるボイラープレート・設定・意思決定から離れ、Rubyとブラウザ技術の「楽しさ」に集中

なぜBrutなのか?

  • Railsなどの既存フレームワークでの反復的なセットアップ、絶え間ない設計・構造論議、不要な柔軟性の代わりに、コードそのものの楽しさを追求
  • 迅速に構築し、開発とデプロイを楽しむことができるRubyベースのWebアプリケーションフレームワークとして、生産性と明確さに集中

始め方と今後のロードマップ

  • Brut公式のDockerイメージ、コマンドベースでの素早いアプリ作成・実行をサポート
  • ADRs.cloudなど、実戦的なサンプルアプリを提供
  • 1.0バージョンと公式ロードマップの継続的な更新を予定

3件のコメント

 
jhk0530 2025-07-31

https://naildrivin5.com/blog/2025/…

このリンクに修正する必要がありそうです

 
colus001 2025-07-31

リンクが間違っているようです。

 
GN⁺ 2025-07-31
Hacker Newsのコメント
  • formspages に集中するやり方が気に入った。自分もアプリでこのアプローチを使っていて、すべてのやり取りは Forms と Links が主導している。JavaScript による拡張も、結局は既存の form(隠れているものも含む)をクリックする程度のものだ。HTML を常に直接確認できるので、どの route が実際にインタラクションを処理しているのかを明確に把握できる。controllers は過剰に使われていると思う。実際には forms と models(バックエンド)、そして views(Pages)だけで十分だ。多くの validation や controller 内で繰り返される手順も、framework がもっと洗練された形で処理できるはずだ

    • なぜ form をクリックイベントでシミュレートするのか気になる。submit() を直接呼ぶのと何が違うのだろう
  • monad、algebraic data types、currying、あるいはすべてを Proc で処理するといった複雑な概念を必ずしも理解する必要はない、という説明が気に入った。ビジネスロジックで functor を使いたければいくらでも選べる。この柔軟さが気に入ったので、少人数の熟練した仲間と進めるサイドプロジェクトで使ってみたくなる

  • この framework は Sinatra の簡潔さと Rails の豊富さのあいだにある、優れた中間地点になりそうだ。私はシンプルなアプリには Sinatra を、必要に応じて Rails を使ってきたが、複雑でないアプリには Rails はむしろ重すぎた。新しく試してみたいという期待がある

    • 参考になる選択肢として Roda もある。小規模プロジェクトで最適だったし、拡張性も高かった。plugin system のおかげで機能拡張がしやすく、routing tree も扱いやすかった

    • 自分にとっては hanami が最高の中間地点だったが、今後は bruts の発展を注意深く見ていくつもりだ

  • David の著書 Sustainable Rails が本当に好きで、Rails 関連ではいつもおすすめしている。この framework のアプローチも印象的だ。こうした小規模で代替的な framework のどれかが Sorbet を完全導入して form validation などに活用したら本当に面白いと思う。もちろん gradual typing のアプローチとは相反するかもしれないが、実験としてでも楽しそうだ

    • David はとても 才能ある 開発者なだけでなく、講演も素晴らしい。本のテーマに通じる動画講演もおすすめしたい: https://www.youtube.com/watch?v=CRboMkFdZfg

    • Sorbet も良いが、構造の強制やデータ検証(data validation)には個人的には dry-rb ecosystem のほうが好みだ

  • この framework が少し変わったライセンスを使っているのはわかるが、これはもしかして ソースコード を見られないという意味なのだろうか

  • このプロジェクトを見て、昔の Camping framework を思い出した。ただし、動的な親クラスコンストラクタがない点は違う

  • Brut の公式サイト(https://brutrb.com/overview.html)にも 興味深い内容 が多かった

  • サンプルサイトでログインを試したが、github 認証 の直後にエラーになった

    • 作者です。現在は乱用防止のため、サンプルサイトではログイン自体を無効にしている。今日になって急きょ公開を決めたので、誰でもログインできる状態にする準備がまだできていない。ローカルで実行するか、https://brutrb.com/adrs.html でページの閲覧やリンクのクリックは可能だ
  • Ruby はまだ使っていないが、プロジェクトに興味を持って Star を付けた。このプロジェクトが Ruby を実際に使ってみるきっかけになるかもしれない

  • 特に Phlex の選択が気に入った。個人的には、この framework が Datastar js library や、その library における SSE(サーバー送信イベント) の活用とも相性が良いのか気になる。ありがとう