Building a Visual Programming Language

When I started building CoCube, I imagined a general purpose tool that was as fluid to modify and introspectable as Emacs, rendered entirely by vector graphics, dynamic and reactive with "no waiting", local-first yet collaborative in real-time, and with robust capabilities for processing text. I wanted it to be usable by anyone, because everyone should be able to create useful tools that help them solve the problems they face personally instead of having to shop for an app that does (almost) what they want. I imagined someone could sit down and create in an hour that app or tool that they wished existed - but didn't have either the time or the technical expertise to build it from scratch. I wanted it to be something that given a bit of upfront effort could become a powerful solution to a wide variety of tasks. A tool that grows with you the more you invest in learning and using it.

See, I was frustrated. There was a pattern in how I used software:

In many cases it would have been a simple feature that would have prevented me from looking elsewhere. But, because I am just one person, small feature requests tend to be ignored. I never thought twice about this problem because it never crossed my mind that modifying the software myself was an option. And in most cases I was right - it wasn't. What changed my perspective was falling into the open-source Emacs ecosystem and community. What I came away with was a new perspective on software that can be summarized like this:

If you don’t like it, you should be able to change it.

Emacs was a tool that allowed me to stop the moment I had an idea for something I wanted it to do. I could, right where I was, add some functionality or change how something worked then resume what I was doing. As I used the tool these small modifications began to add up, sometimes completely changing how I worked. It felt like I was "breaking the software in" as the tool became more and more customized to what I personally needed it to do. I leveraged it do to everything from schedule my days to journaling to studying to writing. I managed projects using it and I used it to communicate. It became an extension of myself, and it was incredible. Until it wasn't.

The great thing about Emacs was that you could make it do anything. The crappy thing about Emacs was that things broke constantly.

There was always an issue - from CPU and memory usage to rendering bugs to data loss and on and on. I remember a week where I had easily spent 20 hours just trying to find and get rid of various bugs that had crept into my system. It started to feel like a part-time job just keeping this system running well. Every day I’d get thrown out of the flow I was in because something wasn't working how it should. I began to feel anxious about depending on it as much as I was. Figuring out the source of problems was was worth the time at first because the system provided so much value. Unfortunately, the problems seemed to keep coming. When I realized I was fighting an uphill battle, I had to reassess.

I quit using the software. I felt that my time was better spent using the rigid, restricted software I had used before - because even if it wasn't perfect for me, at least it worked (put another way - at least I could focus on my work). The experience made me think. What if it were possible to build and share software that could be truly deconstructed and pulled apart and modified - while also being extremely easy to use, with none of the technical hurdles I had gone through? What if it was built on a platform designed for the future - and not one designed to work on computers from 30 years ago? What would that look like?

That vision is starting to come through. What I really want with CoCube is to provide a platform that allows people to come together and create small utilities and components, then share those with each other to build bigger and better things. Like emacs, CoCube allows you to pull apart, rearrange, and modify anything you find. It uses a novel approach to reactive programming and shares a lot in common with spreadsheet software, so that anyone can pick it up and start building right away. It is local first so you can own your own data. It is deeply collaborative. It is general purpose and flexible. And, hopefully, it is enjoyable to use. Right now, you can log in to CoCube, create a reactive component, add collaborators to it, work together on it, and share it publicly. These components/documents (called Cubes) are the building blocks CoCube allows you to create, modify, compose, and share. Unlike most software, these components are not static, but they are collaborative documents, meaning that anybody interacting with the component will see the changes everyone else makes to it in real-time. A text box isn't just a text box - it's something you can share with others, and the result is a real-time collaborative text editor.

Ideally, someone would build a personal set of tools and components that they could use to efficiently do whatever it is they needed to do. They could share pieces of these tools with the community. They could share parts of their system with the people they work with. And they could enjoy making their computers solve their problems - instead of waiting for someone else to, regardless of whether they are building a personal knowledge management system, automating a process at work, building a new todo app with the features you need, creating tools to help you study, or anything else.