I'm working on a boring e-commerce site from scratch, with the boring stack of Phoenix Live View, PostgreSQL, HTML and CSS. You know, the boring stuffs.
I just don't use AI building it. It actually brings me joy amidst all these AI news and updates.
I think it will click once you actually sit down with the AI agent, toggle Plan mode, and just tell it what you want to do in couple of sentences. It will immediately start building up the plan, presenting it to you what it thinks is the right approach , with the steps to take, with open questions that you can look at and answers. Then send them back to the AI. Repeat. That process along would give you a progress way further than you try to do it by yourself.
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.
I came across this repo while trying to find alternative to NimbleCSV, the go-to CSV parser for Elixir. NimbleCSV took 230s to parse a 250MB file with 35000 rows and 2000+ columns. RustyCSV took 1.7s.
It would be nice if there is an extension for VSCode or its forks that let you monitor your agent *running inside* your local machine, or VSCode adds support for it. I want to run agents on the codes I have open, not pushing them to a cloud "box" to run agents on there. But I do like being able to monitor or pick up the next steps from my phone.
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 have just moved from a free environment in which I was able to use any AI harnesses or models to a strict enterprise environment.
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.
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.
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.
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.
I just don't use AI building it. It actually brings me joy amidst all these AI news and updates.