Not related to the original post, but I have been visiting your site for 15+ years now, and it's one of my favorite online art sites. Really grateful for your many years of beautiful work.
Wow, I forgot about this place, but 15 years ago it was my favorite source of wallpapers. The art is as beautiful as ever.
So are some of the accompanying texts:
> This picture is dedicated to Kiev (Kyiv), a capital of Ukraine. It is loosely based on a 13-th century map - this is what center of Kyiv looked like ~900 years ago! The original map also included the city wall - however, I decided not to wrap the buildings into the wall, since in my dream world, a city would not need walls.
I must mention https://ampcode.com/manual which is my favorite toy of them all right now. Has almost no settings; uses Claude 4, no way to change model; just works! (Unfortunately, not a paid comment.)
Yes, something like that. As probably many of you, I spent way too much time switching between agentic apps, switching between models inside these apps, and tweaking system prompts for these models.
When Ampcode took it all away from me, I found I enjoyed the actual AI-assisted coding much more than configuring. Of course, largely because it just worked. Granted, I had enough experience with other AI tools to manage my expectations.
The vibes are on point... I guess looking like Perplexity, right?
But for the way I'm using Cursor, I guess the flow is harder? I want to make smallish edits (review code, improve function)
A small thing, but I appreciate their free trial usage "starter pack" - the landscape of SWE assistance tools is pretty large these days, and it's impossible to assess fit for the use cases you're interested in without trials. As much as all the positive feedback and/or hype about Anthropic's product is tempting, for hobbyist use I can't quite justify shelling $20 out of the box. (That's to say I can't bill it to someone paying me...)
I saw this posted recently without anyone noticing and wanted to give this tool another shot: I've been using it for about a week, and it's worth your attention not less than Cline, Roo Code and many more.
I wonder why there are so many, just people reinventing stuff that no one really needs?
For me personally I have 4 of those as visited, pouchdb, automerge, loro and sqlsync of course. I was trying to fit such a tool into existing architectures that I deal with at work but nothing really makes sense.
My guess is those solutions are in totally wrong abstraction layer, creators think that would be best thing since sliced bread - but in reality having rest API and some persistence on client is like 99% good enough. With service workers in browser and mobile apps no problem of just having data stores.
Sending out specific partial updates, just reloading full state from the server is just easy to explain to the users and easy to implement. Last write wins with some auditing log is also good for something like 99.9% of applications and is super easy to explain to people - what's not easy to explain and not easy to implement is merging conflicts on database data. It is not easy to make audit logs server side so they are not tampered with if you just sync full database instead of doing REST requests.
This approach with "sync databases" feels for me exactly like someone proposing use of LateX because it is great to people who need to write 10 page essays.
It's about the multiplayer application case, think Google Write/Sheets/etc. Applications with data that can change by multiple users and you can both see it live and the application (that keeps state in memory/localdb) is also resilient to disconnects.
The reason people descend into this madness is because visible replication code is tricky and the general feeling is that it'll infect parts that shouldn't be infected (or at least not without a general framework).
So at a somewhat trivial level you have:
A: A bare log replication system (where the application needs awareness for most object types multiplying object complexity).
B: A object replication system where the framework handles all object types coherently and the application "only" needs to be aware of how to fetch objects, think a KV store that stores fairly basic objects with some addressing support.
C: Since recent crowd "wisdom" dictates that most KV stores will likely re-implement SQL functionality badly, people go straight to doing the SQL case (maybe they've had a curiosity about SQL databases already that they're scratching)
I've recently built A (basic replication and LWW) and building the application I'm definitively feeling an itch to just start over or adjust to support B (a simple replicated KV store) to separate the concerns more, I can see how I would also feel the SQL itch of C (but having done SQL like systems before it's not as bad for me).
For this first application A will suffice (since the offline needs are relatively trivial) but having a more complicated application in mind I'm strongly considering B for that project (along with designs or third party libs to make it happen).
I think a big gap in the space is that most seem focused on "documents" (esp the CRDT based tools), ie a document being the atomic piece that is synchronized but imo it leaves a big gap in that now all regular application management tools like SQL query tools are useless since essentially you only have a bunch of "blobs" or worse. If you want the regular enterprise SQL backend these tools don't seem to have a focus on synchronizing to those regular backend storage systems.
This gap is filled by the likes of Couchbase where a single org controls the majority of the stack (spoiler/disclaimer alert: I've been working on Couchbase's Sync for 8 years)
You get local the document-level atomicity for sync. Multi-document transaction support on server side, KV access, SQL inside JSON docs or even across multiple documents, Full Text Search, and fine-grained/RBAC for document-level synchronization - but the cost is as much lock-in as it is financial. You can't mix and match storage, query or sync without pretty big tradeoffs.
Not really, the fundamental problem shared for all the tools mentioned by GP is the same of concurrent edits. We as an industry typically ignore it in regular CRUD settings due to low conflicting operation frequency, but it gets problematic in offline and multiplayer settings since those cause it to become more common/visible.
As for documents vs DB, technically you can often compose documents into a number of tables. And having it decomposed into a regular DB simplifies a lot of visibility tasks since you don't need to built an extra layer to manage that and/or you might want to implement partial permissions into something that feels "document like" but really pertains to a larger system.
