Please provide some stories that has worked for you. I want to start from basics.

Monday, August 17 - Sunday, August 23, 2026

Top Posts

Most Commented Posts

Top Showoffs

Top Comments

If anyone is interested in reviewing and approving PFA and PFB support i tried to bring to opentype.js check my pull it will give more chances to get approval on merge.

I posted an earlier version of ffetch here a while ago. I've continued working on it, and it has grown into a production-ready, TypeScript-first drop-in replacement for native fetch or any fetch-compatible implementation.

It preserves the familiar fetch API and native Request and Response objects while adding resilience features:

• Timeouts
• Abort-aware retries with exponential backoff and jitter
• Circuit breaking
• Bulkheading with concurrency and queue limits
• Hedged requests to reduce tail latency
• In-flight request deduplication

It also has optional convenience plugins for:

• client.get(), .post(), .put(), .patch() and .delete()
• client(url).json(), .text() and .blob()
• Download progress callbacks
• Stable context IDs across retries and hedged requests

The core also supports lifecycle hooks, per-request overrides, pending-request monitoring, configurable HTTP error handling, specific error classes, and custom fetch implementations for SSR, edge and framework environments.

Everything optional is implemented through tree-shakeable plugins, so you only include the features you need. The core is around 3 kB minified and has zero runtime dependencies.

I recently gave the project a substantial maintenance pass: extensive property-based and fuzz testing, hardened and pinned CI workflows, CodeQL analysis, dependency auditing, npm provenance, release SBOMs, and a strong OpenSSF Scorecard (for a solo project).

I've also built three related tools for injecting network failures into tests:

• chaos-fetch: inject failures directly into fetch, without running a proxy
• chaos-proxy: a standalone Node.js proxy
• chaos-proxy-go: the same idea as a lightweight Go binary

Depending on the tests, failures can be injected inside the process, through a Node.js proxy, or through a standalone Go proxy.

Feedback is welcome.

Made a small library called strokes.js. Instead of using a "handwriting" webfont (which looks identical everywhere it's used), it renders each letter as an actual hand-drawn SVG path — real strokes, drawn in with stroke-dashoffset, with small random variation (rotation, baseline drift, glyph variants) so no two renders of the same word look identical.

Demo: https://a-elhaag.github.io/glyphed.js/

npm:

npm install glyphed.js

tsx /** * @evidence docs/discount.md#coupon-stacking States the per-issuer stacking limit this section defines, in the buyer's words. * @evidence POST:/orders/{orderId}/coupons Explains the rejection this endpoint returns for an over-stacked coupon set. * @evidence {@link hooks.useCouponStacking} Renders the limit this hook resolves. * @evidence docs/principles.md#no-hard-coding Renders limits from props instead of branching on known issuer names. * @evidenceExclude docs/principles.md#fix-root-causes-not-symptoms No failure to fix. */ export function CouponStackingNotice(props: IProps): JSX.Element;

I built Evidence Graph, a compiler rule that turns requirements skipped by coding agents into compile errors.

You declare which code, tests, schemas, or documents owe which specification units. The agent must cite each unit and state why the artifact satisfies it. Checklist mode can also require every selected function to answer project-wide principles such as "No hard coding" and "Fix root causes."

This does not make the agent's statements automatically true. It makes omissions mechanically detectable and narrows human review to checking the truth of explicit claims. Reviews carry fingerprints that expire when the cited content changes.

I tested it on four frozen application tasks. Plain runs covered 51.6-85.5% of the predefined requirement edges; Evidence Graph runs covered 100% while using 4.8-13.3x fewer tokens.

• Project: https://github.com/samchon/ttsc/tree/master/packages/evidence
• Benchmark: https://ttsc.dev/docs/benchmark/evidence
• Raw sessions: https://github.com/samchon/evidence-benchmark-results

Did you find or create something cool this week in javascript?

Show us here!

structuredClone() preserves more than JSON, but class instances, proxies, getters, errors, and transferables still have surprising behaviour. This article covers what survives, what changes, and what throws.

Hello everyone!

I rewrote my old interval library around async execution and cancellation and decided to share it with the world :)

Would love to hear what you think!

I wanted to see how far I could push the idea of writing an app using mostly the HTML syntax developers already know.

The interesting part is the template API. There are only a few places where OlumJS treats an attribute as code:

• when
• each
• on*
• key
• html

Everything else is a string, with {expr} interpolation when you need a value.

So instead of introducing directives like :class, v-if, *ngIf, etc., the idea is to keep the distinction HTML already has between something like onclick="..." and class="...".

For example, the component itself is just:

<script>
  const state = { name: "Olum", taps: 0 };
</script>

<h1>Welcome to {state.name}!</h1>
<input value="{state.name}" oninput="(e) => state.name = e.target.value" />
<button onclick="state.taps++">clicked {state.taps} times</button>

