Do you see Ladybird beating the incumbent browsers in any dimension .e.g. performance, usability?, security, etc?
Personally, I much prefer developing for the web than native so if there were APIs exclusive to Ladybird it might create a nice virtuous cycle of developers targeting Ladybird to do new things and users using Ladybird to try those new experiences.
on self-hosting: We're cleaning up the docs on self-hosting to make the configuration clearer, thanks for point that out.
on querying: Yeah we don't have aggregations yet but it's on our roadmap. Don't want to over promise but I think we can make something awesome here by leverage our incremental querying engine. Like consider a data dashboard that needs to be updated every hour; in a traditional system (postgres, mongo, etc) you would need to rerun the query from scratch each time. Our plan is to create something closer to what Materialize does and just process the new data so it's much more efficient and can just update continuously rather than every hour.
re Evolu: I haven't actually gotten a change to try it out but there might be in someone in our Discord[1] that has that could compare/contrast
This is a great question! The short answer is by maintaining backwards compatibility in your schema--it's basically the easiest way to guarantee compatibility. We have warnings in place to let you know when you've made a change that isn't backwards compatible, you can read about it in our docs: https://www.triplit.dev/docs/schemas/updating#pushing-the-sc...
However, overtime this can naturally lead to a mess of a schema definition that has a lot of confusing names. We haven't released a solution to fix this yet but we're working on a few things that should make this less painful. For background on the various approaches, the Cambria doc is an amazing resource: https://www.inkandswitch.com/cambria/
Lenses make total sense. You don't have to maintain lenses for all past versions, just a rolling set with old ones scheduled for deprecation announcements and a sunset schedule.
It's not currently possible to use MongoDB with Triplit, you would use Triplit's server instead but it's very easy to setup with React: https://www.triplit.dev/docs/quick-start
Yeah it's totally usable as is but we're nearly finished with a new system that has more granular controls like delete, preUpdate, postUpdate, insert, and read. We'll still support the existing rules for backwards compatibility.
Yes but the 'backend' (the client, but the non-presentational bit) is Rust; it'd be there you'd want to do this sort of synchronisation or anything to do with state/database. You could absolutely shoe-horn it in, it just wouldn't be the way you'd expect it to work or feel particularly right/supported.
React Query (and other query caching libraries) are great until you have overlapping data between your queries. E.g. you edit a message in one place but other queries that show that same message (like a preview in your chat list) don't update.
Having a complete query engine on the client makes this a lot easier to deal with. It's why most popular messaging apps will use SQLite on the client to render the UI and build their own sync engine to keep it up to date with the backend.
There are adapters for LevelDB, LMDB, and File storage. We just use SQLite out of the box because it's fast and reliable. We'll make those other adapters more accessible in the future.
Personally, I much prefer developing for the web than native so if there were APIs exclusive to Ladybird it might create a nice virtuous cycle of developers targeting Ladybird to do new things and users using Ladybird to try those new experiences.