This is a prototype demo for Compose (new-ish startup): Would love to hear points of confusion, excitement, and other feedback ☺️

I think the whole video was very clear. Would just have been nice to understand how the backend magic part actually works, but maybe stuff for another video.

Thanks! Appreciate the feedback

Interesting work @stevekrouse! Since I am working on https://wasp-lang.dev/ and you mentioned you are trying to unify/squash the stack (elegant unified semantic layer - yumm), it got me pretty excited! Below is my feedback on the video. For the context, these days my go-to for web dev is React + Node, while I do most of my system-level programming in Haskell. • Love the tone of voice, explanations and speed/tempo, video was comfortable and easy to follow. • I was speeding through the video and I missed the point where you said that "./firebase" is part of your Compose project, so I had to go again through the video to catch that part, where you say that you implemented "./firebase" with Compose. If there was a comment next to the

import { realtime } from "./firebase"

saying

// I implemented this using my project, Compose

that would help a lot. • I found the first part of the video pretty long, before we got to the firebase/compose part. The whole video is pretty long (18 min!), I barely convinced myself to watch it (with a lot of speeding up). The buildup makes sense so I understand why it is so long, but if it would be possible to make that part shorter I would go for it. Maybe you could decide that video is aimed for people who already know turbine and then you can skip that intro. Or, maybe you could use React instead of turbine (could you though, or Compose makes sense only with Turbine?) and then aim it for people who know React and again, you can skip the whole part where we are building a component. • So first I thought you used Compose to convert the firebase interface into a functional interface, but then I understood, when I watched that part again, that you actually built Composed on top of Firebase and firebase is really just an implementation detail that is not important? That was a bit confusing. I guess it could have been

import { realtime } from "./compose"

? So

realtime

is the function you implemented and is an interface of Compose? • I get the idea of component containing the information about how it stores/pulls the data that is globally available and persistent, and that sounds pretty cool! Some questions that immediately emerge are though: what about the access control and secrets (like API keys), which is normally done on the server since it is under our control, while client code can be modified by anybody? What about collaboration between the components and sharing the data? I am guessing you will answer those in the future, just wanted to share what pops into the mind. • I never saw Turbine before, and while it seems cool (I love functional, I use Haskell), it felt a bit complex compared to the React, probably because I know React, but maybe also because it is complex in its essence? Not sure, but if it was React, I believe I could focus more of my energy on the Compose itself. But again, I am not sure if you can make Compose work with React or not. • At the end, it was left wondering what a Compose really is -> is it a kind of database that has nice TS SDK that is functional? Or is it something else? I hope this feedback helps and excited to see the future progress!

Really amazing constructive feedback! 🏆 Thank you - I can definitely fix a lot of those in the next video. As far as using React.... I can probably do it but to be honest it is just not functional enough so i resist it. However you are 100% correct that attention spans are short so it could be a huge help... I will probably give it a go

Glad it helps! I assumed that is so (Rust vs Turbine), but my main thought is that it is easier to introduce one concept (Compose) then introducing two of them (Turbine + Compose), which why I said that if you go with Turbine you should probably aim for Turbine users, but if you want to go more general, it would probably make sense to go for React. So maybe at this stage it is ok to stick with Turbine if you are not yet looking for wider adoption, but later it might make sense to go with React. Good luck!

Unfortunately Turbine, and all other "pure" FRP frameworks have zero adoption. Your React advice is thus doubly valid. Thanks!

Great demo. I would probably pull the motivation section where you google for spreadsheet components to the beginning. This is the part that most succinctly explains your value. I second the comment about wanting to understand the back end. It feels so magic that it's a little bit off putting. Particularly for something like AWS where you want to be sure what your billing is going to be, and that it isn't sending excessive traffic.

Great feedback as well! Thank you Chris!

Croquet might be interesting to you @stevekrouse 😃 https://futureofcoding.slack.com/archives/C5U3SEW6A/p1632298432102400

It definitely is! I spent a week out with the team in LA last year. They're more in the OOP style