November 2023


Earlier this year, I came across Peritext – a CRDT for collaborative rich text editing. I skimmed over the authors' blog post, a research paper by the same team, and some related literature on distributed data structures. Peritext seemed simple enough that I wanted to implement it and see if I can make something useful out of it. With that goal in mind, I set out to build a browser-based collaborative rich text editor... from scratch.

I've always hated losing my zest for personal projects to a pile of third party libraries. With too many dependencies, an application is little more than a set of APIs calling into each other from within a murky node_modules directory. For corporate software that is supposed to be reliable and attract revenue, I can understand the need to ship fast and have fewer lines of code to maintain. But bringing this mindset home to exploratory hobby projects cheapens the experience.

My approach was to add a library only when its use-case was orthogonal to what I was building. So I wouldn't miss out on learning anything that might go into building real world collaborative software.

Besides, I was building a collaborative editor for browsers – applications that are ultra-optimized to render hypermedia and make network calls. Surely this wouldn't be too difficult, right? There ought to be plenty of APIs to manipulate formatted text in HTML, right? As I later found out, I was wrong on both accounts.

Building a good rich text editor that works in all major browsers is hard. Making it concurrent for multiple active users is even harder. The simplest way to decorate text in an editable HTML element – execCommand – is now deprecated (Though nearly all browsers will continue to support it, lest half the internet's text inputs break). Worse yet, there is no alternative to execCommand. The only other way to manipulate rich text is to roll your miniature DOM that models the hierarchy of rich text elements. Moreover, your object model has to be built such that incorporating collaborative editing is natural, and doesn't call for a rewrite. I won't go into all the details, but you get the idea – there be dragons.

After about three weeks, It occurred to me that I had unknowingly taken up two projects. One was to implement rich-text editing in browsers, and the other to design APIs and implement algorithms that allow making concurrent edits. I still tried to push through and build on top of my poorly designed block structure that didn't account for non-linear items in rich-text documents (e.g: comments, annotations in an image). So it should surprise no one when I say that in the following month, the project went down in flames.

And just like that, another one of my private GitHub repos bites the dust.

I hope to give it another try, this time with a clean slate and the benefit of hindsight. We shall see in my next update. o/


Mostly fiction, and a pinch of technical reading.


For me, Ted Chiang's best works are Exhalation, The Merchant at the Alchemist's Gate, and What's expected of Us.

Currently reading:

Plan to read:


After my last update, I'd begun working on an NES emulator in C++. Few weeks into development, it ground to a halt owing to my inconsistent routine and lack of interest. A while back, I decided to revive the project and port it to Zig.

Right now, its about 60% done. It cannot run any games just yet, but supports basic display and full CPU functionality. I only support one mapper, and the PPU is still a work in progress.

I don't plan for it to be another Mesen or FCEUX. It should support a good number of NES games, and have mostly accurate emulation for the games it does support.