jlongster

Yeah that article is better. I'm the author and I wrote this only for me as I studied it, it's not great as a way to describe it to others

I wanted to start from the very beginning and as far as I know Lab and OKLab didn't come later. Studying the 1931 studies and such was a start, and I wanted to later bring up all the other things we've learned since then, but haven't had time to write more about it

Hey! I'm James, the original creator. Yeah, I tried to stay involved but over time I had to accept that my life right now just doesn't allow time to be very involved. We've had some incredible maintainers step up and their doing an amazing job stewarding the project along.

I'm long-overdue to check in with the maintainers and write some content about the transition. I was also intending to shutdown the hosted version late summer and hand over actualbdget.com to the open-source community. My goal is to do this by end of year.

Overall, I wish my life weren't so busy in some ways, but it's busy with really good and fulfilling things. The transition was a little rough for me (hard to give control away of something I worked so hard on) but it's turned out surprisingly good

Native apps were open-sourced yes in the repo, but the community moved them out into their own repos and archived them. Hard to build native apps open-source with all the tooling, and the community has been working on replacing them with a webapp

Hey! Glad to be an inspiration :)

What's shutting down is the public syncing server. That server is literally just a message store: it takes CRDT changes and puts them in a big table. And it servers them back out.

Now that the server is public, it's incredibly easy for you to run your own. It's such a simple server (no postgres etc requirement) that this model is actually way better.

I've thought about it! I'm a little burned out though on the business stuff. I'd like for this just to be a cool product now.

Yep that's right.

I launched around 3 years ago, and it was brutally slow. I think it took a year to hit 100 subscribers.

Another year to hit 300.

This past fall, YNAB increased their prices which gave me decent jump from around 500 to 800 subscribers which is where I'm at today.

I did everything wrong when it comes to marketing and getting subscribers. I focused on the tech and never invested in content, building hype, etc. Well, I take that back -- sometimes I did, but only 10% instead of 70% like I should have been doing.

Yes I totally regret it. There are ethical VCs that would be willing to invest a small amount and I should have done that. Bootstrapping isn't all it's cracked up to be; there are a lot better and smarter ways to kickstart a project.

If the community want to wait, I'm happy to push back the date.

I actually thought it felt less greedy to not wait too long, because doing it in the far future just means people are paying for unsupported software. Happy to keep it running though for as long as people want.

Funny too because Ian (author of the posted article) designed the Prettier logo

> Does this mean the main (UI) thread is blocked during queries? Or are there more threads, like UI <- async messages -> SQLite main <- Atomics blocking -> SQLite FS backend?

The latter! Your app running queries must be on a worker, and then the IDB backend will spawn another worker. `Atomics.wait` is not even available on the main thread.

Ideally in the future, there will be a better storage API that we don't even need all the Atomics silly-ness (hopefully it provides Sync methods)

That's really cool re: Notion! That's exactly the kind of thing I want too: a way to just build apps the same way everywhere, on mobile/desktop/web.

You are right about various issues, and I personally don't have to worry much about it on my app because I have native mobile apps and I don't support the web version on mobile. I intentionally do that -- the mobile web is just too broken in too many ways. My impression is the IDB is more stable on desktop, but because mobile is more memory sensitive there are more issues there.

However, you should try it out! I definitely discovered a lot of weird things; I definitely was able to get Safari into a weird state the required a complete app restart. Here's the thing though: I found ways around them. If you do a lot of read requests in a certain way, Safari will lock up permanently. However, if you make sure to wait until the `readonly` transaction is finished before starting a new one, the problem goes away. I was able to reliably reproduce that problem and it went away with that fix.

I think absurd-sql is so promising because it normalizes the patterns of how IDB is accessed, and it already includes fixes for a bunch of edge cases. There are probably more, but try it out! If you run into an edge case, we can tweak the IDB backend until it works. We can paper over these issues in the underlying backend and you don't have to worry about it because you aren't directly managing IDB read/writes.