Rails World '26: Lexxy for Action Text

I was in the audience at Rails World 2026 for Jorge Manrubia’s talk on Lexxy, a new rich text editor for Action Text. Jorge is a Principal Programmer at 37signals, and if you’ve used Active Record Encryption, you’ve used something he built.

Jorge explained why 37signals built a new editor, what Lexxy adds, and how the work opens Action Text to other editors beyond Trix, the editor that’s shipped with Action Text since day one.

In this post, we’ll walk through why Trix became a maintenance burden, why 37signals picked Meta’s Lexical framework over the more obvious open source contenders, and what Lexxy actually does differently inside Action Text.

The Problem

Trix is built on contenteditable, the browser API that lets any element become an editable rich text region. Jorge’s core concern about it wasn’t that it lacked features. It’s that contenteditable behaves differently across browsers, and sometimes changes behavior entirely when an operating system ships an update.

He described browser and operating system updates repeatedly breaking Trix in different ways, with no code change on 37signals’ side to point to.

That instability wasn’t a one-off. 37signals had been circling the “do we need a new editor” question for years without pulling the trigger:

• 2022: A two-week attempt at adding table support to Trix, dropped because tables didn’t fit the editor’s model in a way the team found acceptable.

• 2023: a quick evaluation of TipTap for Hey, driven by the specific problem of composing replies inside an email’s existing formatting. The effort didn’t go anywhere.

• 2024: Writebook shipped with House, its own markdown editor: a “what you see is what you mean” editor that shows markdown syntax with light visual formatting on top. It works well for long-form writing, but when 37signals tried applying that same approach to a more general product early in 2025, it didn’t feel right for everyday use.

That last attempt is what restarted the conversation in earnest. Early 2025, the team went back to evaluating editors from scratch.

Why Not TipTap

TipTap came up again as the obvious open source contender, and Jorge was direct about why 37signals passed on it: it’s an open source project with a venture-backed company behind it, and that setup creates a structural tension.

Features can move between the open source and paid tiers over time, or a company can decide that certain fixes only ship under a license, and 37signals didn’t want to build a core piece of their product on top of someone else’s monetization decisions.

Why Lexical

That search led to Lexical, Meta’s open source rich text framework, and Jorge described the team falling for its design quickly.

The core idea isn’t new: Trix itself used a version of it more than a decade earlier. contenteditable is treated as a rendering surface, not the source of truth.

The actual state lives in a document model, and every edit produces a new snapshot of that model rather than a direct mutation of the DOM.

From there, Lexical exposes a small set of primitives:

• A reconciler that diffs two document snapshots and applies the minimal set of DOM changes needed, the same idea behind virtual DOM diffing in UI frameworks.

• Commands, a global event bus other code can subscribe to and react against.

• Transformers, which let extensions listen for node changes and intervene, which is what makes Lexical’s extension model work well with the reconciler instead of fighting it.

The core itself has no dependencies. Everything else (rich text formatting, markdown, tables, clipboard handling) lives in separate packages built on top of those primitives.

Beyond the technical design, Jorge pointed to something less obvious: Lexical solves 37signals’ maintenance problem by proxy.

Lexical has hundreds of millions of users through WhatsApp and Instagram, so an obscure bug in some browser or Android version is more likely to get caught and fixed upstream before it reaches 37signals’ customers, something Jorge said had already happened more than once.

Jorge saw that incentive structure as a better fit than a VC-backed open source project: Meta makes money from the products built on Lexical, not from Lexical itself. He was upfront that he can’t know for sure how that will hold up over time, but said the team is much happier with this setup.

Building Lexxy

The plan going in was straightforward: adopt Lexical, pick the packages needed, add a toolbar, ship it. Jorge candidly shared that it didn’t stay that simple.

Building a genuinely good editing experience turned out to be a much bigger effort than expected. An editor has to handle an enormous number of edge cases: selection state spanning multiple elements with no natural DOM boundary between them, pasting formatted content from Microsoft Word, and dozens of other details that only show up once real users start typing into it.

The rollout happened in stages: development started in May 2025, a public beta followed that September, and it grew into a wider release as part of Basecamp 5 in 2026, once the editor had been through enough real-world use to be considered stable for general use.

The Differences Between Lexxy and Trix

Lexxy ships with a substantially broader set of features than Trix. Jorge walked through a list that included:

• Tables, something Trix never got past the prototype stage on.

• Native Markdown support, so pasted or typed markdown syntax gets converted as you go.

• Code blocks with syntax highlighting across more than 20 languages.

• Image galleries, with drag-and-drop and keyboard support, not just single inline images.

• Link creation by pasting a URL onto selected text, turning it into a link automatically.

• A mentions API, for referencing people or other records inside your application, generalized from patterns 37signals had already built separately in both Fizzy and Basecamp.

• Attachment previews for files like PDFs and videos, another feature that used to be built custom per-product and is now part of the editor itself.

The Action Text Integration

The part of the talk I found most interesting wasn’t about Lexxy as a standalone editor. It was about how it plugs into Action Text.

Action Text made an early design decision that turned out to matter a lot here: it normalizes rich text content, including attachments like images, files, and mentions, into a canonical HTML format that isn’t tied to any specific editor.

Trix has always done a conversion back and forth between its own internal format and that canonical HTML. Lexxy leans on the same idea, but takes advantage of Lexical’s built-in support for customizing how content gets serialized to HTML, so the format Lexxy writes out is the same normalized HTML Action Text already expects.

That shared format is what made a bigger change possible: Action Text used to only support Trix. Jorge credited Sean Doyle, a thoughtbot developer who had already opened a pull request proposing a configurable Action Text editor before Lexxy existed. After Lexxy shipped, Jorge’s team worked with him to get it across the finish line.

The result is an ActionText::Editor base class with adapters for Trix and Lexxy opens a new window , merged into Rails’ main branch months before this talk. Action Text is no longer tied to a single editor going forward, whether that’s Lexxy, Trix, or something else entirely.

Lexxy itself ships with an extension API, letting other code hook into it to define new node types, add new toolbar commands, and customize the editor further.

Jorge said Lexxy currently has around ten internal extensions in active use, with a similar number built for Basecamp on top of that API. His favorite example was Basecamp’s voice note feature, built entirely as a Lexxy extension.

The Future of Action Text

Jorge closed by framing this as more than a Trix replacement.

The bigger shift is that Action Text no longer has to mean one specific editor. It means a canonical content format with a pluggable editing layer in front of it, which opens the door for other teams to bring their own editor into Action Text if Lexxy or Trix aren’t the right fit for what they’re building.

Conclusion

The future of Rails is bright when it comes to the frontend and rich text editing features. I really appreciated Jorge’s explanation of why 37signals needed a new editor, and why that doesn’t mean the end of the road for Trix. Trix keeps working. It just won’t see further updates from 37signals, who are now putting their effort into Lexxy.

As a consultancy that focuses on modernization projects and sustainable software, I appreciate the conscious effort to have an adapter layer that is friendly to Trix, Lexxy, and future WYSIWYG editors.

Are you weighing whether Lexxy fits into your Rails app’s roadmap, now that Trix is no longer where 37signals is investing? Talk to us today! opens a new window