HNHacker News
TopNewBestAskShowJobs

teamchong

140 karma · joined April 9, 2023

submissionscomments
teamchong··on Tell HN: Anthropic's Fable model is too expensive
built this to stop fable blowing up my usage limit https://github.com/teamchong/pxpipe
teamchong··on Show HN: Prompt-to-Excalidraw demo with Gemma 4 E2B in the browser (3.1GB)
sorry it’s not working for you. I built this as a personal project for self-learning, but I plan to take a look at this issue next weekend. you can check out a video demo of it here: https://github.com/user-attachments/assets/71ae6e5c-a5ec-4d0...
teamchong··on Show HN: Prompt-to-Excalidraw demo with Gemma 4 E2B in the browser (3.1GB)
firefox has webgpu already, but the subgroups extension isn't in yet. every matmul / softmax kernel here leans on subgroupShuffleXor for reductions, that's the blocker. same reason mlc webllm and friends don't run on firefox either. once mozilla ships it this should work
teamchong··on Show HN: TurboQuant-WASM – Google's vector quantization in the browser
I made some adjustment, can you try again? Is it faster now?

https://teamchong.github.io/turboquant-wasm/search.html

teamchong··on Show HN: TurboQuant-WASM – Google's vector quantization in the browser
you’re right that 32f is faster on raw query time, quantization adds extra step. main benefit on download size since gzip won’t help much, which matters most in browser contexts
teamchong··on Show HN: VectorJSON – O(n) streaming parser to handle LLM JSON outputs
I built this after hitting GC stalls parsing streaming tool calls in my AI agent. LLM outputs are getting large — code edits, file writes, 50-200KB JSON payloads.

Every AI SDK I looked at (Vercel, Anthropic, TanStack, OpenClaw) does `buffer += chunk; JSON.parse(buffer)` on every token. That's O(n²) — a 100KB tool call arrives in ~8000 chunks, and each chunk re-parses the entire accumulated buffer from scratch. The cumulative parse time adds up to 13.4 seconds for the Anthropic SDK. Each intermediate buffer string and parsed object becomes garbage immediately, thousands of short-lived allocations that put constant pressure on the GC.

VectorJSON scans only the new bytes on each chunk. O(n) total — same payload, 6.6ms. Parsing happens in WASM linear memory, so no JS objects are created until you access a field.

Built on zimdjson (Zig port of simdjson by @travisstaloch) compiled to WASM. Fields materialize lazily through a Proxy — if you only read 3 fields from a 100KB payload, the other 97% never touches the JS heap. Deep comparison runs entirely in WASM memory — 2-4× faster than recursive JS deepEqual with 24× less heap pressure.

Not a replacement for JSON.parse — for single-shot full materialization, JSON.parse is faster (it's optimized C++ in V8). VectorJSON is built for streaming, partial access, and deep comparison.