Trix: A rich text editor for everyday writing

quick experiment: after copying the original text 200 times into the text box it starts to be unbearable to write any new text. However, if one just inserts 200k characters with no formatting, the editor doesn't seem to slow down.

I don't get these simplistic editors. You just have to learn ten HTML tags to do the formatting these editors offer.

What would be useful though, would be an editor that supported "design" and not just text.

Has anyone tried to embed Trix into React? How all this custom tags and polyfills will behave inside react component tree (even though shouldComponentUpdate will always return false)?

There is https://github.com/souporserious/react-trix but it looks like it does nothing at the moment.

Agreed.

This is a very astute observation. When I was developing Gate One I experimented with something similar for terminals (using contenteditable to work around issues with keeping elements up-to-date while retaining formatting) but ultimately ran into severe performance problems. That was years ago though and browsers have gotten much better at handling contenteditable with larger amounts of text.

However, the more tags you add to contenteditable elements (i.e. for formatting) the more work the browser has to do every time there's a page reflow and there will be a reflow every time the text changes. So the more formatting, the slower (less responsive) it will be.

The workaround for this (no idea if it's used in this editor) is to divide the document up into lots of individual elements with contenteditable=true and make sure that all outside-the-view elements are removed or at least hidden via 'display: none' and merely re-show them on-the-fly as the user moves about the page. Keeping a page or two above and below the view pre-rendered can help with responsiveness and you'd also have to make sure to pre-fill all the document's unseen space with whitespace so that the user can scroll to any position accurately even if the browser is still retrieving and rendering that portion of the document.

I came very close to implementing such a solution but ultimately decided on something else entirely (server-side rendering and a difference-based terminal update protocol). It's a great idea for an editor and tows the line of, "what we're supposed to be doing" on the web but ultimately it requires a lot of complicated code. Far more complicated that one would think at first glance.