DEV Community: Marvin Ahlgrimm

Do AI Coding Agents Need a Different CSS Architecture?

Marvin Ahlgrimm — Thu, 22 Oct 2026 11:25:12 +0000

Does BEM Still Make Sense When AI Writes CSS?

I use BEM. Sometimes.

Most of my CSS is plain CSS, with a main stylesheet and a few additional files for specific areas, such as blog.css. The HTML is rendered on the server using Marten. During deployment, a minifier takes care of the CSS, and Marten's collectassets handles fingerprinting.

That's pretty much my entire CSS toolchain. And I like it. There's very little overhead, and it does everything I currently need.

But with AI coding agents writing more of my code, I started wondering whether my approach still made sense. Should I use BEM more consistently? Switch to data attributes for modifiers? Or consider something like Tailwind or CSS Modules?

I ended up asking a Codex agent whether replacing BEM modifiers with data-* attributes would improve an existing project.

Its answer was rather simple:

data-* doesn't automatically make sense as a replacement for BEM modifiers.

Well, that wasn't quite the answer I expected.

But it got me thinking. Maybe the more important question isn't which CSS methodology an agent should use, but how to make sure it understands the decisions already made in a project.

BEM, modifiers, and data attributes

Here's a typical BEM example:

<article class="card card--featured">
  <h2 class="card__title">Hello World</h2>
  <p class="card__description">
    A short description.
  </p>
</article>

I like how predictable this is. The relationship between the elements is obvious, and I don't have to worry too much about a generic .title selector affecting something elsewhere.

That's useful when working with global CSS.

Of course, BEM doesn't actually isolate styles. It relies on naming conventions to avoid collisions. And I don't think every simple layout needs a complete BEM structure.

But what about modifiers?

Instead of:

<button class="button button--primary button--large">
  Save
</button>

I could write:

<button
  class="button"
  data-variant="primary"
  data-size="large"
>
  Save
</button>

I actually prefer the second version here. The attributes make it clear that variant and size are independent properties.

Modern CSS handles this quite nicely:

.button {
  padding: 0.5rem 1rem;

  &:where([data-variant="primary"]) {
    background: var(--color-primary);
    color: white;
  }

  &:where([data-size="large"]) {
    padding: 0.75rem 1.5rem;
  }
}

Using :where() prevents the attribute condition from adding specificity. Without it, .button[data-variant="primary"] would be more specific than .button--primary.

So far, so good.

But Codex had a point. Compare:

<div class="card card--flat">

With:

<div class="card" data-variant="flat">

What exactly do I gain by replacing the first with the second?

Not much, especially if the existing modifier is already understood throughout the project.

I still like data attributes for components with multiple named variants. But changing working code just because another syntax looks a little cleaner doesn't seem particularly useful.

Do we need the modifier at all?

The Codex agent also raised a more useful point: if a component already exposes its state through a semantic attribute, why introduce another representation just for styling?

Imagine an accordion trigger:

<button
  class="accordion__trigger accordion__trigger--open"
  data-state="open"
  aria-expanded="true"
>
  Details
</button>

Now we have three representations of the same state. The BEM modifier says it's open, the data attribute says it's open, and aria-expanded says it's open.

Why?

For an ordinary disclosure component, I could avoid this entirely by using native HTML:

<details class="accordion">
  <summary class="accordion__trigger">Details</summary>
  <p>Some additional information.</p>
</details>

.accordion:where([open]) > .accordion__trigger {
  font-weight: bold;
}

The browser already manages the open state. And if I need several disclosure elements where only one can be open at a time, the name attribute on <details> can handle that too.

Not every accordion or disclosure interface fits the native element, of course. For a custom implementation, aria-expanded may still be necessary. In that case, I can use it directly for styling:

.accordion__trigger:where([aria-expanded="true"]) {
  /* Expanded styles */
}

Now there's less state to keep synchronized.

The same applies to disabled buttons. HTML already has disabled, and CSS provides :disabled. There's no reason to invent another representation of that state.

This doesn't mean adding ARIA attributes just for styling. They still need to describe the interface correctly. And data-* remains useful for custom states that don't have an appropriate native or ARIA representation.

But before introducing another modifier, it's worth checking whether HTML already provides what we need.

Would another CSS methodology help?

I also looked beyond BEM and data attributes.

CSS Modules, Tailwind, CUBE CSS, ITCSS, and other approaches offer different ways to organize or write styles. But for my setup, only a few seem particularly relevant.

CSS Modules

CSS Modules solves one of BEM's problems differently: instead of relying on globally unique class names, it scopes them during the build.

That's attractive. Classes like .title or .icon can be local to a component without requiring a naming convention.

But I'd also need a transformation step and a way to use the generated class mappings in my Marten templates.

If I were already using a component-based frontend with a build pipeline, CSS Modules would be an obvious candidate.

For my current setup, I don't have enough problems with class collisions to justify adding that integration.

Tailwind CSS

I initially associated Tailwind with a much larger frontend toolchain. That wasn't entirely fair.

Tailwind's CLI can compile static CSS during a build, without requiring React, Vite, or JavaScript in the browser. Adding it to my Containerfile wouldn't necessarily be difficult.

The bigger difference is how I'd work with CSS.

Instead of writing component styles separately, I'd compose utilities directly in the markup.

I can see why that's useful, including for AI agents. Tailwind provides a predefined vocabulary rather than leaving every class name up to the developer or agent.

But I still prefer meaningful component classes over long utility lists in my templates.

And Tailwind has conventions of its own, such as making sure its source scanner can detect the utility classes being used.

I'm not convinced that switching would make my development workflow better. It would mostly make it different.

