jlongster

Author of the article here; I wasn't able to understand how to get that to work, and I talked about that in the post. This demo is doing that: https://jlongster.com/why-chromaticity-shape#block-31f373

The problem is "for each pixel inside the area". I could have done that, and then clipped the output by that shape. The problem is this doesn't answer why the shape is this way at all because you are using the shape itself to clip the output. It felt fake.

I do think this is what is most common though. I was trying to understand a more rigorous approach, and the one where you generate spectra and try to fill it is described here: https://clarkvision.com/articles/color-cie-chromaticity-and-...

That feels like a more rigorous approach, but clipping is probably "good enough" too

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

I'm the author of the article and the intensity is referring to the level of the light source used in the study to generate the data. See the study explained here: https://medium.com/hipster-color-science/a-beginners-guide-t...

but you're right, the intensity needed of each R, G, and B light sources to produce the correct color is directly related to how our eyes perceive each of those sources, so yes you are correct

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.

Sure thing dang, thanks! Sorry!

Reads aren't as bad, but any kind of writes seem terrible. Take "10ms" with a grain of salt and view the numbers yourself here: https://priceless-keller-d097e5.netlify.app/

I was profiling on an older computer. On my newer one, summing 100 items takes ~8ms (use the raw idb mode). When I said "simple operations" I meant simple queries that you'd expect apps to write, not just 1 single read/write. It is a little faster for each read/write, but there seems to be a bottom floor. Even if reading an item itself is fast, opening a transaction is slow. So any query, even if it only reads one item, is going to suffer the perf hit of opening a transaction.

It's only twice as fast as Firefox, so overall IDB is still super slow when compared to running the same queries with native SQLite. We're talking summing 100 items taking ~.01ms or less. I have no idea why it's so slow.

People are already trying to get me to hook up https://litestream.io/ to it

Something sounds wrong with your setup. I've had no problems!

Yep, this is the biggest problem (although I haven't seen it happen after 7 days, at least on desktop).

We will provide a new backend for the Storage Foundation API when it's available.

Did you read the post? This project does exactly that. (but focuses in IndexedDB for now because it's the only cross-browser thing that works. I actually tried a webkitFileSystem backend and it was slower)

Thank you!

All that does it export the entire db and write it down whenever something changes.

I just include a list of migration files in the app, iterate through them in startup and make sure they are all applied. It's pretty simple, but yeah you have to think about this if doing local apps

Yeah, it adds to the absurdity of all of this.

Although I do empathize with browers vendors. I worked at Mozilla at the time and was aware that this is a lot of things to think about when integrating something onto the web. I get why it happened, but practically speaking maybe it should have won. It's not like Chrome seems to care much about cross-browser standards these days.

I'm hopeful for a storage layer like this though: https://web.dev/storage-foundation/

It might actually be a better outcome if we get a storage layer with close to native performance, and then you can compile and db/lib/etc and it gets to use it.

Oh right, that makes sense in the context of this thread :)

What doesn't work about them?

I use `Atomics.wait` and `Atomics.compareExchange` and maybe a couple other APIs and it works well on Safari Technology Preview (if you enable SharedArrayBuffer).

I built an app (https://actualbudget.com/) that uses a local sqlite db and syncs changes, and that's exactly how it works. It takes quite a different approach though, using CRDTs to represent changes and those are synced around. When a fresh client comes into play, it downloads the latest sqlite snapshot from a server and then syncs up.

Thank you!

Not yet! I plan to but it's not fully supported (I think Safari is the only one missing?) and you still have to handle quota exceeded errors anyway. My first step will be handle the quota errors gracefully and warn users that it's not locally saving changes.