Future of BaconJS in plugins

[rhbvkleef]

BaconJS version 1.0.1 is currently used, which is the last version of the version one series. It is 7 years old by now and will probably never be updated again. Eventually, we'll have to update it, and before we do, some thought needs to go into how to do this.

Most importantly, plugins expect v1.0, so updating to v3.0 requires either updating all plugins, providing a shim, or announcing to all plugin authors that they need to update their plugin to work with future versions of BaconJS.

https://github.com/baconjs/bacon.js/wiki/Migration-from-version-1.0-to-2.0 has some recommendations.

At the bottom of the page, there's a recommendation to make packages compatible with both BaconJS version 1.0 and version 2.0. Pushing plugin authors to do so might be a viable strategy to go to 2.0. I think the same strategy will work for 3.0. We might therefore opt to skip 2.0.

[tkurki]

Sigh. This is a pain. As the use is spread over a zillion plugins no easy way to update.

The plan (at the back of my head, not communicated) has been to recreate similar APIs with a reactive framework that (a) probably has a future (b) is more future proof technically. So far I've been looking at https://rxjs.dev/ and used it in a few places. This would allow a transition period with hopefully decommissioning BaconJS in some distant future.

[tkurki]

Retitled.

[tkurki]

There is some standardisation work related to Observables that is close to RxJs.