CUBE CSS

CUBE CSS is probably the approach I found most relevant to my existing setup.

It separates Composition, Utility, Block, and Exception. I particularly like the distinction between layout composition and component styling.

Unlike CSS Modules or Tailwind, I can borrow these ideas without changing my toolchain.

I can keep my stylesheets, use BEM-style names where they make sense, and organize the CSS a little more deliberately.

And CSS itself?

Part of the reason I'm comfortable keeping vanilla CSS is how much the language has improved.

Nesting, custom properties, container queries, cascade layers, and @scope all address problems that previously required additional conventions or tooling.

For example, cascade layers let me explicitly define the precedence of different groups of styles:

@layer base, components, utilities;

And @scope lets me target elements within a particular part of the DOM without relying entirely on globally unique selectors.

It's now supported in current versions of the major browsers, although older browser support still matters. It isn't the same kind of isolation as CSS Modules either.

None of these features replaces BEM, but they give me more options for solving specific problems without introducing another toolchain.

What actually changed with AI?

After looking into these approaches, I couldn't find convincing evidence that AI agents produce more maintainable CSS with BEM, Tailwind, CSS Modules, or data attributes.

Each has plausible advantages.

Tailwind provides a shared vocabulary. CSS Modules offers local class scoping. BEM makes naming patterns predictable.

But I don't think we can conclude that one is inherently better for AI-assisted development.

What matters more to me is consistency.

If an agent works on a component that already uses BEM, it shouldn't introduce data attributes just because they look more modern.

If a component already exposes its state through aria-expanded, it shouldn't add data-state to represent the same thing.

And if the project already has design tokens, it shouldn't invent a slightly different color or spacing value for every new component.

So rather than replacing my CSS architecture, I've been making its conventions more explicit.

For one of my projects, I put the UI guidance into a repository-local Codex skill under .agents/skills/.

The skill describes existing components, where shared design tokens belong, how variants and UI states should be handled, and which stylesheets to look at. It also points to the component gallery, so an agent has actual examples rather than just abstract rules.

The relevant conventions can be summarized as:

## Component styling

- Follow existing component and CSS conventions.
- Reuse shared design tokens.
- Check existing components before creating new ones.
- Preserve clear BEM-style names.
- Use native HTML states where appropriate.
- Reuse semantically correct ARIA states for styling.
- Avoid duplicating state across classes and attributes.
- Use data attributes when they make variants clearer.

These are the principles rather than a verbatim extract from the skill.

In AGENTS.md, a short reference is enough:

For changes to UI templates, CSS, or visual Stimulus states,
use the repository-local UI skill.

I like this separation. The agent has access to detailed UI guidance when it's relevant, without loading all of it for unrelated backend work.

It's not a new CSS architecture. It's a way to make the existing one easier to understand and continue.

Of course, the skill doesn't guarantee correct code. I still have to review what the agent produces.

But it reduces how much of the project's styling conventions I have to explain repeatedly.

And perhaps that's where AI has changed my approach the most. Decisions that previously lived in my head now benefit from being documented somewhere an agent can find them.

So, is BEM still worth using?

For me, yes.

I don't see a reason to replace my current CSS setup. It's comfortable, requires very little maintenance, and works well for the applications I'm building.

I'll continue using BEM where it makes sense, use data attributes when they add clarity, and take advantage of modern CSS features when they solve an actual problem.

There's also plenty to learn from approaches like CUBE CSS without adopting an entirely new system.

But the most useful result of this research wasn't discovering a better naming convention.

It was making the conventions I already use more explicit.

And I still find it amusing that the Codex agent, which prompted me to question my CSS approach in the first place, ended up arguing against changing it just for the sake of change.

I think I'll take its advice on this one.

Hotwire Marten: Updating Just the Parts That Changed

Marvin Ahlgrimm — Mon, 12 Oct 2026 16:30:04 +0000

In the first part, we wired up Hotwire in a Marten application and built a small task list. Clicking "Create task" loaded a form into a Turbo Frame. Pretty nice for something that barely involved JavaScript!

But a task app where you can't complete a task feels a little broken. Nothing is done or is everything already done? Or maybe I just forgot to add some mechanisms for that 🤷🏻.

Let's fix that with Turbo Streams. New tasks should appear in the list without a full page reload, completing a task should update just that item, and deleting one should remove it.

Turbo, Stimulus, and importmap are already in place from the first part, so we can focus on the behavior this time. We'll start with task creation.

Render a task once

Before adding the streams, let's extract the markup for a task into src/templates/tasks/_task.html:

<li id="{% dom_id task %}">
  <span>{{ task.title }}</span>
</li>

The dom_id tag comes from marten-turbo. For a task with ID 42, it produces task_42. We'll use that ID later to update or remove exactly this element.

In tasks/list.html, replace the existing list with:

<ul id="tasks">
  <li class="empty">No tasks yet.</li>
  {% for task in records %}
    {% include "tasks/_task.html" %}
  {% endfor %}
</ul>

The surrounding "Create task" link and empty new_task frame stay as they were. The list now has an ID too, so we can append things to it.

One small detail: the empty message is always in the HTML. A little CSS handles its visibility:

#tasks .empty:not(:only-child) {
  display: none;
}

When a task appears, the message hides. When we delete the last task, it comes back. Conveniently, our stream responses don't have to do anything about it. Modern CSS is awesome!

Also add ordering :id to Tasks::ListHandler. We're going to append new tasks at the bottom, so the initial page should use the same order. Otherwise a reload could rearrange our list. Small but important!

Creating a task with Turbo Streams

