I have ran into very specific scenarios where JavaScript's design has unnecessarily complicated my project's code structure and logic. Are there any alternate implementations of JS web requests that don't work through asynchronous functions?
This one took a while, it's probably the longest thing I've written on this blog. I wanted to do a proper end-to-end walkthrough of cmd/compile: real package names, real data structures, diagrams for the AST and SSA CFG, and the flags you actually need (-m, -m=2, GOSSAFUNC, -S) to observe each phase yourself rather than just take my word for it.
Covers the full pipeline: lexer → parser → type checker → IR lowering → SSA construction → optimization passes (inlining, escape analysis, BCE, nil check elimination, register allocation) → architecture-specific code emission.
Hope it's useful — happy to answer questions or push back on anything that looks wrong.
Jag skapade ett npm-paket
Jag gjorde ett paket som heter FactCheck, det är ett YouTube-bot paket som använder AI och webbsökning för att faktakolla kommentarer på YouTube.
Jag gjorde det eftersom det finns ganska mycket falska nyheter i kommentarer på YouTube.
Är det någon som vill prova paketet och ge feedback?
I’m maintaining a small npm package and I’m trying to understand how meaningful npm download numbers actually are for an early-stage package.
After publishing a new version, I consistently see a noticeable spike in downloads shortly after the release, followed by a smaller number of downloads each day. The pattern seems to repeat with subsequent releases.
I’m especially interested in how people establish credibility around early npm download numbers without overinterpreting them.
Would love to hear how other package maintainers approach this.
I kept hitting the same annoying loop while building features: change some code, manually click through the flow to check it still works, repeat. No test exists yet because the
feature isn't done — so I just... kept doing it by hand.
So I built five46 — you give it a plain-English goal like "log in and confirm the dashboard loads", point it at your local app, and it uses your own LLM key
(OpenAI/Anthropic/Gemini/Groq/Bedrock) to actually drive a real Chromium browser (or hit real HTTP endpoints for APIs), one action at a time, and tells you honestly whether it worked
— with a root-cause guess if it didn't.
The part I'm most happy with: once a run succeeds, it writes out a real, standalone .spec.ts (Playwright) or .test.mjs (node:test) file. That file has zero dependency on five46 or the
LLM afterward — it's just a normal test you commit and run in CI with npx playwright test. So the same check that helped you while you were building the feature becomes your
permanent regression test, instead of a separate thing you write later.
Other bits:
- Fully local, no cloud sandbox — the only thing that leaves your machine is the text sent to your LLM provider per step (always shown, never hidden)
- Session reuse so you're not paying LLM cost to log in on every run
- Self-healing selectors (one bounded retry if a selector goes stale)
- --repeat N to catch flaky steps
- MCP server so Claude Code/Cursor can call it as a tool directly
It's an early proof of concept — works, but rough edges. Genuinely want feedback on whether the "test-while-you-build becomes your regression suite" idea is useful to anyone else, or
if I'm solving a problem only I have.
GitHub: https://github.com/sekharsdet/five46
npm: npm install -g five46