Echo JS 0.11.0

Beacon is backend-focused state primitives—metrics, config, service state. Not trying to replace Redux/Apollo.
You're right that transport/sync is the missing piece. That's on the roadmap as Beacon-Transport, but nothing publishable yet.

The plan: WebSockets with value diffing (not action/patch history). Last-write-wins. The advantage: recovering state is a single read instead of replaying patches—faster failure recovery.


Current ecosystem status:

Beacon (1000.2.3): Core reactivity—complete for my backend needs
Beacon-Durable (next release): SQLite-backed persistence, resumability
Beacon-Rules (following): FSM foundation
Beacon-Transport (future): Client sync over WebSockets

Thanks! Will update that with the next version v1001.0.0

I applied the concept of Epoch SemVer https://antfu.me/posts/epoch-semver

Without actually using it, I can't have an informed opinion about it.

I disagree with SemVer that security fixes are just patch bumps. Some security updates require a breaking change, requiring the major version to bump. Epoch SemVer supports that.

Bumping the version 1000.2.3 → 1001.0.0 could signal a security fix with behavior changes in backwards-incompatible way.

You are referring to https://github.com/tc39/proposal-signals.
The proposal is currently in Stage 1 - Exploration. It'll take some time until we have native Signals in JavaScript.

I stated some differences here:
https://github.com/nerdalytics/beacon?tab=readme-ov-file#key-differences-vs-tc39-proposal

Beacon, may or may not use TC39 Signals as a foundation.
Beacon, may or may not become obsolete with the TC39 Signals becoming GA.

Give Beacon a try, then feed back your experience to TC39.
I think my design easier to get into Signals.
~Thanks

Bare uses a pluggable library approach over a fat-embedded-standard-library. Example, `bare-fs` needs to installed and imported in order to access the file system.

I had a run with Rare last weekend. It delivers on it's promises–so far. I'm not sure yet, if the pluggable library approach will benefit or hurt. Some people might look to often for alternatives to `bare-**` libraries, instead of writing code.

I'll try it on a Raspi where Node.js still crashes with Out of Memory exception unless tweaking memory parameters.

I also skipped dealing with ESLint in favor of Biome.

The experience is quite nice. Rules have few options, which reduces the time needed to adjust parameters.

With Biome 2.0 (currently in Beta), Biome introduces plugin support. Unlike ESLint, where plugins may repeatedly parse code to an Abstract Syntax Tree (AST) due to the flexibility in tool choice, Biome Plugins will be written in GritQL. This approach leaves the AST unmodified and allows efficient querying, potentially avoiding the inefficiencies caused by repeated parsing. While GritQL may not cover all ESLint plugin functionalities initially, it is designed to handle most use cases effectively.

I use Zed+Biome.js, and I'm happy with Biome.

One caveat: Biome requires a GitHub Action when using in a workflow. At least in my set up, npm seems to be not able to run Biome after installing dependencies. Fortunately, the Biome team hosts an official Github Action.

While working on a backend project, I needed a better way to manage and update statistical data across different components. Inspired by React's useState and useEffect, and frameworks like Preact, Angular, and SolidJS, I dove into the world of Signals.

💡 Instead of adapting existing frontend solutions, I created a Node.js library 'Beacon' that brings the power of Signals to backend development. This library efficiently tracks dependencies, preventing infinite loops and stack overflows, even with complex cyclic dependencies.

🌟 If you're looking to streamline your backend data management, give my library a try! It's potentially makes your development process smoother and more efficient too.