Compose update: Sept 2021

Sept 2021 · All Compose Updates

Hello friends,

We've had a productive month, creating prototypes, getting feedback, and iterating. TL;DR - Compose is working really nicely as a React hook, so we're continuing to build in that direction.

Prototypes

Prototype 1: Figma mockup of Haskell IDE

Feedback 1: Haskell syntax is confusing

Prototype 2: Toy implementation in Typescript & Turbine

Feedback 2: Turbine is confusing

Prototype 3: Toy implementation in React (photo below)

Feedback 3: Makes sense but how does it...?

Compose, the React Hook & Backend-as-a-Service

That's some real progress: from an obscure programming language & new IDE to the world's most popular programming language & framework that can be used with any IDE! It's so obvious in retrospect that it begs the question: why we didn't simply start with a React hook?

Well, we did consider it many months ago (credit to Dave Fontenot for initially suggesting it), but rejected it because we couldn't see how to do it in a way that respected our distributed FRP semantics. And it seemed like Firebase (& its increasing number of friends) successfully serve that niche. However, after building the first couple of toy prototypes, we finally saw how the essence of Compose could fit snugly into React in a way that is differentiated from those other offerings. (Thanks to Aidan Cunniffe and Chet Corcos for pushing me in this direction.)

Beyond that super simple chat app, Steve also rebuilt the Rails demo blog app in Compose/React. In both cases 90% of the code is regular old React, and the remaining 10% is Compose. And the Compose code doesn't feel so magical, because it looks a lot like the useReducer hook. The Compose version is just useRealtimeReducer.

But does it...?

People seem intrigued with these demos but are distracted by a number of practical questions:

We do have reasonable (albeit handy-wavy) answers to all of these questions (1, 2), but nobody will care enough about these details if we don't make the value proposition clear enough — which it currently isn't as demonstrated by these questions.

Value propositions

We're inspired by HN's response to Alexander Obenaur's "Build apps in minutes, not months" post, which is very similar in spirit. He does a much better job of articulating the point and promise of a full-stack state-management solution built into React. I'll work on doing a better job of communicating Compose's value propositions in our next video:

1. Developer experience

Lighting-fast iteration cycles 100% within your existing IDE
Ergonomic abstractions that fit better into React than SQL or NoSQL
Try it out incrementally, because it works in parallel with your existing stack
Incredibly lightweight "database forks" and migrations that fit into your git-branching workflow

2. Full-stack components

Just like React combined HTML, CSS & JS to make the cohesive React Component, Compose will add real-time persistence to make a full-stack Compose Component. This will allow you to:

Import whole features into your app that span the whole stack (not just libraries for only the front-end or back-end).
- If you search for "spreadsheet react component" or "calendar vue component" you'll get dozens of results. However, the same is not true for full-stack components, because there is currently no library that encapsulate back-end state into the component. Enter Compose.
- In other words, Intercom, Discourse, Auth0, and many other SaaS companies could be replaced by open-source libraries on top of Compose — just like open-source databases currently work: you get really high-quality software for free from the open-source community, and you just pay for hosting (which would be 100x cheaper than those SaaS companies charge).
- Our thesis is that Firebase failed to kick-start an ecosystem of Firebase components because they didn't integrate their model deeply enough into the (React) component. There is just this one (amazing!) fullstack Firebase component (that we know of) that they built in-house.
Every Compose component is live-embedable anywhere on the web

3. End-programmer programming

End-users that are also programmers will be able to live-edit Compose apps that others have built, bringing their live data with them. The data is in the component, so simply plop the component where you want it, and edit it how you see fit. The data flows through, no matter where the component lives: in the original app or in a totally different one.

The eventual dream is end-user programming, but unlike no-code startups, we're tackling end-users last because we're sacrificing learnability in favor of the right semantics. We're very optimistic that our semantics will lend themselves well to being scaffolded for end-users. (We're skeptical that no-code will ever be able to cross the chasm in the other direction.)

Next couple months

While Steve continues to push down the React hook direction, Adriaan is continuing to expand the frontiers by prototyping in Haskell. We've found that this is a good balance for creating the right abstractions, and then bringing them to tools people are familiar with. In particular, we are looking to prototype user authentication and access control in the context of a real world application.

If we stick to this overall React-hook architecture (which is a big "if"), we might have something in the hands of close friends in a couple weeks, something usable by strangers at a hackathon by the end of the year, and a public launch ~March of next year. Lots of "if"s in there, but it's still way better than the last update, where we were targeting the end of 2022 as the best case scenario!

Thanks

Thanks so much to everyone who read last month's post and replied with good advice and introductions. A special shout-out to Nick Arner and Varadh Jain for introducing me to so many relevant investors! We're still probably a couple months away from feeling ready to fundraise because we want to settle on a plan first, but I'm glad to have started the conversation with some folks.

Best,

Steve & Adriaan