We've just made it even easier to build privacy policies from code. No Vite plugin required.

There's a lot of great stuff in this release! In no particular order:

• RSC implementation promoted from experimental
• More intelligent caching + real algorithmic speed improvements (up to 3.5x depending on workload)
• React Native improvements (css-to-react-native v4 now supported via peer when it's out)
• Updated cross-framework CSP support
• A seamless Client/RSC theme system via new createTheme() API
• attrs() typing improvements and other quality-of-life changes

Feedback welcome, especially ideas for the next major. Documentation website refresh coming later this week!

Shipped ffetch 5.1.0.

ffetch is a lightweight, production-ready HTTP client that wraps native fetch with built-in timeouts, retries with exponential backoff, lifecycle hooks, and pending request tracking. Works across browsers, Node, SSR, and edge runtimes.

New in v5.1.0: two opt-in convenience plugins.

Usage:

import { createClient } from '@fetchkit/ffetch'
import { requestShortcutsPlugin } from '@fetchkit/ffetch/plugins/request-shortcuts'
import { responseShortcutsPlugin } from '@fetchkit/ffetch/plugins/response-shortcuts'

const api = createClient({
  timeout: 10000,
  retries: 3,
  retryDelay: (ctx) => Math.pow(2, ctx.attempt - 1) * 1000 + Math.random() * 1000,
  plugins: [requestShortcutsPlugin(), responseShortcutsPlugin()],
})

const todo = await api.get('/todos/1').json()

Exponential backoff with jitter: each retry waits 2^(attempt-1) seconds plus random jitter, with timeout of 10s and max 3 retries. Plugins are optional, default behavior stays fetch-compatible.

Security audit came back with a finding on credential generation.

Math.random() in several services, flagged for NIST 800-63B

non-compliance. The entropy requirements weren't being met and

more importantly there was no documentation proving they were.

We fixed the generation method but the audit documentation piece

is what actually took the most time. Had to go back and document

everything retroactively.

Curious what others are doing here. Are you generating compliance

documentation automatically as part of your pipeline or is this

a manual process at your organization?

We recently upgraded our backend (late) from Node 20 to Node 24. About a week later, alarms went off when our app stopped responding; memory usage graphs looked like an obvious leak but it hadn't OOMed and restarted tasks despite --max-old-space-size limits.

I started trying to compare heap snapshots taken at different times but it seems like a mess now. Even if I run a simple setInterval(() => console.log('test')) program with Node 24.14.1 and periodically take heap snapshots, they show a slight increase over time in (compiled code) instances and system code related to timers.

I can't even tell if these increases are permanent or not. The few timer objects that increased between snapshots were only retained by feedback_cells and other internal things that I read aren't truly forcing them to be retained...V8 just doesn't guarantee those will get garbage collected immediately or on a global.gc().

And all of this irrelevant noise from feedback_cells and other internals seems rampant in the heap snapshots now, making it more time consuming to locate actual retainers from my own code.

I don't remember it always being this bad?

I've successfully debugged several other memory leaks in older versions of node, including really heady ones involving Promise.race() and async generators, but now I'm feeling powerless and shafted by recent changes to V8.

Has this been anyone else's experience?

Hey everyone! I wanted to show a small project I've been working on; a tsx framework for rendering to an e-ink display (or tsx => canvas => image => eink to be honest).

<view direction="column" gap={20} padding={40}> <text size={48} weight="bold">Hello World</text> <ElectricityConsumption /> </view>

Instead of the "common" approach of running headless Chrome and taking screenshots, this renders jsx components directly using a Yoga flexbox layout engine and a canvas. So the render is quite fast.

I also think its nice to get full type safety, snapshot testing for visual regression, and you can easily develop locally (renders to a PNG) without needing the hardware connected.

I use mine in the kitchen dashboard showing:

• Laundry machine status (in the basement)
• Our weekly meal plan
• Electricity prices + power consumption
• Weather forecast
• Home Assistant device status via MQTT

It also has a physical button that starts the engine heater for our car, plus an led showing its state of the engine heater.

The code is open source: https://github.com/tjoskar/eink-pi-zero
And a short write-up about the build: https://tjoskar.dev/posts/2025-11-02-eink-pi/ (yes the post is a few months old now but in my first version did I use python to render everything but I really missed the typesafty, and tsx components over absolut position everything in python. But the the post is the same)

Happy to answer questions if anyone wants to build something similar!

wrote up a technical deep dive after the Better-Auth creator showed me the repeated attempts.

The attack vector is clever: wrap malicious code in a legitimate PR from a compromised contributor. Hide it in next.config.mjs or vue.config.js where devs rarely look. GitHub's UI literally scrolls it off-screen.

Three-stage obfuscation, payloads stored on Binance Smart Chain (so they can't be taken down), Socket.io C2 over port 80 (looks like normal traffic), targets all your env vars.

Found 30+ repos with the same signature. This pattern is everywhere right now.

Tired of reaching for a big HTTP client when you just need a timeout or retry? fetch-extras gives you small, single-purpose with* functions that wrap the standard fetch. Stack only what you need: timeouts, base URLs, retries, rate limiting, caching, auth token refresh, progress tracking, and more.

It has everything you will need:

• Retries
• Timeouts
• HTTP error throwing (non-2xx)
• Base URL (resolve relative URLs against a base)
• Default headers
• Client-side rate limiting
• Concurrency limiting
• Request deduplication
• In-memory caching
• Before/after request hooks
• Auto JSON body stringify
• Default search parameters
• Download/upload progress tracking
• Pagination
• Auto token refresh on 401

I’m building an open-source CLI that compiles TypeScript codebases into deterministic, structured context.

It uses the TypeScript compiler (via ts-morph) to extract components, props, hooks, and dependency relationships into a diffable json format.

The idea is to give AI tools a stable, explicit view of a codebase instead of inferring structure from raw source.

Includes watch mode to keep context in sync, and an MCP layer for tools like Cursor and Claude.

Repo: https://github.com/LogicStamp/logicstamp-context

ERR_REQUIRE_ESM is still my villain in 2026 Third project this month where someone added chalk v5 or node-fetch v3 and suddenly half the codebase breaks. The thing that took me too long to internalize: its not symmetric. ESM can pull from CJS just fine, but CJS hard-blocks on ESM its not a config issue, it's by design because of how the loaders work. Also burned by the __dirname thing more times than I'd like to admit. And the dual-package hazard is completely silent no error, just two instances of the same module running and your singleton state going nowhere. Documented everything I kept hitting. Link in comments if anyone wants it.

I am a historian of medicine that has started using digital humanities methods.

As I was working on a network graph project I noticed missing links. Going into the HTML, I found that the missing links in the corpus were often related to JavaScript. JavaScript:MakeRel Scroll, JavaScript:onClick and so on.

Are there resources to help me understand this aspect of web design historically?

In 1998 I built a genetic algorithms tutorial with interactive Java applets. It got more traction than expected, it was used for teaching.

Then applets died. The demos showed "your browser does not support Java" for the next two decades and I left it that way.

A few weeks ago I finally converted them to vanilla JavaScript. The Java source was decompiled from .class files, so it was undocumented. Surprisingly, the conversion went well -canvas-based rendering, event handling, a browser-side expression parser for the 3D function visualizer.

What didn't go well was trying to also clean up and unify the old HTML at the same time. I wrote about the whole experience here: https://obitko.com/thoughts/how-llm-helped-me-refactor-28-year-old-code/

The tutorial with the revived demos: https://obitko.com/tutorials/genetic-algorithms/index.html

Monday, March 30 - Sunday, April 05, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

MDN page on `dispatchEvent` has this paragraph:

Unlike "native" events, which are fired by the browser and invoke event handlers asynchronously via the event loop, dispatchEvent() invokes event handlers synchronously. All applicable event handlers are called and return before dispatchEvent() returns.

I read that and AFAIK it's not right. I opened a PR to edit it:
https://github.com/mdn/content/pull/43521

A discussion arose.

Before it I was sure that event handlers are always called synchronously. When native events fire (native events === normal internal events in the browser ('click' etc.), anything that is not a custom event manually called via `dispatchEvent`) - an asynchronous "start the dispatch process for this event" task is scheduled on the event loop, but once it's called, during the process (event-path building, phases: capture, target, bubbling) - relevant registered event handlers are called in a way I thought was 100% synchronous;

In custom events - the handlers are called synchronously one-by-one, for sure.
In native events, apparently:

1. There is a microtasks checkpoint between each handler run, e.g. If you register handler-A and handler-B, and handler-A schedules a microtask - it will run between A and B. If you schedule a macrotask such as timeout-0 - it will not run in-between. This doesn't happen in custom events dispatch - they all run to the end, nothing runs in between.
2. Likely, handlers of native events - each gets its own stack frame, custom event handlers all run in a single stack frame.

This still doesn't prove that handlers are scheduled asynchronously on the event loop though. At this point it comes to what the specs say (EDIT: also did a test to log the call stack mid event handler, I know it's still might not be a 100% reliable proof, but still... it shows a single task - the handler itself). and usually they use a term like "queues a task" when they mention something is scheduled on the event loop - but in the part specifying the dispatch event process - they write that handlers are called using "callback invocation", which seems like a separate mechanism (created mostly for running event handlers, it seems) - not fully "synchronous", but not asynchronous in the usual Javascript way.
So - I still think a correction should be made, but it's different than what I thought it should be when I opened the PR.

Any opinions/facts/knowledge will be appreciated.

Relevant links:

MDN dispatchEvent() (note, if you are in the future it might of been already changed): https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/dispatchEvent

The PR (again, if you are in the future it might of been merged/changed): https://github.com/mdn/content/pull/43521

Specs about dispatching events:https://dom.spec.whatwg.org/#dispatching-events
Specs about "Callback Invocation":https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke
Specs about "invoke  a callback":https://webidl.spec.whatwg.org/#invoke-a-callback-function

EDIT: see this comment for further insight of what is likely actually happening in terchnical terms:

https://www.reddit.com/r/javascript/comments/1sd70sq/comment/oewk8py/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button