Our create handler already knows how to validate and save a task. We can keep that and switch its parent class to the Turbo-aware version:

class Tasks::CreateHandler < MartenTurbo::Handlers::RecordCreate
  model ::Task
  schema TaskSchema
  template_name "tasks/create.html"
  turbo_stream_name "tasks/create.turbo_stream.html"
  record_context_name "task"
  success_route_name "home"
end

turbo_stream_name tells the handler which template to render after a successful Turbo submission. record_context_name makes the created record available as task, matching the variable our partial already uses.

Now create src/templates/tasks/create.turbo_stream.html:

{% turbo_stream 'append' 'tasks' template: 'tasks/_task.html' %}
{% turbo_stream 'replace' 'new_task' do %}<turbo-frame id="new_task"></turbo-frame>{% end_turbo_stream %}

That's the entire response template.

After saving, the task appears in the list and the form closes.

Why replace the frame instead of removing it? Our "Create task" link still needs that frame as its target. Replacing it also clears the src attribute Turbo added when it loaded the form, so clicking the link again can fetch a fresh form.

What about validation?

A successful submission is the easy part. Let's submit an empty title.

We want the form to stay open and show the error from Marten. For that, move the frame and form into src/templates/tasks/_form.html:

<turbo-frame id="new_task">
  <form action="{% url 'tasks_create' %}" method="post">
    {% csrf_input %}
    <label for="{{ schema.title.id }}">Title:</label>
    <input type="text" id="{{ schema.title.id }}" name="{{ schema.title.id }}">
    {% for error in schema.title.errors %}
      <p class="input-error">{{ error.message }}</p>
    {% endfor %}
    <button type="submit">Create</button>
  </form>
</turbo-frame>

Then replace the frame in tasks/create.html with {% include "tasks/_form.html" %}. Keep the page's template inheritance and content block around it.

I've removed the input's required attribute here so we can actually send an empty title to Marten and see its validation response. The schema still validates the title on the server:

class TaskSchema < Marten::Schema
  field :title, :string, max_size: 255
end

The old completed field is gone from this schema. Creating a task only needs a title; completion will get its own schema in a moment.

Add one more setting to Tasks::CreateHandler:

turbo_invalid_stream_name "tasks/create_invalid.turbo_stream.html"

And create that template:

{% turbo_stream 'replace' 'new_task' template: 'tasks/_form.html' %}

The handler returns a 422 response for invalid submissions and renders the form with Marten's validation errors. The form stays open so we can try again.

Finally, completing some work

Let's add a checkbox. First, a small schema in src/schemas/task_completion_schema.cr:

class TaskCompletionSchema < Marten::Schema
  field :completed, :bool, required: false
end

And an update handler in src/handlers/tasks/complete_handler.cr:

class Tasks::CompleteHandler < MartenTurbo::Handlers::RecordUpdate
  http_method_names :post

  model ::Task
  schema TaskCompletionSchema
  turbo_stream_name "tasks/complete.turbo_stream.html"
  record_context_name "task"
  success_route_name "home"
end

Add its route inside Marten.routes.draw:

path "/tasks/<pk:int>/complete", Tasks::CompleteHandler, name: "tasks_complete"

The handler only accepts POST requests. We don't need a separate page for editing one checkbox.

Its stream template, tasks/complete.turbo_stream.html, is another one-liner:

{% turbo_stream 'replace' task template: 'tasks/_task.html' %}

This time we pass the record itself as the target. The tag derives its DOM ID, so task becomes something like task_42, matching the <li> from our partial.

Now update _task.html:

<li id="{% dom_id task %}"{% if task.completed %} class="completed"{% endif %}>
  <form action="{% url 'tasks_complete' pk: task.pk %}" method="post">
    {% csrf_input %}
    <input type="hidden" name="completed" value="0">
    <input type="checkbox" name="completed" value="1" aria-label="Completed"{% if task.completed %} checked{% endif %}>
    <button type="submit">Save</button>
  </form>
  <span>{{ task.title }}</span>
</li>

And give completed tasks a little styling:

#tasks .completed span {
  color: #888;
  text-decoration: line-through;
}

Check the box and click Save. The task is saved and shown as completed.

There's a slightly sneaky detail in the form: the hidden input before the checkbox. An unchecked checkbox sends no value at all. We need an explicit 0 to clear an existing completion value. When checked, both values are sent, and Marten takes the last one: 1.

If you've used Rails form helpers, this probably looks familiar.

A little Stimulus, finally

The Save button works, but clicking it after every checkbox change feels unnecessary. This is a good job for Stimulus.

Generate a controller:

marten stimulus generate controller autosubmit

Replace its generated contents with:

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  submit() {
    this.element.requestSubmit()
  }
}

Then add the controller and action to the completion form:

<form action="{% url 'tasks_complete' pk: task.pk %}" method="post"
      data-controller="autosubmit" data-action="change->autosubmit#submit">

The checkbox's change event bubbles up to the form, where Stimulus calls submit(). We can put the Save button inside <noscript> so it's only displayed when JavaScript is disabled:

<noscript><button type="submit">Save</button></noscript>

Our importmap and controller loading were already configured in the first part. Rebuild and restart the server after adding the controller so its pin appears in the generated importmap.

Now clicking the checkbox submits the form, saves the task, and replaces the list item. Stimulus also connects the controller on the replacement form, so the next click works too.

And that's all the custom JavaScript for this feature. The controller doesn't even know what a task is. It just submits its form.

Deleting a task

We can create and complete tasks now. Let's also add a way to delete them.

Create src/handlers/tasks/delete_handler.cr:

