5 Punkte von GN⁺ 2025-07-31 | 3 Kommentare | Auf WhatsApp teilen
  • 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 < AppPage definiert

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. WidgetsPage ist unter /widgets erreichbar)
  • 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

 
jhk0530 2025-07-31

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

Ich glaube, dieser Link sollte korrigiert werden.

 
colus001 2025-07-31

Ich glaube, der Link ist falsch gesetzt.

 
GN⁺ 2025-07-31
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.

    • Ich frage mich, warum man Forms per Klick-Event simuliert; worin besteht der Unterschied dazu, submit() direkt aufzurufen?
  • 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?

  • 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 bin der Autor; aktuell habe ich das Einloggen auf der Beispielseite zur Vermeidung von Missbrauch deaktiviert. Ich habe heute spontan entschieden, das Projekt öffentlich zu machen, und bin noch nicht bereit, Logins für alle zuzulassen. Man kann es lokal ausführen oder unter https://brutrb.com/adrs.html Seiten durchsuchen und Links anklicken.
  • 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.