grabshot_dev

This is a great observation. I've noticed the same pattern with AI-generated code and deployment configs. Ask it to set up a Node.js service and it will happily write a new PM2 ecosystem file every time rather than noticing you already have one with shared configuration.

The "make the change easy first" mindset requires understanding what already exists, which is fundamentally a compression/abstraction task. Current models are biased toward generation over refactoring because generating new code has a clearer reward signal than improving existing structure. Until that changes, the human still needs to be the one saying "stop, let's restructure this first."

If you go the image-rendering route for e-paper, Sharp (the Node.js libvips binding) is surprisingly good for this. You can do grayscale conversion, resize to the exact panel resolution, and apply Floyd-Steinberg dithering all in one pipeline with minimal memory overhead.

The trick with e-ink displays is that naive grayscale conversion looks terrible because you lose all mid-tone detail. Dithering the image down to 2-4 levels before sending it to the display makes a huge difference in readability, especially for things like weather icons and charts. ImageMagick can do it too but Sharp is about 4-5x faster for batch processing since it avoids spawning subprocesses.

One thing worth noting: beyond raw parse speed, oxc's AST is designed to be allocation-friendly with arena allocation. SWC uses a more traditional approach. In practice this means oxc scales better when you're doing multiple passes (lint + transform + codegen) on the same file because you avoid a ton of intermediate allocations.

We switched a CI pipeline from babel to SWC last year and got roughly 8x improvement. Tried oxc's transformer more recently on the same codebase and it shaved off another 30-40% on top of SWC. The wins compound when you have thousands of files and the GC pressure from all those AST nodes starts to matter.

Why don't you make Claude give feedback and iterate by itself?

Neat idea. API discovery is a real pain point -- I find myself constantly Googling for specific API capabilities when building integrations. How are you handling versioning? APIs change their endpoints and capabilities over time, so the semantic index could drift from reality pretty quickly.

Hi HN,

I built GrabShot (https://grabshot.dev). The feature I'm most excited about: live OG images with zero backend code.

You add one meta tag to your HTML:

  <meta property="og:image" content="https://grabshot.dev/v1/screenshot?url=https://yoursite.com&og=ogk_yourkey&width=1200&height=630">

That's it. When Twitter, LinkedIn, or Slack crawls your page, GrabShot screenshots your live site and serves it as the preview image. Your OG image updates automatically whenever your site changes. No build step, no server code, no cron job.

The ogk_ key is derived from your API key via HMAC-SHA256. It's safe to put in public HTML because it can only be used for OG generation, not general API access.

You can also add device frames (iPhone, MacBook mockups) or AI cleanup that removes cookie banners and popups before the screenshot is taken.

How it works under the hood: Node.js + Puppeteer + Sharp for image processing, Gemini 2.0 Flash for AI cleanup. Results are cached and served from a single VPS.

Free tier: 25 screenshots/month, no credit card. OG parameter is on Pro/Business plans ($29/$79).

Try it without signing up: https://grabshot.dev/try.html Docs: https://grabshot.dev/docs

Would love feedback on the approach.

The field-sizing: content one for textareas is the kind of thing that makes you wonder how we tolerated the JS workaround for so long. I've shipped that "measure scrollHeight, set height, reset" hack in probably a dozen projects. Same with scroll-state queries replacing IntersectionObserver for sticky headers.

What's nice about this collection is it's organized by the problem, not the property. Makes it easy to find the thing you're actually trying to solve rather than browsing a spec.

Would love to see one for the new anchor positioning API. That one could replace a lot of tooltip and popover JS.

Great writeup. I went through a very similar journey. Signal as the "good enough" default, then gradually wanting to own the whole stack. The bit about smacks and cloud_notify being essential for mobile is spot on, that was the part I always underestimated in past XMPP attempts. Without those two modules the experience is terrible on phones and it's no wonder people bounced off it.

One thing I'd add: if you're already running Caddy as your reverse proxy, you can use its on_demand TLS to handle certificates for the upload and conference subdomains automatically instead of managing them through certbot separately. Saves a moving part.

Curious how federation has been in practice. Are you actually messaging people on other servers, or is it mostly just you and contacts you've created accounts for?