class Tasks::DeleteHandler < MartenTurbo::Handlers::RecordDelete
  http_method_names :post

  model ::Task
  success_route_name "home"

  def turbo_stream
    MartenTurbo::TurboStream.remove(record)
  end
end

The handler also lets us return a MartenTurbo::TurboStream directly from Crystal. For deletion, that saves us a template file.

Add the route:

path "/tasks/<pk:int>/delete", Tasks::DeleteHandler, name: "tasks_delete"

And add a second form after the title's <span> inside _task.html:

<form action="{% url 'tasks_delete' pk: task.pk %}" method="post">
  {% csrf_input %}
  <button type="submit">Delete</button>
</form>

Click Delete, the record is deleted, and the stream removes its list item. If that was the last task, our empty message becomes visible again through CSS.

Where we ended up

We now have a task list where creating, completing, and deleting tasks updates just the relevant elements on the page.

What I like about the Marten integration is how little we had to add to our existing handlers. We switched to the Turbo-aware base classes, configured the stream templates, and reused the same task partial throughout. The only custom JavaScript is our small autosubmit controller, but it feels SPA like nonetheless!

A language for humans and computers: Crystal in the AI era

Marvin Ahlgrimm — Wed, 07 Oct 2026 15:44:46 +0000

At Rails World 2026, DHH described a division of labour that caught my attention: let agents write Rust and enjoy the result without having to look at the code.

At around 30:15 in the opening keynote, he puts it simply:

Agents like Rust.

I can see the appeal, and I see the same sentiment at my workplace. When an agent writes the code, the effort of writing it by hand matters less. The compiler can catch mistakes as the agent works.

But I still need and want to understand the software I am responsible for. For me, that points to Crystal.

I work with Ruby and Crystal and contribute to the Marten web framework.

Familiar syntax, static checks

Crystal combines Ruby-inspired syntax, static type checking and type inference, and compiles to native code. If you come from Ruby, much of it will look familiar.

That familiarity matters even when I am no longer typing every line. I still read the implementation, question its choices and make changes myself. Type inference keeps many annotations out of the way while the compiler checks how values are used.

Static checks on nullable values are available in other languages, too. What interests me about Crystal is having those checks in code I find straightforward to read. The agent gets feedback from the compiler; I get an implementation I can work with.

A compiler cannot choose the right tools

How do I know the agent chose the right libraries and integration approach?

Later in the talk, around 32:15, DHH describes assigning work asynchronously and reviewing the result. In my projects, that review includes the choices inside the implementation.

I recently tried setting up a small Marten application with only one prompt. During implementation, I had to correct the agent twice:

I wanted Marten Turbo and Marten Stimulus. The agent used npm to install the JavaScript packages instead of the CLI provided by Marten-importmap, which was the integration approach I wanted.
It started developing its own throttling middleware instead of using Marten-throttle.

I maintain these Marten shards, so I recognised the detours. npm was not the setup I wanted, and the custom middleware would have given me more code to maintain. Neither choice was a type error. Correcting them took knowledge of the project and its libraries.

Where compiler feedback has helped me

A few months ago, when the models I used were less capable, I repeatedly saw compilation errors in generated Crystal code. Some involved incorrect handling of String? values. In some cases, compiler feedback led the agent towards a correction without me having to explain the type problem myself.

A small example shows what the compiler can catch:

name = ARGV[0]?
puts name.upcase

The first argument might be missing. Its type is String | Nil, also written String?. Calling upcase directly is rejected because Nil does not provide that method.

An ordinary conditional handles the missing value:

name = ARGV[0]?

if name
  puts name.upcase
else
  puts "GUEST"
end

Inside the if branch, the compiler knows the local variable cannot be nil. Crystal documents this type narrowing and its limitations, including why repeated getter calls cannot always be narrowed in the same way.

Writing another if/else can feel tedious. I appreciate it more when an agent writes the code: I can see what it decided to do when the argument is missing.

Compiling still leaves a decision open

There is another way to get past the error:

name = ARGV[0]?
puts name.not_nil!.upcase

This compiles, but raises an exception when the argument is missing. The standard-library documentation describes that behaviour and recommends avoiding not_nil! where possible.

Ameba's Lint/NotNil rule flags the assertion in this example. With the rule enabled, the linter gives the agent feedback about a shortcut the compiler accepts.

The requirement is still open. Should a missing name produce a guest label? Should it stop the operation? Is absence supposed to be impossible? The compiler accepts both the guest fallback and the assertion. I still have to decide which matches the requirement.

I still need end-to-end checks in both Marten applications and fixes or features for Meridian, my deployment tool. Parts of that work can already be automated, but the agents I use do not reliably cover all my requirements.

Code and tests generated from the same misunderstanding can agree with each other.

Libraries and compiler feedback

The Marten experiment showed that I cannot assume the agent will find the libraries I want. In a smaller ecosystem, I need to name them and provide current documentation.

A study on code generation for low-resource programming languages explores how tools and feedback can help models work with less familiar languages. I do not know what caused the mistakes in my experiments. I check the agent's library choices and language usage either way.

Waiting for the compiler also adds up. Long development builds slow down every round of corrections.

The Generative Compilation preprint explores compiler feedback during the generation of partial Rust programs and reports improvements over feedback after complete generation. Its results suggest that the timing of compiler feedback matters as well as the checks themselves.

What Rust offers

Rust's ownership model and concurrency checks provide guarantees Crystal's garbage collector does not replace. Rust also offers cargo check and Clippy as feedback tools.

I have not benchmarked my Crystal workflow against Rust. If you work with Rust every day, you may find its code easier to review.

