HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
basecamp
trix
JavaScript2015–2022
basecamp / trix

trix

A rich text editor for everyday writing

16Distinct people
16Mentions
0Explicit recommenders
20KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A rich text editor for everyday writing

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year16 dated mentions

Observed mentions: 2015-10-19 03:08:04 UTC to 2022-06-30 11:50:41 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC514
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC413
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Trix A Rich Text Editor for Everyday Writing Compose beautifully formatted text in your web application. Trix is a WYSIWYG editor for writing messages, comments, articles, and lists—the simple documents most web apps are made of. It features a sophisticated document model, support for embedded attachments, and outputs terse and consistent HTML. Trix is an open-source project from 37signals, the creators of Ruby on Rails. Millions of people trust their text to us, and we built Trix to give them the best possible editing experience. See Trix in action in Basecamp. Different By Design When Trix was designed in 2014, most WYSIWYG editors were wrappers around HTML’s contenteditable and execCommand APIs, designed by Microsoft to support live editing of web pages in Internet Explorer 5.5, and eventually reverse-engineered and copied by other browsers. Because these APIs were not fully specified or documented, and because WYSIWYG HTML editors are enormous in scope, each browser’s implementation has its own set of bugs and quirks, and JavaScript developers are left to resolve the inconsistencies. Trix sidestepped these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all. This is the approach that all modern, production ready, WYSIWYG editors now take. Built on Web standards Trix supports all evergreen, self-updating desktop and mobile browsers. Trix is built with established web standards, notably Custom Elements, Element Internals, Mutation Observer, and Promises. Getting Started Trix comes bundled in ESM and UMD formats and works with any asset packaging system. The easiest way to start with Trix is including it from an npm CDN in the <head> of your page: <head> … <link rel="stylesheet" type="text/css" href="https://unpkg.com/trix@2.0.8/dist/trix.css"> <script type="text/javascript" src="https://unpkg.com/trix@2.0.8/dist/trix.umd.min.js"></script> </head> trix.css includes default styles for the Trix toolbar, editor, and attachments. Skip this file if you prefer to define these styles yourself. Alternatively, you can install the npm package and import it in your application: import Trix from "trix" document.addEventListener("trix-before-initialize", () => { // Change Trix.config if you need }) Creating an Editor Place an empty <trix-editor></trix-editor> tag on the page. Trix will automatically insert a separate <trix-toolbar> before the editor. Like an HTML <textarea>, <trix-editor> accepts autofocus and placeholder attributes. Unlike a <textarea>, <trix-editor> automatically expands vertically to fit its contents. Creating a Toolbar Trix automatically will create a toolbar for you and attach it right before the <trix-editor> element. If you'd like to place the toolbar in a different place you can use the toolbar attribute: <main> <trix-toolbar id="my_toolbar"></trix-toolbar> <div class="more-stuff-inbetween"></div> <trix-editor toolbar="my_toolbar" input="my_input"></trix-editor> </main> To change the toolbar without modifying Trix, you can overwrite the Trix.config.toolbar.getDefaultHTML() function. The default toolbar HTML is in config/toolbar.js. Trix uses data attributes to determine how to respond to a toolbar button click. Toggle Attribute With data-trix-attribute="<attribute name>", you can add an attribute to the current selection. For example, to apply bold styling to the selected text the button is: <button type="button" class="bold" data-trix-attribute="bold" data-trix-key="b"></button> Trix will determine that a range of text is selected and will apply the formatting defined in Trix.config.textAttributes (found in config/text_attributes.js). data-trix-key="b" tells Trix that this attribute should be applied when you use meta+b. If the attribute is defined in Trix.config.blockAttributes, Trix will apply the attribute to the current block of text. <button type="button" class="quote" data-trix-attribute="quote"></button> Clicking the quote button toggles whether the block should be rendered with <blockquote>. Integrating with Element Internals Trix will integrate <trix-editor> elements with forms depending on the browser's support for Element Internals. If there is a need to disable support for ElementInternals, set Trix.elements.TrixEditorElement.formAssociated = false: import Trix from "trix" Trix.elements.TrixEditorElement.formAssociated = false When Trix is configured to be compatible with ElementInternals, it is also capable of functioning without an <input type="hidden"> element. To configure a <trix-editor> element to skip creating its <input type="hidden">, set the element's willCreateInput = false: addEventListener("before-trix-initialize", (event) => { const trixEditor = event.target trixEditor.willCreateInput = false }) NoteTrix will always use an associated <input type="hidden"> element when the [input] attribute is set. To migrate to <input>-free support, set willCreateInput = false, then render the <trix-editor> without the [input] attribute. WarningIn the absence of an <input type="hidden"> element, the <trix-editor> element's value will not be included in <form> element submissions unless it is rendered with a [name] attribute. Set the [name] attribute to the same value that the <input type="hidden"> element would have. Invoking Internal Trix Actions Internal actions are defined in controllers/editor_controller.js and consist of: undo redo link increaseBlockLevel decreaseBlockLevel <button type="button" class="block-level decrease" data-trix-action="decreaseBlockLevel"></button> Invoking External Custom Actions If you want to add a button to the toolbar and have it invoke an external action, you can prefix your action name with x-. For example,
Read the full README on GitHub

What Hacker News says

16 sources
While I agree we (as in the internet at large) haven't solved the text editor problem, by saying "web components have failed" you're concluding in bad faith. If such a "universal rich text edit" web component comes out, have web components then succeeded? Then failure isn't such a permanent state as your comment implies, rather an indication of work yet to be done. Unless you'd like to clarify more, your comment seems to me like you're flinging mud without being able to back it up. What's the reason for that? Of note, Trix has been using the `customElements` standard since forever: https://github.com/basecamp/trix/ There's also slate, the (old!) tinymce, umm... I know I've at least experimented with a good couple more I can't recall. And, on the topic of components I wish existed (anywhere - react, vue, angular, etc - anything), I've been
Read the rest
searching for a good rich multiselect for a long time! If you know of any please let me know :)
In Show HN: A renderless and extendable rich-text editor for Vue.js
> The MIT license is replaced with a custom, ‘free for non-commercial and evaluation’ license This is really all I want out of anything. I don’t want to pay to evaluate, just to see if it’s a good fit. But if I’m going to use something commercially, I actually want to pay for it, at least if that thing is a complicated component like a rich text editor or handsontable. These open source projects usually have 1-2 developers who account for 95% of code changes[0][1]. If they went away, the project would die. Commercially, that’s a huge risk. EDIT: Just read this license. I wonder why they went with license keys? [0] https://github.com/quilljs/quill/graphs/contributors [1] https://github.com/basecamp/trix/graphs/contributors
In Handsontable drops open source for a non-commercial license
I'm surprised to see no mention of the Trix editor here amongst the comments about how contentEditable is the root of all evil. Trix has a nice solution, from their readme: Trix sidesteps these inconsistencies by treating contenteditable as an I/O devi- ice: when input makes its way to the ed- itor, Trix converts that input into an editing operation on its internal docum- ent model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all. Trix is from basecamp, and has a super healthy plugin/extension ecosystem - https://github.com/basecamp/trix Full disclosure: not affiliated at all, but the rare times I need a WYSIWYG editor I tend to look for Trix and be very pleased.
In Pell – A simple and small rich-text editor for the web
Disclosure: As the maintainer of Quill, I am much more aware if its strengths and have worked hard to limit its weaknesses. The main idea behind Trix as stated in their README[1]: "Most WYSIWYG editors are wrappers around HTML’s contenteditable and execCommand APIs... Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all." I think the first portion is only historically true. Everyone has figured out contenteditable/execCommand alone is a problem and all notable editors I have seen released in the past few years have reas
Read the rest
onable solutions--Trix's solution included. Quill is slightly different in that it prevents problematic operations in the first place and reimplements them itself, such as enter and backspace, but the main idea is the same: maintain a document model as the source of truth, define operations to mutate it, and build an editing experience on top of this. Some strengths unique to Quill: * API Quill has the most powerful API of any editor I have seen. You can make any text or formatting change in any part of the editor at any time. Trix by contrast only allows changes to the current selection. * Modules Quill's internals are broken into modules[2] that themselves can be configured or even swapped out. Many modules also include their own APIs. Trix does not have documentation in this regard, but looking at its codebase, it does not appear designed to support major modification of its internals. * Formats/Content Quill's document model itself is customizable, which allows users to define their own formats or customize existing ones. This capability is what kicked of 1.0 development, now being released today. This gives Quill extensive coverage of well known formats (tables to my knowledge is the only missing one), but more exotic formats/content like formulas, tweets or syntax highlighted code is also supported. Some editor frameworks have this same idea, but lack the actual editor and UI on top of this so you have to build a big portion of functionality to realize the full benefits. One main idea I'd like to highlight is this: Text is no longer written to be printed. It is written to be rendered on the web—a much richer canvas than paper. Quill 1.0 was designed and built to support this next generation canvas. [1] https://github.com/basecamp/trix#different-by-design [2] http://quilljs.com/docs/modules/
In Announcing Quill 1.0
I'd like to see someone write on how web based rich text editing tools store their textual data. Like, + [quill.js](https://github.com/quilljs/quill) + [draft.js](https://facebook.github.io/draft-js/) + [prosemirror.js] (https://github.com/ProseMirror/prosemirror) + [trix.js](https://github.com/basecamp/trix) Each of them might be relying on some form of Tree to store the content which actuates the views to react. I'm only guessing. A deeper, closer look might be interesting and useful.
In A Brief Glance at How Various Text Editors Manage Their Textual Data (2015)
Great timing, we were just looking for a new editor for our project. Since there are so many choices, here's a list of everything mentioned in this post. Trix - https://github.com/basecamp/trix - demo here: http://trix-editor.org/ by basecamp and used in v3, handles files/images well Squire - https://github.com/neilj/Squire - used in FastMail webmail, better for text than images ProseMirror - http://prosemirror.net/ - not great with images Scribe - https://github.com/guardian/scribe - by the Guardian team CKEditor - http://ckeditor.com/ - solid and very customizable, lots of plugins, a little dated in look/feel Quill - http://quilljs.com/ Summernote - http://summernote.org/ wysihtml - http://wysihtml.com/ Etherpad - http://etherpad.org/ - collaborative realtime editing TinyMCE - http://www.tinymce.com/ - older editor but still good Textb
Read the rest
ox.IO - https://textbox.io/ - new from the owners of tinymce project Froala - https://www.froala.com/wysiwyg-editor - solid editor, newer features like drag/drop images, v2 RC3 just released Redactor - http://imperavi.com/redactor/ - we used this in production but quality has gone down, v2 is half the functionality at 3x the price, not recommended anymore
In Trix: A rich text editor for everyday writing
+1 With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS. JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 130MB). They have poorer performance, can drain your battery faster, and some OS native features/guidelines must be implemented in a custom way, or could not be implemented/used at all. Sorry, for my critical and conservative view, but it's just my opinion (probably due to annoyance of overflow of laggy (web)apps, riddled with complex JS, where it could be avoided). Probably it's the price of 'cross-platformity'. [0] https://ww
Read the rest
w.youtube.com/watch?v=20BySC_6HyY (original site does not load for whatever reason) [1] https://github.com/basecamp/trix
In React Desktop – React UI Components for OS X El Capitan and Windows 10

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.