---

“An idea that is not dangerous is unworthy of being called an idea at all.” ― Oscar Wilde

💡 Idea

It all started with a simple idea, how can we share our codes over internet. The obvious start was to use a Version Control System and create a public repository in one of the managed VCS hosting sites. However, I soon realised this will not do a good justice to the User Experience as the changes has to be frequently committed, pushed and pulled by others to be synchronised at all time. So I went on internet to check if there is any tool that could do this out of the box and I could simply integrate or use as package to my solution.

✨ Inspiration

The first occurence to such solution came from the OG collaboration tool Firepad. I have long been introduced to Firepad, mostly as a note sharing application, however this time my interest piqued on about it’s internals. So I went to it’s GitHub repository, and learn the term Operational Transformation.

😵‍💫 Problems with Firepad

While going through source code and running the examples provided, I soon realised that albeit being developed in quite elegant way, it does not work for certain code editor, namely Microsoft’s Monaco Editor, which was going to be my preferred editor.

However, this also provided me with an opportunity to contribute to the repository and gain further insight on it’s working principles. I took over the challenge and managed to fix all the known irregularities experienced by developers time to time with Monaco Editor with Firepad. Of course, the changes were made public through a Pull Request to the repository.

During this, I came across another problem with the existing code. Despite it trying to attempt a much more granular pattern to handle each editor individually, it still loaded all of them into the final bundle. And not only that, but due to out of date package managers and bundlers, it was literally combining all the codes into one file and then minify it.

⚡ Realisations

Age and Popularity of the Firepad had caught up to it’s flexibility to changes. Hence, being unsatisfied with the state of the architecture and it’s ease to change and adopt new designs and requirements, I decided to build an alternative Open Source repository from ground up. I adopted Adapter Pattern at the core.

This helped the design to be not only simple and atomic in nature, but also opened up the avenue for consumer applications to write their own Adapters and run about anything on top of @otjs. In this process, I was also able to decouple parts of the system and made them communicate over defined protocols and interfaces.

👨🏻‍💻 Tech Stack

Technological choices so evolved while building this repository included the items listed as following:

---