Crystal can be hard to read, too. Complex macros can hide what the code does, and its unsafe operations need careful review. I have to account for that effort even when an agent handles the implementation.

The code I still want to understand

I expect agents to do more implementation work. In my projects, I still need and want to judge the result, check requirements and understand enough to make changes.

With Crystal, static feedback helps the agent correct certain mistakes, and its syntax helps me inspect the decisions that remain.

Crystal calls itself a language for humans and computers. As computers take on more of the writing, the human side becomes a reason to choose it. I want to delegate implementation and remain capable of understanding and changing the result. Crystal makes that practical for me.

Hotwire Marten: Less JavaScript, More Interactivity

Marvin Ahlgrimm — Fri, 19 Jun 2026 07:05:29 +0000

Recently I came across a statement that a developer went back to Ruby on Rails from the Crystal ecosystem. The reason: missing Hotwire support. And honestly, I get it!

I'm a huge fan of the Hotwire utilities - you can write normal server code without too many frontend dependencies. In fact, Turbo brings SPA feeling out of the box!

I've been developing apps with Marten for a while. And all of them have had Hotwire built in. I've built a turbo extension for it quite a while ago, but the experience was never the same as with Rails. So I very much understand the statement to go back to Rails. Everything works out of the box!

Well, how should anyone know that there's already effort to bring better Hotwire support to the Crystal ecosystem, if nobody writes about it? So here it is! In this post I'll walk you through building a task app with Marten using the full Hotwire stack — Turbo Frames, Turbo Streams, and Stimulus. And beyond what's already available in marten-turbo, I'm currently working on importmap and Stimulus integration support, which is coming along nicely. I want to show you where things stand today.

Initializing the task app

Let's start by setting up a normal Marten project:

marten new project turbo_tasks

Hotwire integration? None 😩 But don't worry — it's relatively simple to add, and once it's set up, the tooling will feel quite natural.

Let's add marten-turbo and marten-stimulus. The latter will pull in marten-importmap as a transitive dependency:

dependencies:
  marten_stimulus:
    github: treagod/marten-stimulus
  marten_turbo:
    github: treagod/marten-turbo

Run shards install and we're halfway there.

We need to require the new dependencies and register the Marten apps:

# src/project.cr
require "marten_stimulus"
require "marten_turbo"

# src/cli.cr
require "marten/cli"
require "marten_stimulus/cli"  # also loads marten_importmap/cli

config.installed_apps = [
  MartenImportmap::App,
  MartenStimulus::App,
  MartenTurbo::App,
]

And just like that, Marten has Hotwire support! It recognizes Turbo tags, provides Turbo helpers, and adds CLI commands for importmap and Stimulus.

1. Initialize Importmap

Run:

marten importmap init

This generates:

config/initializers/importmap.cr
config/initializers/importmap_pins.cr
src/assets/application.js

2. Pin Hotwire dependencies

Now pin the required packages:

marten importmap pin @hotwired/turbo
marten importmap pin @hotwired/stimulus

3. Boot Turbo and Stimulus

Update src/assets/application.js:

import "@hotwired/turbo"
import { Application } from "@hotwired/stimulus"
import { eagerLoadControllersFrom } from "stimulus-loading"

const Stimulus = Application.start()
eagerLoadControllersFrom("controllers", Stimulus)

The stimulus-loading import is pinned automatically by MartenStimulus::App — no manual setup needed. It reads your importmap at runtime and registers any controllers it finds under the controllers/ prefix.

You'll also need to tell the importmap where your controllers live. In config/initializers/importmap.cr:

Marten.configure do |config|
  config.importmap.draw do
    pin "application", "application.js"
    # Add this line
    pin_all_from "src/assets/controllers", under: "controllers"
  end
end

Finally, add {% importmap %} to the <head> section of your base template. This renders the importmap JSON and the necessary preloads.

With that, the boring part is done. Let's build something.

Task App

Let's build something really innovative: a Task App. An app where you can create a task and mark it as complete once done. Never seen that before 🤞.

Well it's small enough to showcase the basics of this setup.

We'll create a task model, let Marten generate the migrations and create a turbo-augmented CRUD interface.

The model is kept fairly slim in order to not overload this post:

class Task < Marten::Model
  field :id, :big_int, primary_key: true, auto: true
  field :title, :string, max_size: 255
  field :completed, :bool, default: false
end

And run

turbo_tasks$ marten genmigrations
Generating migrations for app 'main':
  › Creating [src/migrations/202604270947501_create_main_task_table.cr]... DONE
      ○ Create main_task table
turbo_tasks$ # Migrate
turbo_tasks$ marten migrate
Running migrations:
  › Applying main_202604270947501_create_main_task_table... DONE

Create src/handlers/tasks/list_handler.cr and src/templates/tasks/list.html:

class Tasks::ListHandler < Marten::Handlers::RecordList
  model ::Task
  template_name "tasks/list.html"
end

{% extend "base.html" %}

{% block title %}Tasks{% endblock %}

{% block content %}
  <h1>Tasks</h1>
  <ul>
    {% for task in records %}
      <li>{{ task.title }}</li>
    {% endfor %}
  </ul>
{% endblock %}

Some more tweaking:

path "/", Tasks::ListHandler, name: "home" to your config/routes.cr
Add {% importmap %} right before </head> inside src/templates/base.html
spin up the server with marten s, and navigate to http://127.0.0.1:8000/.

Nothing fancy yet — just a list of zero tasks. But open your dev-tools and check the network tab: Turbo and Stimulus are already loaded without touching any further JavaScript beyond the initialization 😮‍💨.

From here on, we'll keep the setup intentionally small so the Turbo behavior stays visible.

