It's getting real now that everyone can prompt to build things now and call themselves coders. I was even offered help from them.
165 karma · joined April 20, 2013
It's getting real now that everyone can prompt to build things now and call themselves coders. I was even offered help from them.
No Konami code :(
Now, we talk about whether such discovery was written by LLM.
Does it really matter?
I just don't use AI building it. It actually brings me joy amidst all these AI news and updates.
You can tell it to start implementing step 1. And you pick it up from there. Very natural how you would approach an expert for help, but you can always audit.
Last time I tried to let AI build such extension, it told me that VSCode did not expose extension API to monitor AI chat.
I was shocked to realize how difficult it has been to have a GitHub CoPilot license on Azure. I mean, they're both Microsoft products. But no, the IT now has to figure out how to set up a GitHub enterprise, link to Azure subscription, and all that.
But if you have to use `display: flex" in a lot of places, having the `flex` utility is better. And there are tons of such utilities with Tailwind.
I love Elixir but I had been a JS developer by trade. Bridging that interface keeps my brain focusing on building instead of splitting between JS and Elixir.
Still a lot to do, but I love the progress so far. This puts the joy of building something back to me.
## 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/.
For your example, you can just match in `[id^="insert"]` and add the actual firstName value in the handler.
I use it alot on the server side, but it's for JavaScript side, or Rust if you use the lower level lol-html.
Of course, clothes can be hung outside for the warmth of the sun, but this seems way cooler.