Brut – Ein neues Webframework für Ruby
(naildrivin5.com)- Brut ist für das Ruby-Ökosystem ein einfaches, aber leistungsstarkes Webframework auf Basis von geringer Abstraktion und low-ceremony, das eine seiten-, formular- und einzelaktionszentrierte Struktur ohne Controller- und REST-Ressourcenkonzepte bereitstellt
- Server-seitig gerendertes HTML, direkte JS/CSS-Entwicklung, OpenTelemetry-Integration sowie moderne Ruby-Tools wie Sequel und OptionParser sind integriert, sodass Installation und Entwicklung in wenigen Minuten möglich sind
- Mit einer klassenbasierten Struktur, typbasierter Verwaltung von Sessions, Formularen und Parametern sowie minimalem Einsatz dynamischer Methoden und Hashes setzt Brut auf klaren Code und automatische Dokumentation
- Nutzung der modernen Web-Plattform: integrierte Server- und Client-Validierung, BrutJS (Web Components), CSS-Bündelung und Hashing mit esbuild, sowie stärkere Grundlagen bei Sicherheitsrichtlinien und DB-Design
- Mit minimiertem YAML-Einsatz und Ruby/Hash-basierter Konfiguration, klarer Namensgebung und Rollenaufteilung ist es Brut-Ziel, Ruby und Browser-Technologien ohne unnötige Abstraktionen oder erzwungene Muster mit Freude zu nutzen
Die wichtigsten Merkmale des Brut-Frameworks
Vollständig neue Struktur – seitenzentriert ohne Controller
- Statt Controller, REST-Ressourcen und Route-Actions nutzt Brut klassenbasierte Pages, Forms und Single-Action-Handler
- HTML wird direkt auf dem Server erzeugt; JS/CSS kann nach Bedarf geschrieben werden
- Beispiel: Die Zeit-Anzeige-Seite wird direkt als
TimePage < AppPagedefiniert
Aktive Nutzung moderner Web-Plattformen
- Integrierte Server- und Client-Validierung für die Form UX
- BrutJS (Web-Components-Bibliothek) zur inkrementellen Erweiterung von HTML
- esbuild für CSS-Bündelung und Hashing, ohne PostCSS oder SASS
Eingebaute Produktivität und Grundlagen
- OpenTelemetry-basierte Instrumentierung, auf Sequel basierter Datenzugriff, CLI-Automatisierung auf OptionParser-Basis
- Standard-Sicherheitsrichtlinien, Standardwerte und Indizes für DB-Spalten/Fremdschlüssel, stets zeitzonenbewusste Zeitangaben, einfache Lokalisierung
- RSpec-Tests, Datengenerierung mit Faker/FactoryBot, HTML-Erzeugung mit Phlex
YAML-Reduktion und klare Konfigurationsstruktur
- I18n basiert auf Ruby Hashes, dynamische Konfiguration wird über dotenv verwaltet (nahezu kein YAML)
- Nur bei docker-compose wird YAML ausnahmsweise genutzt
Keine unnötigen Abstraktionen oder erzwungenen Muster
- Klare Namensgebung und Struktur (z. B.
WidgetsPageist unter/widgetserreichbar) - Datenebene (DB::Widget) und Domänenebene (Widget) lassen sich vollständig trennen
- Kein Controller-Konzept, Geschäftslogik kann frei implementiert werden
- Komplexe funktionale Muster, Monaden, Proc usw. werden nicht erzwungen
Entwicklererfahrung und Flexibilität
- Moderne Ruby-Ökosystem-Tools wie RSpec sind standardmäßig integriert
- Phlex (HTML), Faker/FactoryBot, Sequel, OpenTelemetry und weitere wichtige Bibliotheken werden aktiv genutzt
- Weg von wiederkehrendem Boilerplate, Setup und Entscheidungsdebatten; Fokus auf den Spaß mit Ruby- und Browser-Technologien
Warum Brut?
- Statt wiederholten Setups, ständiger Architektur- und Strukturdebatten sowie unnötiger Flexibilität in Rails und anderen bestehenden Frameworks setzt Brut auf die Freude am Code selbst
- Als Ruby-basiertes Web-App-Framework, mit dem sich schnell entwickeln und deployen lässt, konzentriert es sich auf Produktivität und Klarheit
Start und Roadmap
- Brut stellt ein offizielles Docker-Image bereit, unterstützt schnelle App-Erstellung und -Ausführung per Kommandozeile
- Praxisnahe Beispiel-Apps wie ADRs.cloud
- Version 1.0 und die offizielle Roadmap sollen kontinuierlich aktualisiert werden
3 Kommentare
https://naildrivin5.com/blog/2025/…
Ich glaube, dieser Link sollte korrigiert werden.
Ich glaube, der Link ist falsch gesetzt.
Hacker-News-Kommentare
Mir gefällt der Fokus auf forms und pages; ich nutze in meiner App selbst einen ähnlichen Ansatz. Alle Interaktionen werden von Forms und Links getragen, und jede Verbesserung mit JavaScript läuft im Grunde darauf hinaus, ein bereits vorhandenes form anzuklicken, auch wenn es versteckt ist. Ich kann immer direkt im HTML nachsehen und klar erkennen, welche Route die Interaktion tatsächlich verarbeitet. Ich finde, controllers werden übermäßig verwendet; eigentlich reichen forms und models (Backend) sowie views (Pages) aus. Viel Validierung und viele wiederkehrende Abläufe in Controllern könnte das Framework eleganter übernehmen.
Mir gefällt die Erklärung, dass man komplexe Konzepte wie monad, algebraic data types, currying oder alles als Proc zu behandeln nicht unbedingt verstehen muss. Wenn man in der Business-Logik functor verwenden möchte, kann man das natürlich tun. Diese Flexibilität gefällt mir, deshalb könnte ich mir vorstellen, es in einem Side-Project mit ein paar erfahrenen Kolleg:innen auszuprobieren.
Dieses Framework wirkt wie ein großartiger Mittelweg zwischen der Schlichtheit von Sinatra und dem Funktionsreichtum von Rails. Ich habe Sinatra für einfache Apps und je nach Bedarf Rails verwendet, aber für nicht allzu komplexe Apps war Rails eher ballastreich. Ich freue mich darauf, etwas Neues auszuprobieren.
Als weitere Option zum Anschauen gibt es auch Roda. Für kleinere Projekte war es optimal und ließ sich gut skalieren. Dank des Plugin-Systems konnte man Funktionen leicht erweitern, und auch der routing tree war gut zu handhaben.
Für mich war hanami der beste Mittelweg, aber ich werde die Weiterentwicklung von bruts aufmerksam verfolgen.
Ich mag Davids Buch Sustainable Rails wirklich sehr und empfehle es immer, wenn es um Rails geht. Der Ansatz dieses Frameworks ist beeindruckend. Wenn eines dieser kleinen alternativen Frameworks Sorbet vollständig einführen und für Dinge wie form validation nutzen würde, fände ich das wirklich spannend. Natürlich könnte das dem Ansatz des gradual typing widersprechen, aber schon als Experiment wäre es interessant.
David ist nicht nur ein sehr talentierter Entwickler, sondern hält auch großartige Vorträge. Ich empfehle auch seinen Videovortrag, der thematisch gut zum Buch passt: https://www.youtube.com/watch?v=CRboMkFdZfg
Sorbet ist auch gut, aber für strukturelle Vorgaben und Datenvalidierung bevorzuge ich persönlich eher das dry-rb-Ökosystem.
Ich verstehe, dass dieses Framework eine ungewöhnliche Lizenz verwendet, aber bedeutet das vielleicht, dass man den Quellcode nicht einsehen kann?
Man kann sich den Quellcode auf GitHub ansehen: https://github.com/thirdtank/brut
Ich kann nachvollziehen, dass sich die Lizenz etwas seltsam anfühlt.
Dieses Projekt erinnert mich an das frühere Framework Camping, nur dass hier kein dynamischer Parent-Class-Constructor vorhanden ist.
Auch auf der offiziellen Website von Brut (https://brutrb.com/overview.html) gab es interessante Inhalte.
Ich habe versucht, mich auf der Beispielseite anzumelden, bin aber direkt nach der GitHub-Authentifizierung auf einen Fehler gestoßen.
Ich nutze Ruby noch nicht, aber das Projekt hat mein Interesse geweckt, deshalb habe ich einen Star vergeben. Vielleicht bringt mich dieses Projekt dazu, Ruby tatsächlich auszuprobieren.
Besonders die Wahl von Phlex hat mir gefallen. Ich frage mich, ob dieses Framework auch gut zur Datastar-js-Bibliothek und deren Einsatz von SSE (Server-Sent Events) passen würde; danke.