Stephen Margheim's wroclove.rb 2025 single-speaker 'teaser trailer' talk for Yippee (aka Yippi/Yippy), a new Ruby web framework he and Joel Drapper have been designing from first principles over roughly three years. No public GitHub — private repo, half-broken experiments — but the talk walks through the vision layer-by-layer and ends with Q&A. Opens with his background (@fractaledmind, fractaledmind.github.io), mentions his newest project Plume (a SQLite SQL dialect parser in Ruby, to be introduced next week at RubyKaigi), plugs the paid 'High Leverage Rails' course he made with Aaron Francis, and credits years of conversations with Joel Drapper (on Rooftop Ruby with co-host Colin and offline) as the origin of a shared 'taste' that sparked the project. Structure: persistent data → model layer → controller layer → view layer → testing → hosting/deployment → accessories → philosophy → wild vaporware ideas. Core constraints declared on day one and immovable: (1) SQLite-only — primary data, cache, job queue, pub/sub, full-text-search all in separate SQLite databases; (2) single-machine deployment with a persistent file system. Consequence: N+1s become a feature — because indexed in-memory reads have ~nanosecond latency with no serialization/HTTP overhead, many small simple queries hit indexes and cache better than one big join, and 200 queries per request become reasonable. Model layer borrows the repository pattern but with renamed collaborators: **resource** (what you present to the HTTP request/response cycle), **model** (what you present to the application), **table** (one specific type of **data source**; other data sources include joins and values). Layers can be collapsed (Active-Record-style one-file-per-table) or expanded (one model for three tables, three models for one table) as needed — the 'accordion'. Embraces query building over AR's model-as-table style, powered by a Plume-based SQL parser; code sample shows a fluent Ruby query builder with a nested EXISTS sub-select for tag filtering. Even more radical: a pure-Ruby-hash representation of SQL (using constants, nested hashes, arrays, booleans as AST nodes) that is Turing-complete for SQL and adds the one feature SQL lacks — composability. Controllers: inspired by Roda but rewritten — a routing tree where a controller is a single class whose `handle` method pattern-matches on HTTP verbs and path segments, with zero boot-time route parsing (constant start-up time regardless of number of routes, singledigit-millisecond boot as a goal). You can have one controller per app, one per resource (Rails-style), one per action (Hanami-style), separate controllers for member vs collection actions, or inline hash-based dispatch for hot paths — all mixable. Code samples show collection+member actions in one class, delegation to a nested controller via `two_proc`, and hash-based dispatch. View layer fully embraces Phlex (views, components, kits) and selective rendering (Phlex can no-op unused methods to return tiny Turbo-Frame-scoped payloads); everything is a Phlex class extending Literal::Properties. Explicitly encourages hundreds of queries inside views for locality of behaviour, arguing the only reason Rails/MySQL/Postgres apps avoid this is that p50 collapses under reckless partial nesting — a problem SQLite removes. Testing goal: 10,000 tests (unit, system, browser) in ≤1 second, ideally 100 ms. Uses quickdraw's test-runner which saturates every CPU core, plus per-thread in-memory SQLite databases cloned from a single-fixture-step template, plus high-leverage shortcuts (e.g. in test mode Phlex produces a queryable AST instead of an HTML string to skip a parse step). Recommends a new Zig-based headless browser for fast browser tests. Hosting/deployment: framework spins up Digital Ocean or Hetzner machines given an API key; deployments should be sub-second. Key idea: isolate fine-grained deployment types — application (Ruby change), infrastructure (e.g. C utility security patch), schema — coordinated via a framework-managed deployment queue so you can say 'make these changes now' and always run them serially and safely. Docker yes for infrastructure, no for app deployments (don't rebuild an image for every character change). Accessories: batteries-included exception monitoring (incl. CSP violations), performance monitoring, background-job monitoring, logs, database inspection — all shipped. Philosophy: an aggressive love of simplicity yields leverage, leverage yields value; and the 'accordion of complexity' lets applications collapse trivial paths into one file and expand complicated paths into many named layers with clear contracts. Explicitly against YAML config ('a scourge and a cancer, burn it with hot fire') and against excessive generated configuration. Full-vaporware wild ideas: a Bootsnap replacement that writes Ruby VM instructions to a single SQLite database file (inspired by 'SQLite: 30% faster than the filesystem') and ships that one file as the deployment artifact; purely declarative migrations (describe the desired schema, the framework synthesises the safest/fastest transition); running CI locally on your laptop and, once green, deploying — all in under a second. Q&A: one attendee praised the SQL-as-hash representation and 'treat the database as a variable' framing; the recorded question asked how routing trees find the right controller at request time when cost is moved from boot to request, and Margheim answered that Ruby is fast enough and the tree is cheap to walk, with hash-based dispatch available for truly hot paths. A second attendee disclaimed defending YAML. Also jokes throughout about the Polish audience's 'coldness' and his own marriage.