this is a thread for me to just post screenshots and update things as they happen. i'll be back-filling it as well to see it with some of the in-progress things I've been recording.

so first step here —getting Depot up and running with Svelte 5 in electrobun. it works! needed to fix images but this is just validating that the tool operates and can open an existing .dpo file. i'll likely update the depot schema itself in this process and auto-upgrade stuff that's imported, but for now it works!

also for reference, here is the same sheet opened up in old depot:

one thing on my mind as I do all this is trying to think of all the ways I did stuff in the first Depot, and trying to determine if those ways are intrinsic to how depot should operate (like nested views), or are things that were done due to how vscode worked (like file-centric operation), or are things that were more the limits of my own coding ability (like no re-arranging columns) or my own product-thinking ability (like the big chunky field buttons). we'll see what stays/goes!

one thing I'm doing is also changing the overall theme/vibe of the tool, and am thinking about making it something that is more neo-brutalist, like the below screenshot. ill very likely provide lots of theme options to match the project of vibe, but here's where im kind of thinking.

when I had set out to start doing this, I was still largely thinking of it working in a "file centric" model, given that's how the VS Code version worked. this was sort of okay, until I started to work on it and see some weird things.

first, a local file makes sense if you have a "dumb view" on top of it, but how does it work on a server (like the browser-hosted version)? does a server have to serve depot-the-editor and a file itself? between that and the standalone I was running into lots of permutations: 1) standalone + local file (normal file read) 2) standalone + network file (?) 3) server + local file (FileAccess web api) 4) server + network file (some endpoint, somewhere?)

having to start carving seperate paths for all the different cases felt weird, so I did a lot of thinking, and what I came up with was the idea of having both a "dumb" front end app, and then an actual server daemon that "serves" the data that the apps can connect to. this is doubly nice for doing a lot of in-browser testing, because I can serve the data on localhost and connect to it through both the web browser and the standalone app.

given the possible synchronous connections though, I also made the actual jump to CRDTs and Yjs. then also there was a need to implement an actual REST API on the same server for static asset serving for images. 

here's a video of two clients connected to the same source — notice the bool flags changing!

took some time to clean up the UI a bit, mainly unifying row size. also been very inspired by linear/supabase recently for UX stuff and added in linear-style row selection to clean up the little "x"/"c" buttons. now you can select rows, delete them with delete, or duplicate them with cmd+d. it all just works. oh also there is undo/redo! im using the giant cantata depot file here (~3MB), loads almost instantly and no lag in the interface for scrolling/operations/etc.

another thing that I wanted to add in was a REST client. I want other tools to be able to easily communicate with running Depot instances, so now the server that serves the images also provides a REST api so other tools can hit the endpoint to do stuff! there is still the websocket connection that the client uses, but REST is easier to understand and setup (you can just use curl!) so I've been loving it.

cool things possible here are things like dev builds being able to write data back to the db itself, either to tweak values, write in new entries/etc. whatever you want!

spent a lot of time as well leaning on some supabase inspiration here and implemented row sorting. this works at both the high level sheet level, but also allows you to sort independently on nested lists. these nested sorts also persist across any visible versions of that list, which is nice for comparing comsistent sorted values!