I built Signet.js because I wanted a reactive layer for high-performance edge applications that felt more like a browser standard than a "framework."
## The Architectural Context:
I’ve spent years working on high-performance websites and legacy CMS modernizations. I found that existing reactive frameworks often introduce excessive memory overhead or rigid DSLs that don't play well with bespoke, performant, or legacy-injected code. I wanted to see if I could build a "toolbox" instead of a "black box" that stays small.
## Design Philosophy & Trade-offs:
- Why `Proxy`? I initially explored `Object.defineProperty` to minimize bundle size, but I eventually pivoted to `Proxy`. While it adds a tiny bit of runtime trap cost, the engine-level optimizations in modern browsers make the performance impact negligible for UI cycles. More importantly, it allowed for clean, dynamic object handling without the "magic" workarounds required by descriptor-based reactivity.
- Standards-First: I’m building Signet to be a thin orchestration layer. It currently leverages `@preact/signals-core` for its robustness, but the architecture is designed as a drop-in reactive layer. My roadmap is to align the internal primitive with the upcoming [TC39 Signals Proposal](https://github.com/tc39/proposal-signals), treating Signet as a bridge to native browser reactivity as it matures.
## Why did I build Signet instead of using [Alpine / petite-vue]?
The `petite-vue` Gap: Petite-vue was the gold standard for "sprinkling" interactivity, but with it no longer being maintained, there's a real need for a modern alternative that bridges the gap between pure HTML and heavy SPA frameworks.
Solving "DOM Pollution": A common friction point I found when moving to Alpine was the "messy DOM"—state-heavy applications often left behind excessive attributes and listeners that made the DOM feel cluttered. Signet is architected to be "DOM-transparent," ensuring that reactive bindings don't leave a trail of debris when components unmount.
Signal-First Architecture: By building Signet directly on a Signal primitive, I’m opting for a "Reactive-first" model. This is fundamentally cleaner than the directive-heavy, "magic-attribute" approach of previous libraries, leading to more predictable data flows and easier debugging.
## Memory Stability:
I ran a 10,000-component mount/unmount stress test using WeakRef to verify garbage collection. The results confirmed stable heap usage, proving that you can achieve leak-free reactivity with Proxy if you manage the dependency graph lifecycle correctly.
## A Note on Implementation:
I approached the development of Signet as a human architect utilizing AI agents for the implementation. My role was defining the constraints (e.g., bundle size limits, dependency lifecycle logic, memory stability) and enforcing the "clean DOM" architecture, while the AI handled the boilerplate and repetitive logic. This allowed me to iterate on the internal signal graph and performance testing at a speed that would have been impossible manually. This project is a deliberate experiment in "AI-assisted architecture"—where the human provides the technical constraints and domain expertise, and the AI acts as a high-speed implementation engine. I also let the AI implementor construct the full document site at https://sntran.github.io/signet.js/.
I feel similarly. Being laid off and doing job search recently got me thinking about switching to become an electrician. I don't mind starting over and lower wage, but mortgage and family depending on me still hold me off.
Had this thought multiple times over the years. However, reality in the UK is training cost and time (~2 years with 2 days a week college + at least ~£5k cost and further 2 years gaining experience) can be quite a blocker- difficult to achieve with dependents for most. Then throw in the reality of domestic work and building up experience. Greener grass and all that
Thanks for the feedback, since it's in BETA, there are some bugs with it that I'm working on right now, feel free to check out later when I fix the issues
I do. I was not into WordPress until recently. Gutenberg has been very easy to get started versus writing a lot PHP. While there are still annoyances, I have managed to work around. Maybe my projects have not been that complicated, but I feel like the Gutenberg team is heading the right way.
The new CSS Overflow Specification 5 has scroll-marker that can replace anchor link. From my short test in Chrome 135, they seem to scroll to the right place.
When VR was starting to gain attraction, I had this idea of a virtual playing card deck. Everybody joining the game could move the phone around to see the virtual cards either on their hand or on the surface chosen as the "table". The idea came from the need to play cards in the hall of college department without showing that we were playing cards.Unfortunately, my college education did not equip me enough skills to make that happen. I'm glad that somebody else made this. Looks very nice!
## The Architectural Context:
I’ve spent years working on high-performance websites and legacy CMS modernizations. I found that existing reactive frameworks often introduce excessive memory overhead or rigid DSLs that don't play well with bespoke, performant, or legacy-injected code. I wanted to see if I could build a "toolbox" instead of a "black box" that stays small.
## Design Philosophy & Trade-offs:
- Why `Proxy`? I initially explored `Object.defineProperty` to minimize bundle size, but I eventually pivoted to `Proxy`. While it adds a tiny bit of runtime trap cost, the engine-level optimizations in modern browsers make the performance impact negligible for UI cycles. More importantly, it allowed for clean, dynamic object handling without the "magic" workarounds required by descriptor-based reactivity. - Standards-First: I’m building Signet to be a thin orchestration layer. It currently leverages `@preact/signals-core` for its robustness, but the architecture is designed as a drop-in reactive layer. My roadmap is to align the internal primitive with the upcoming [TC39 Signals Proposal](https://github.com/tc39/proposal-signals), treating Signet as a bridge to native browser reactivity as it matures.
## Why did I build Signet instead of using [Alpine / petite-vue]?
The `petite-vue` Gap: Petite-vue was the gold standard for "sprinkling" interactivity, but with it no longer being maintained, there's a real need for a modern alternative that bridges the gap between pure HTML and heavy SPA frameworks.
Solving "DOM Pollution": A common friction point I found when moving to Alpine was the "messy DOM"—state-heavy applications often left behind excessive attributes and listeners that made the DOM feel cluttered. Signet is architected to be "DOM-transparent," ensuring that reactive bindings don't leave a trail of debris when components unmount.
Signal-First Architecture: By building Signet directly on a Signal primitive, I’m opting for a "Reactive-first" model. This is fundamentally cleaner than the directive-heavy, "magic-attribute" approach of previous libraries, leading to more predictable data flows and easier debugging.
## Memory Stability:
I ran a 10,000-component mount/unmount stress test using WeakRef to verify garbage collection. The results confirmed stable heap usage, proving that you can achieve leak-free reactivity with Proxy if you manage the dependency graph lifecycle correctly.
## A Note on Implementation:
I approached the development of Signet as a human architect utilizing AI agents for the implementation. My role was defining the constraints (e.g., bundle size limits, dependency lifecycle logic, memory stability) and enforcing the "clean DOM" architecture, while the AI handled the boilerplate and repetitive logic. This allowed me to iterate on the internal signal graph and performance testing at a speed that would have been impossible manually. This project is a deliberate experiment in "AI-assisted architecture"—where the human provides the technical constraints and domain expertise, and the AI acts as a high-speed implementation engine. I also let the AI implementor construct the full document site at https://sntran.github.io/signet.js/.