Turbo enters the room

Let's add some basic Turbo functionality to see if it really works. We need a create handler, a schema, and a template:

class Tasks::CreateHandler < Marten::Handlers::RecordCreate
  model ::Task
  template_name "tasks/create.html"
  schema TaskSchema
  success_route_name "home"
end

class TaskSchema < Marten::Schema
  field :title, :string
  field :completed, :bool, required: false
end

{% extend "base.html" %}
{% block title %}Create Task{% endblock %}
{% block content %}
  <h1>Create Task</h1>
  <turbo-frame id="new_task">
    <form action="{% url 'tasks_create' %}" method="post">
      {% csrf_input %}
      <label for="{{ schema.title.id }}">Title:</label>
      <input type="text" id="{{ schema.title.id }}" name="{{ schema.title.id }}" required>
      <button type="submit">Create</button>
    </form>
  </turbo-frame>
{% endblock %}

Add path "/tasks/create", Tasks::CreateHandler, name: "tasks_create" to your config/routes.cr.

Now update the list template to have a link to the new create page:

{% extend "base.html" %}

{% block title %}Tasks{% endblock %}

{% block content %}
  <h1>Tasks</h1>
  <a href="{% url 'tasks_create' %}" data-turbo-frame="new_task">Create task</a>
  <turbo-frame id="new_task"></turbo-frame>
  <ul>
    {% for task in records %}
      <li>{{ task.title }}</li>
    {% else %}
      <li>No tasks found. <a href="{% url 'tasks_create' %}">Create your first one</a></li>
    {% endfor %}
  </ul>
{% endblock %}

Notice what's happening here: the "Create task" link has data-turbo-frame="new_task", which tells Turbo to fetch the create page and only extract the matching <turbo-frame id="new_task"> from the response. It swaps that frame into the empty <turbo-frame> on the list page — no full page reload, no custom JavaScript. Nothing new to seasoned Hotwire devs, but it's still worth mentioning!

Click the link and the form just appears inline. Submit it and you're back to the list with your new task. That's the SPA feeling Turbo gives you for free.

That's enough for the first part. In the next one, I'll go further into Turbo and how to use it to not replace the whole page of the task list when updating a task!

When AI Moved Into My Editor: Faster… and Weirdly Slower

Marvin Ahlgrimm — Fri, 03 Oct 2025 11:28:29 +0000

The first time I asked an AI to write a small snippet of code, I was flabbergasted. It worked—instantly. It saved me the usual search-and-compare detour, and that alone felt worth paying for.

This was back then when no Thinking models existed. But it was an immediate argument for a subscription for XYZ AI (no ad here 😬 just think of one of the many options).

From there, I went into a long phase of copy & paste: throw code at an LLM, ask it to analyze or rewrite, and stitch the result back in. It kind of worked. When reasoning models arrived, my confidence went up: wait a minute, wait three—freshly baked code appears. In Rails, that meant small adjustments and I was done. In Marten, I had to correct more, which made sense — newer framework, less model knowledge.