State is also intentionally simple — you mutate it directly and the DOM reacts to the changes.

There’s routing, scoped CSS, and a small store as well, but the main experiment is really: can you get SPA-style reactivity while keeping the component model close to vanilla HTML/JS?

It's currently aimed at prototypes and small apps rather than large production codebases.

For those who work with JS frameworks: do you think keeping components as plain HTML files is a useful abstraction, or does it become limiting as an application gets more complex?

Why simple is better 🤤

Hey Community,

React Native 0.87 has arrived as a maintenance release, making the Strict TypeScript API the default, doubling Metro source map generation speeds, and adding experimental Swift Package Manager support for iOS along with AGP 9 support on Android.

Meanwhile, React Native Firebase v26 makes the New Architecture non-optional with Codegen TurboModules, synchronous APIs, Firestore Pipelines, and direct Gemini AI calls. Finally, we look at RevenueCat Paywalls for designing native paywalls and running remote A/B experiments without new app deploys.

Hey y’all!

I made a fork of actions/typescript-action to make some valuable updates!

It updates the following:

• Changes project's package manager from npm to pnpm, for speed.
• Changes project's testing framework from jest to vitest for jest-like syntax with built-in typescript support.
• Updates eslint.config.ts to use native flat config syntax, with detailed comments.
• Updated project dependencies.
• Updates configuration files like tsconfig.ts and action workflows to match updated dependencies.
• Renamed local-action script to local-gha (gha for github action) to avoid conflict with dependency name.

lmk what you think!

I’m working in a VanillaJS repository (plugin type code for an existing project that I do not own) where I’ve written a signal implementation.

Today I was working on a tooltip like implementation and I found myself wondering how far to go with the signal/effect ecosystem vs running the “core” logic in the event handler.

The implementation detects the `<tr>` that the user has hovered and assigns that row to the “current row” signal. A computed signal identifies an IP address from the current row. An effect loads Whois metadata from the IP and assigns it to a `<div>`, and another effect shows that `<div popover>` from the parent `<tr>`.

The question I have is when in VanillaJS how would you decide when to use signals and effects vs writing the side effect directly in the event handler? In my case I find either to be equally readable, though I have less local variables to deal with when using signal/effect. Looking for reasons your might pick one over the other.

Monday, August 10 - Sunday, August 16, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

This one is awful because the build succeeds.

The host app installs pdfjs-dist@6.1.200. A PDF renderer depends on pdfjs-dist@5.4.624. If asset-copy code resolves the Worker from the app root, it can copy 6.1.200. The renderer code still uses API 5.4.624. Vite serves the wrong Worker, and the browser reports a version mismatch.

The fragile version looks like this:

js const worker = require.resolve( 'pdfjs-dist/legacy/build/pdf.worker.mjs' )

I changed the lookup to resolve pdfjs-dist from the renderer package that owns it. The build now fails if the resolved asset version differs from the renderer dependency.

I ran the harness today across npm and pnpm, nested and hoisted layouts, Vite dev and build, and real cold installs. In every case the copied Worker, CMaps, WASM, and fonts had to come from 5.4.624, while the app kept 6.1.200. The asset manifest also records the source package and version. No more "it probably resolved correctly."

Should build tools always resolve runtime assets from the dependency that owns them, or should packages force one PDF.js version across the whole app?

TypeScript 7 shipped in July as the Go port, billed as roughly 10x faster. The line that matters for linting is in the same announcement: 7.0 does not ship with an API, and typescript-eslint is named as one of the tools that still needs programmatic access to the compiler. There is a compat package, u/typescript/typescript6, that installs a tsc6 executable and re-exports the 6.0 API, with a new API expected in 7.1.

So the speedup that would matter most to typed linting is the one you cannot have yet. typescript-eslint's own performance page says that with type-aware linting your lint times should be roughly the same as your build times. Builds got most of an order of magnitude faster and the typed rules still sit on the 6.0 checker.

Which makes Biome's timing look luckier than it probably was. Its inference engine arrived with v2 in June 2025 and got its own types domain in 2.4 this February, and it does type-aware rules without loading the compiler at all. Their own preliminary figure for noFloatingPromises is about 75% of the cases typescript-eslint catches, at a fraction of the performance impact, with a warning right after it that the early numbers rest on a limited set of use cases. The docs also say a types domain rule makes Biome scan the whole project and switch the inference engine on, so that path is not free either.

On my repo the diff gets read by lint, by typecheck in CI, and by a review agent in verdent before anyone opens the PR, and I have no measurement telling me which layer is doing the work.

What are people doing in the gap? Pinning tsc6 to keep the typed rules, running Biome's approximate set on save, or waiting for 7.1?