Compose is dead; long live Zaplib! After just a couple weeks working with JP on Zaplib, I decided to switch over. Compose lives in a very crowded Backend-as-a-Service space, and its features were more “nice-to-have” than essential. On the other hand, the potential customers of Zaplib (a Rust Wasm library for fast web apps) were desperate to give it a try, and that there are virtually no other alternatives out there. And working with JP is a dream!
How you can help #1: If you’re interested in trying out Zaplib, please reach out. At this stage, we’re looking for companies working with ArrayBuffers, WebWorkers, or Wasm — we’d love to hear from you!
How you can help #2: We’re looking for a founding-engineer to join Zaplib — someone passionate about developer tools, library and framework design, and crafting the perfect developer experience. Rust, C++ and/or Web Assembly experience are huge pluses. Someone who worked on performance, profiling, or low-level JavaScript at their last job could also be a perfect fit. It’s just the two of us right now, so this is an opportunity to join a small, fun, fast-moving team to shape the future of application tooling. We’ll both be in SF for now, but likely remote after.
Zaplib is a Rust Web Assembly framework for incrementally speeding up web apps. Say you have an existing JS app that’s doing a lot of compute on the client. It’s slow. Maybe you try offloading the compute to the server. Maybe you try ArrayBuffers, WebWorkers, or Web Assembly. Your performance gets a little better but your life gets a lot worse, because now you’re in the wild, wild West.
Enter Zaplib. Now you can rewrite the bottlenecks from your JS client in a language designed for performance that developers love: Rust. Your code will be much simpler and more maintainable than low-level JavaScript, and (hopefully) many times faster. You write these Rust files right in your JS app, compile them with Zaplib, and simply ship a .wasm file alongside your .js bundle. Zaplib handles the JS / Wasm interop, provides a standard library (threading, HTTP, etc), and more!
The long-term dream is to provide a batteries-included application framework for cross-platform, high-performance apps. Of course not all web apps need high performance. NextJS is and will remain perfect for news sites and e-commerce. Zaplib is for apps would have been built on native before the web became the default platform for everything.
In short: highly-interactive pro tools. If you’re a professional that spends hours each day living in some software, you deserve software that is fast. Think: Figma, Notion, Roam, GSuite, Adobe tools, Autodesk software. Our early customer conversations are with folks building tools for architects, circuit designers, website builders, and data analysts. There’s even a new movement of “faster X” software: Superhuman is faster Gmail; Warp is faster Terminal.
At some point while working on Compose it hit me that I’d need to hire a CTO, and that JP would be that dream CTO. He’s a veteran startup technology leader, and everybody seems to love working with him. He has fantastic technical taste, is a great mentor and recruiter, and has an eye for architecting systems for maintainability and scale.
For the last couple months, we’ve each been trying to recruit the other to join their respective startups. We’re both so similar (Bret Victor fanboys, steeped in the startup and open-source cultures), and had a strong feeling we’d work well together. (We met at a hackathon 8 years ago and made this.) When we did a “cofounder dating checklist”, we had so much in common. I was most blown away by the fact that we both used the same words to describe the culture we want to foster: “positive, good vibes, upbeat”. In short, I found my dream cofounder.
I’m proud of what I created over the last five months at Compose. Maybe someone will stumble across the README and steal some of these features.