Then the next big thing happened: tools that could search the internet. (What kind of technological progress! The internet wasn't a trend that is going away anytime soon 🤯) I started asking the LLM to read Marten's docs first and then implement feature XYZ. Suddenly, I could use LLMs for Marten, too. Great! "No need for using my brain anymore," right? At least it felt like that — because the handler fixes took less time than before.

Except I still had to pour context into the model and explain compile errors or edge cases. It became a kind of pair programming where I asked for features and an inexperienced junior picked random things from the internet, threw them at me, and hoped it worked. Sometimes it did. Sometimes it didn't.

Next wave: MCP and CLI tools like Claude or Codex inside my editor. Now the LLM could read my files and pick up the context I’d been manually narrating. I could spin up the CLI, spell out a feature request, and it worked most of the time. When it didn't, I'd say what didn't work. And then again. And again. Also: I won't give an LLM permission to change my files without acknowledging its work first—so I kept the loop manual. That created a very familiar pattern: write the prompt → wait for results → correct the results → fine-tune. And yes, I sometimes forgot the CLI was sitting there waiting for my response, dragging on the cycle.

Recently it clicked that this can slow me down. The waiting, the corrections, the context coaching — it adds up. In Rails, this is fine for smaller features. In Marten, I still hit compile errors or subtle misuses that need careful guidance. And I don't want a bot silently editing my codebase while I lose track of what changed.

My trust issues mostly come from one experience: a bigger chunk of AI-generated code that "magically" worked — until I needed a behavior change. That request overstrained the model and it started producing incorrect fixes. Because I hadn't reviewed the initial output deeply, adapting it took longer than if I had either built it myself or reviewed it properly to make it adaptable from the start. That one was on me.

In my little delusion, I even thought AI could basically ship whole projects for me while I skimmed and sprinkled adjustments. Boy was I wrong. I kicked off a bunch of dear side ideas I didn’t have time for, assuming the model would carry them over the finish line. Instead I ended up with a constellation of half-baked repos — and a clear lesson: AI accelerates momentum you already have; it doesn't create it. It won't do the product thinking, the trade-offs, or the patient grind.

So I'm stepping on the brake a bit. AI is here to stay and it's impressive, but the "AI will take our jobs" hype is exaggerated. It can absolutely solve things — but it's not delivering the consistent quality of an experienced dev. What it does do well is guide you toward a correct path faster.

What I’m doing now (so it helps more than it hurts)

Start with a requirements doc. I write a short spec (goal, constraints, edge cases, acceptance criteria), manually refine it, and treat it as the single source of truth.
- If I have absolutily no idea what I'm dealing with I'm starting a deep research
Use AI for planning, code mostly by hand. From the spec, I ask the LLM “what’s next / risky / missing,” but I hand code most parts and only offload small snippets or algorithms.
Read the docs—with citations. With search enabled, I ask the LLM to analyze the documentation of some library/tool, read the answer and check the sources.
Scope it right. AI for scaffolding, glue, migrations, rote transforms; humans for domain logic and novel framework patterns.
Front-load constraints. State invariants, interfaces, and edge cases up front to avoid rework.
One prompt → one cohesive diff. Treat AI output like a junior’s PR; keep changes small and reviewable.
Tests first (or alongside). Have the model draft intent-revealing tests; they surface mismatches early.
Document the "why." Ask for a 5-line design rationale to stash next to the change.
Time-box retries. If the LLM had its third faulty try, I take over the tricky bit.
Never skip the review—even when it "just works." That’s where hidden debt sneaks in.

Conclusion

AI won’t take over anytime soon, but it will help to achieve our goals. Used well, it augments your knowledge and accelerates the momentum you already have.

Treat it like Little Helper to Gyro: exceptionally clever, creative, and efficient—but still a helper. Keep your guard up: review the final output, require citations when you rely on docs, and let tests plus a short requirements doc be the gatekeepers. That’s how AI helps more than it hurts.

Embrace the Default: Let HTML and CSS Do the Work

Marvin Ahlgrimm — Sat, 28 Jun 2025 10:55:42 +0000

We often reach for JavaScript too quickly.
But modern HTML and CSS can already do more than you think

Maybe you know the situation. You want to provide some intuitive user interface where the user has a nice UI with huge elements, like cards, that are easy to click on. You want to make sure that the user can easily see which element is currently selected. So you reach for JavaScript and add some event listeners to change the style of the element when it is clicked.

In my case the user had to select which payment type they wanted to use. So I had a list of payment types, each represented by a nice little card. The "cash" option should be selected by default and the user could click on a card to select it. The selected card should have a different background color to nicely indicate which payment type was selected and give the user a visual feedback. Because the cards don’t contribute to the form there has to be a way to tell the form which card was selected.

Being lazy my first thought was "I need to create another Stimulus Controller to handle the click and fill a hidden input with the selected payment type. Ugh..".

But then I thought about it for a second and realized that I could do this with just HTML and CSS.

The Solution: Radio Buttons

I don't know why, but radio buttons are not in my standard repertoire of UI elements. I always think of them as something old school, something that is used in the 90s. But they are actually a great way to implement the functionality I needed.

Radio buttons are a form element that allows the user to select one option from a set. They are perfect for this use case because they inherently support the concept of a "selected" state. When you click on a radio button, it automatically updates the state of the form, and you can style the selected button differently using CSS.

So I created a list of "hidden" radio buttons and labels that reference them via the for attribute. The labels are styled as cards, and when the user clicks on a card, the corresponding radio button is selected. The selected radio button can then be styled differently using CSS.

<div class="row">
    <% payment_methods = [
        [t('payment.cash'),        "cash",            "bi-cash"],
        [t('payment.creditCard'),  "credit_card",     "bi-credit-card"],
        [t('payment.online'),      "payment_pending", "bi-credit-card"],
        ] %>

    <% payment_methods.each do |label, value, icon| %>
        <div class="col-4">
            <%= f.radio_button :payment_kind,
                                value,
                                id: "payment_kind_#{value}",
                                class: "radio-card-input" %>

            <label for="payment_kind_<%= value %>"
                    class="card radio-card">
                <i class="bi <%= icon %>"></i><br>
                <strong><%= label %></strong>
            </label>
        </div>
    <% end %>
</div>

/* keep it in the DOM for a11y */
.radio-card-input {
  position: absolute;
  opacity: 0;                 
}

.radio-card {
  display: block;
  padding: 1rem;
  border: 1px solid var(--grey-200);
  border-radius: var(--radius);
  background: var(--white);
  text-align: center;
  cursor: pointer;
  transition: border-color .2s ease, box-shadow .2s ease;
}

.radio-card-input:checked + .radio-card {
  border-color: var(--primary);
  box-shadow: 0 0 0 4px rgba(var(--primary-rgb), .35);
}

.radio-card-input:focus + .radio-card {
  outline: 2px solid var(--primary);
  outline-offset: 2px;
}

.radio-card:hover {
  box-shadow: 0 2px 4px rgba(0,0,0,.06);
}

/* helper for nice icon sizing */
.radio-card i { font-size: 2rem; margin-bottom: .25rem; }

This allows the user to interact with the payment options in a very intuitive way and keep it accessible. The selected payment type is automatically stored in the form, and you can easily access it when the form is submitted.

But there is more!

Toggle Visibility with CSS

This is probably something you have seen before, but I want to show it again because it is so useful. You can use the :checked pseudo-class to toggle the visibility of elements based on the state of a radio button.

In my case I wanted to show a invoice form when the user selects the online payment option. I could have used JavaScript to show and hide the form, but instead I used CSS to toggle the visibility based on the state of the radio button.

Right underneath the radio button container I put another container <div class="invoice">. By default this container is hidden:

.row .invoice {
  display: none;
}

Then I use the :checked pseudo-class to show the container when the online payment option is selected:

.row:has(#payment_kind_payment_pending:checked) .invoice {
display: block;
}

How does that work?

:has() is the long-awaited parent selector: it lets you style a parent (here .row) if any child inside it matches a condition – in this case, the radio button with ID payment_kind_payment_pending is :checked. After decades of “CSS can’t look upwards,” :has() finally makes it possible 🤯. It’s a relational pseudo-class which ships in every evergreen browser.

Browser support & fallback

As of mid-2025, :has() enjoys ~93 % global support (Chrome 105+, Firefox 117+, Safari 15.4+, Edge 105+).

For the minority still on older engines, the invoice panel simply stays hidden. If you need to support these too JavaScript will probably solve this.

This way the invoice form is only visible when the user selects the online payment option. No JavaScript needed! And it’s accessible out of the box too!

Applying the Presenter Pattern in Marten

Marvin Ahlgrimm — Mon, 23 Jun 2025 14:54:22 +0000

I recently ran into a problem in one of my Marten projects. My Journey model — originally quite simple — ended up bloated with methods like travel_period, total_costs, sidebar data prep and more. Nearly every view needed these calculations, so my model was being polluted with logic that didn’t belong there.

Marten templates doesn't allow complex calculations, so I had to do these calculations in my models and access it in my template. But this made the model huge and hard to maintain. It felt wrong to mix UI logic with data persistence.

I wanted to keep my models clean and focused on their primary role: representing data in the database. But I also needed a way to prepare data for my templates without cluttering the model with view-specific logic.

To solve this, I borrowed a pattern from Rails and other ecosystems: the Presenter Pattern. Instead of stuffing the Journey model, I moved view-specific logic into a JourneyPresenter class. I then plugged that into my handlers so my templates could work cleanly with journey.

Here’s how I set it up.

Extracting a Presenter for my `Journey` model

My Journey model acts as a central wrapper — holding transports, accommodations, travelers, days, and so on. All my journey views show a sidebar with accumulated price, total traveler count, and other derived data. That made it a perfect candidate for moving presentation logic out of the model.

Initially I thought to use Object#delegate, but manually listing every method felt brittle.

Thankfully Crystal’s macro system allowed me to generate delegations compile-time. The result: a reusable Delegate module that forwards all public, zero-argument methods from the model and mixes in Marten::Template::Object::Auto, making them accessible in Marten templates.

module MartenPresenters::Delegate
  include Marten::Template::Object::Auto

  macro present(klass)
    {% ivar_name = klass.resolve.name.split("::").last.underscore.id %}

    {% unless @type.methods.any?(&.name.== :initialize) %}
      def initialize(@{{ivar_name}} : {{klass}}); end
    {% end %}

    getter {{ivar_name}} : {{klass}}

    {% for m in klass.resolve.methods %}
      {% if m.visibility == :public && m.args.empty? %}
        {% next if @type.methods.any?(&.name.== m.name) %}
        def {{m.name.id}}
          @{{ivar_name}}.{{m.name.id}}
        end
      {% end %}
    {% end %}
  end
end

This modules macro present takes a class, which is used to create a initializer that takes an instance of the class we want to present. It also creates delegation functions for all public methods that take no arguments (in assumption they are getters).

Sidenote: This could be extended to use a blacklist of methods to exclude.

The macro generates methods that delegate to the wrapped model, so I only need to call start_date! instead of journey.start_date!.

The present Journey call wraps up model attributes neatly and compile-time delegation avoids manual boilerplate.

Defining `JourneyPresenter`

class JourneyPresenter
  include MartenPresenters::Delegate

  macro finished
    present Journey
  end

  def end_time_formatted
    end_date!.to_s("%Y-%m-%d")
  end

  def total_costs
    total = Money.new(0, "EUR")
    days.each do |day|
      day.events.each { |e| total += e.price.not_nil! }
    end
    total.format(symbol_first: false)
  end

  def sorted_days
    days.order(:date)
  end

  def total_costs_per_traveler
    total = Money.new(0, "EUR")
    days.each { |d| d.events.each { |e| total += e.price.not_nil! } }
    (total / travelers.count).format(symbol_first: false)
  end

  def travel_period
    (end_date! - start_date!).days + 1
  end
end

Important note: I wrap present Journey inside a macro finished block. Without deferring it, the compiler wouldn’t have fully resolved Journey’s methods yet — so delegation wouldn’t include them all.

All Journey fields are directly accessible, e.g. #start_date! or #end_date!!

This presenter now handles formatting dates, accumulates prices and travelers, and provides ordered collections. Models stay lean, and templates stay expressive and focused.

Injecting the Journey Presenter into Handlers

I wanted a quick way to make journey available in my templates, so I built this mix-in:

module HasJourneyContext
  macro included
    before_render :set_journey_context
  end

  @journey : Journey?

  private def set_journey_context
    # Inject the presenter into the templates context
    context[:journey] = JourneyPresenter.new(journey)
  end

  private def journey
    @journey ||= Journey.get!(access_token: params["access_token"])
  rescue Marten::DB::Errors::RecordNotFound
    raise Marten::HTTP::Errors::NotFound.new("Journey not found")
  end
end

Using the Presenter in a Real Handler

Here’s an example handler that includes the mix-in:

class TravelerListHandler < Marten::Handlers::Template
  include HasJourneyContext # Include for simple usage of the presenter

  template_name "travelers/list.html"

  before_render :set_travelers

  private def set_travelers
    context[:travelers] = Traveler
      .filter(journey: journey)
      .order("-created_at")
  end
end

By including HasJourneyContext, this handler automatically injects a fully prepared JourneyPresenter into the templates context.

What This Achieves

Models stay focused on persistence — no mix of UI logic
Templates call {{ journey.travel_period }} or {{ journey.total_costs }} directly
Presenter class is testable in isolation
Handlers are lean and declarative
Macros generate safe, compile-time delegations
No global state, no hidden context—everything is explicit

Everything just works, and it’s easy to extend or test.