sbinder

Because millions of Spotify-compatible speakers are sold with firmware that will never be upgraded, so they can't ever change the Spotify connect protocol without breaking those devices.

They've added it as an option recently.

I don't think the runtime is "much more advanced", the JVM has had most of these optimizations for years.

by dynamically allocating FFI trampolines, which add their own performance and lifetime issues that would be unacceptable for Rust.

(I work at PowerSync)

This is a good point, and we definitely agree that the local sqlite database should be the source of truth for all things state management. The example here is consistent with that view because the intermediate providers and notifiers are stateless, their only role is to bundle related functionality as well as exposing database queries as typed providers (making it easier to read results in widgets because no explicit StreamBuilder is necessary).

We've recently published guides on using PowerSync with popular Flutter state management approaches [1], and we mostly agree that sync engines simplify state management to the point where intermediate layers are unecessary. Some really enjoy the structure Riverpod can provide though, and that's why we want to make sure PowerSync works well with those architectures.

[1]: https://docs.powersync.com/client-sdk-references/flutter/sta...

Perhaps they're referring to this famous objection of financial institutions to TLS 1.3, motivated by them not wanting to update their MitM software needed for compliance: https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr...