Handling rich-text content within applications is a notoriously difficult problem, with traditional WYSIWYGs yielding only a monstrous mess of markup. I have seen the need and opportunity to build more sophisticated and deterministic solutions for obtaining rich-text, which has led to building editors atop cutting-edge tools.

The first milestone I would mention in this connection was the release of draft.js, which finally replaced the free-form content & post-processing strategy of WYSIWYG editors with a direct flow of data from keypress down into a well-determined schema—something for which the React developers were well positioned, given their commitment to unidirectional data flow and clarity. Shortly after the release of Draft.js, I began to construct a document editing application around it for campus use. One minor open source contribution that I made at this time was typically seeing 15-30k downloads a month from npm.

Beyond the clean, immutable data flow and adherence to a logical schema, one of the key elements that I found powerful in Draft.js is the ability to include content that is beyond user control, and essentially static or atomic, within the flow of user-supplied text. This capability opens up much more rigorous templating capabilities, which is one of the key elements missing in other uses of online document systems. For background: on some projects long prior to these developmemnts, I used the Google Docs API to integrate their editor into the flow of soliciting document-like write-up from users, but that system lacked any ability to carefully control where the user may write, what they may not overwrite, etcetera. Betweeen having a schema (therefore, forbidding certain types of content under certain areas) and static content within the same interface (forbidding any user overwrite or deletion), I was able to build a document editor that permits the user to write their own rich text into the flow of an existing, carefully templaed document.

I eventually, however, ran into a wall with the capabilities of Draft.js when it comes to more tree-like nested content, particularly for tables. At this point, I moved my work over to Slate, which inherits some of the ideas behind Draft but takes the requirement of a nested schema to be a much more crucial design element, and significantly improves on the logic one can communicate via the schema rules. Over time, I’ve contributed very significant PRs to shape slate in the direction I needed where it was lacking, including its testing capabilities and substantially overhauling its decorations.

My “deep” reworking of a prior table plugin for slate’s prior version was long the de facto option (typically at least 10k downloads per month) for anyone using the library, since the only prior implementation eventually decided to fork the base project, and could never support content within cells, eg. list items inside a table cell.

The first very largest and demanding project on which I used these tools was the Online Syllabus Editor for the University. I built an editing interface using Slate, powered by a strict templating logic worked out in my own tag system, and guided by a principle that every document has 3 distinct and independent layers: a template (providing the skeletal structure, some default or locked content), data (the course details, eg. credit hours), and edits (user-submitted rich text data). My implementation—which still powers many thousands of syllabi every semester, from thousands of users, presented via server-side rendering to tens of thousands of students—keeps these three layers independent so that even a published syllabus’s list of textbooks will change when the bookstore changes their listing, and I can update templates with corrected language for university policies centrally and instantly. This project required many years of working directly with departments and areas with unique needs, as well as integrating with other campus systems and workflows.

Later, I have worked at the intersection of text editing and NLP, solving many problems in the space of moving text from rich, complex marked-up structures over into plain text with aligned offsets, so that I can render annotations provided by a plain-text NLP stack correctly into the DOM tree. See my work on in-browser NLP.

Finally, in my role at Slite, I have led the development of a collaborative editor that is rich with complex features of many kinds, and which typically has over 10k concurent users at any given moment. Over the years of my work at this company, I steered the editor through many technological challenges and migrations.