Context: Birch is a 2d canvas-based editor and dev environment that runs code in the cloud. I've been writing a series of blog posts about its development which you can see here.
When I started working on Birch I wanted to own a product that I could polish and contribute to day in and day out. Something I could make incremental progress on and be happy with. I wanted a project that could theoretically make money in the future.
I've largely changed my perspective on this. I don't care about the 'day-in and day-out product' or the money as much as I care about working on the forefront of what technology could be. On top of that I've rethought some of the initial hypotheses Birch started with. If I were to continue down this road with Birch I would end up rewriting the entire frontend and a fair bit of the backend...
So I'm pivoting away from Birch! I am just so excited about exploring some other areas. I spent the last few days reading, brainstorming, and delving into some tools-for-thought literature. Keep an eye out 😄
But I also want to share some of my thoughts about Birch in the hopes that someone finds them useful and perhaps even picks up where I left off:
I tried seeing how good I could get it, but even with snap-to-grid, the organization and placement of cards had a larger overhead than seems warranted. It's nice to have all your cards visually laid out and organized, but getting there can be a hassle.
If I were to rewrite Birch I would use a multimedia list instead of a multimedia canvas. The "multimedia" here is important — tables, functions, charts, forms all in one conceptual place is a very good thing! The canvas... not so much.
For the last two months I had been thinking more and more about the whole "making money" thing. I was the dreaded "solution in search of a problem". Fortunately Birch is generic enough that it could apply well to a number of problems. The two I landed on:
It's harder than it should to write a backend when you only know frontend coding, i.e. Birch could evolve into a "Backed-as-a-service" Ã la Firebase, Supabase, etc.
It's harder than it should be to interact with existing APIs and services. i.e. Birch could evolve into a "Zapier for Programmers" - high-level building blocks for people who prefer writing code to dragging around pipelines.
I'm still optimistic about the potential in both of these spaces! Both quickly building APIs and easily interacting with APIs remain unsolved problems. There are a lot of people who stand to benefit here. This should at some level be able to finance the effort to help them, right? I hope someone takes this opportunity and runs with it!
If I were to spend more time on Birch the first thing I would do would be to put some serious thought into a better persistence interface. (Prolog, anyone?)
The same issue I encounter with APIs shows up in the database space: What is the easiest and most flexible way to persist data if you don't care about performance or safety? Sqlite? Filesystems? Redis set to persist mode? Mongo?
I don't think any of these are good answers. Key-value databases are conceptually simple but then users end up writing a query engine to deal with them. Don't get me started on SQL. There's a lot to say here that I'll save for another post, just: databases aimed at ease of use are not finished.
... at least if you're trying to be a backend-as-a-service.
Birch right now doesn't have a deploy step: anytime you finish editing a function it's immediately in production, potentially able to handle requests. This could be convenient for scripting, but is completely unacceptable for a backend-as-a-service since broken edit states can cause downtime!
The liveness is interesting though. It makes things feel really fluid and, well, editable. I like that. If I were to continue iterating I would add a 'staging' environment where your functions are by default live. Any edits would be immediately reflected in staging. Then there would be a deploy button to push everything in staging to prod.
This is not the same as developing locally and git pushing to prod! One could imagine more features where scrubbed prod data gets pulled into staging (Ã la snaplet.dev) or prod events get automatically forwarded to staging.
Anyways — this is an interesting space and I hope this serves as inspiration for future exploration! Maybe even for me?
Thanks for reading and happy Sunday!
Charles
P.S. I want to talk to you! @charlesetc or [email protected] 🙂