HackerTrans
TopNewTrendsCommentsPastAskShowJobs

teamchong

no profile record

Submissions

Show HN: TweetDeck-style HN reader, built to experiment with Chrome's Prompt API

hndeck.teamchong.net
2 points·by teamchong·2개월 전·0 comments

Show HN: Prompt-to-Excalidraw demo with Gemma 4 E2B in the browser (3.1GB)

teamchong.github.io
163 points·by teamchong·3개월 전·62 comments

Show HN: TurboQuant-WASM – Google's vector quantization in the browser

github.com
165 points·by teamchong·3개월 전·7 comments

Show HN: VectorJSON – O(n) streaming parser to handle LLM JSON outputs

github.com
1 points·by teamchong·5개월 전·1 comments

comments

teamchong
·지난달·discuss
built this to stop fable blowing up my usage limit https://github.com/teamchong/pxpipe
teamchong
·2개월 전·discuss
[flagged]
teamchong
·3개월 전·discuss
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
·3개월 전·discuss
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
·3개월 전·discuss
I made some adjustment, can you try again? Is it faster now?

https://teamchong.github.io/turboquant-wasm/search.html
teamchong
·3개월 전·discuss
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
·5개월 전·discuss
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.