Free and open source, no signup. The theme changes with the era. Borders before ~500 BC are approximate, and leader data is thin before 1600, so corrections are very welcome. Link in comments.

code: https://github.com/nsijwali/WhoRuled

built this after getting tired of manually writing fetch wrappers for sites with no public API. point it at a HAR file (browser network capture) and it generates a typed client.

input: a captured request to something like `GET /users/42`

output (simplified):

export interface User {

id: number;

name: string;

email: string;

}

export async function getUser(id: number): Promise<User> {

const res = await fetch(`${baseUrl}/users/${id}`);

if (!res.ok) throw new ApiError(res.status, await res.text());

return res.json();

}

it infers the types from the actual response bodies in the capture, templates dynamic path segments like `{id}`, and also generates an OpenAPI spec + mock server from the same HAR.

also tries to catch GraphQL/tRPC/JSON-RPC calls instead of treating everything as REST, and strips anything sensitive (tokens, cookies) from the captured data before it reaches the generated code.

npx har2sdk capture.har -o ./sdk

repo: https://github.com/Mersbyte/har2sdk

curious what people think of the generated code style, or if anyone's hit an API shape it chokes on.

Spent the last months building

@datastripes/forecast
@datastripes/dashboard
@datastripes/anomaly 

These are framework-agnostic npm packages (React, Vue, Angular, or a plain custom element) that add time-series forecasting, an editable dashboard builder, and anomaly detection to any frontend app.

Everything runs client-side via WebAssembly, so no user data ever hits a server except a license check without a backend to deploy, no Python microservice.

Would genuinely love feedback from anyone who's had to build this kind of feature in-house.

https://datastripes.com/forecast-widget/

https://datastripes.com/dashboard-widget/

https://datastripes.com/anomaly-widget/

I've been working on Knitting, a JavaScript worker runtime using shared memory for communication and work stealing for scheduling.

Some results from the published benchmarks:

• 8.9× faster empty-call round trips than postMessage on Node.js (4.4× on Bun, 4.3× on Deno).
• 86% lower p99 latency in a Hono server test: 16.93 → 2.31 ms at 6,000 req/s.
• Nearly identical CPU per request in that test: 180 → 183 µs.
• 3.5× CPU-heavy throughput on Node.js with four extra workers.

I've been working on this for more than a year, so there are a lot of things to showcase, but knitting was designed to offload work from servers.

Features:

• Typed worker calls and specialized payload types
• Shared-memory transport and zero-copy buffers
• Work stealing and automatic load balancing
• Timeouts and cancellation with real signals
• Precompiled workers and process isolation
• Process workers
• Permission (when available)
• And more ...

Docs · Benchmarks · GitHub

I’m most comfortable in JS/TS, and I wanted to learn LangGraph.js properly, so I wanted to build in that. When I looked for a production-grade example, the closest thing I found was Deep Agents, but that’s a library for building agents, not a full system. The complete systems I saw were mostly Python, like Open SWE. So I built my own.

It reviews GitLab merge requests and resolves issues. It’s been running in production for a few months, 1,000+ reviews so far. A webhook drops each review into a BullMQ queue, a LangGraph.js agent does the work with GitLab tools over MCP, runs are checkpointed in Postgres, and there’s a React admin UI where I can watch runs live. I also had to add guardrails to stop the agent repeating tool calls or quitting before it’s done.

MIT, all TypeScript.

three-nebula is a magical 3D particle engine for the web. I maintain it, and v13.3.0 (Helix) is the first of a few releases working back toward the library's original design goals. This one is additive and backward-compatible, so it is a safe bump.

The engineering theme this release is determinism. Two new behaviors and four new emission zones all produce the same output given the same seed, which matters a lot when you want reproducible scenes, snapshot testing, or editor previews that do not drift between runs.

The first behavior, Vortex, applies a tangential swirl around an axis with optional inward or outward pull and radial falloff. It acts directly on particle velocity rather than going through the Force path, which means it sidesteps the internal Force x100 scaling quirk and stays predictable. The second, CurlNoise, drives particles with the curl of a Perlin field. The curl of a vector field is divergence-free, so particles roil without clumping into sinks. The noise is seeded through mulberry32 rather than Math.random, so nothing in the pipeline reaches for global nondeterministic state.

The four new zones (RingZone, DiscZone, CylinderZone, ConeZone) sample uniformly and are axis-aligned to +Y. Ring and Disc are planar emission zones, while Cone and Cylinder are solid and work as true 3D CrossZone boundaries. All five new types round-trip through System.fromJSON, and the debug renderer draws wireframes for the new zones, so serialization and tooling stay in step with the runtime.

Release notes and full changelog are here: https://github.com/creativelifeform/three-nebula/releases/tag/v13.3.0

I would be curious what people think about the seeded-RNG approach for a library like this. Threading an explicit seed everywhere instead of Math.random adds a little API surface, but it is what makes the JSON round-trip and snapshot tests reliable. Have you handled determinism differently in your own simulation or animation code?

Circuit breakers are good at stopping traffic and bad at resuming it. When a breaker closes, every replica goes back to the constructor limit at the same moment, so a dependency that just answered a few probes receives its full load again.

I've been adding a recovery ramp to Caracal, my TypeScript resilience library, on top of its distributed bulkhead, rate limiter and circuit breaker.

This is the sixth article in a series on distributed resilience. Feedback welcome, particularly if you have run slow start or ramp-up in production.

As a software engineer I always love creating unique and cool designs and animations on the web, and I also wanted a blogging website for myself.

Recently I made my personal blog and wanted something hand-drawn on it so I sketched some flowers on my iPad and exported them as SVGs, then I wrote a script that cuts each drawing into its flower head, buds and leaves (the drawn stems get thrown away), and the site grows long curvy stems in code, hangs the leaves and buds along them and puts the flower at the tip.

Every stroke is drawn in gradually with CSS. After that, in React, I hooked that progress to the scroll while the photo stays pinned. All this just to create the scroll animation on the page above.

tbh idk how good it looks, but I wanted to do something creative for my first blog website.

Any feedback will be highly appreciated!

Can any one tell me what do they miss or i should implement extra to solve the problem of 3d design and building with easy integartion of 3d tech and design i choose Next js for fast And dynamic reload and three js for 3d designing and gizmo and other stuff comes from react-three-fibre/drei and library i m trying to build ui similar to spline so comment down for a feature You were hopping in this app

I will soon deploy

It's a tiny library for how I love to do these tings. Lemme know what you think!

Bots in my game sim (TypeScript, built with Cline) kept printing identical rows. Equal averages can be a coincidence, so I didn't want the lab saying "these bots played the same" unless they actually did. So every move gets logged as a short string: `B:ticker:cents` for a buy, `S:holdingId` for a sell, `K` for a skip. Moves are joined with commas, all 1,000 games with newlines, and two bots only match if the whole strings are equal.

I skipped hashing mostly because the result ends up in posts and I didn't want a collision to be possible at all. Yeah, SHA-256 collisions aren't a real risk. The better reason is probably debugging. Factorio's old desync post does a CRC every tick so they know the first tick where two runs split. A hash just tells you "different."

Would you have hashed it? And if you keep logs, do you store the whole thing or just enough to find the first diff?

Context: I'm coming from Python with FastAPI and want to try build a similar app using express, but the thing i'm most lazy about is definitely configuring swagger, compared to the built-in swagger integration that fastapi provides. apparently express-zod-api tries to bridge that gap, but i don't know how good is it?

hey! tsuzuki is a free site that tells you which legal platform streams an anime in your country

source code: https://github.com/tsuzuki-anime/tsuzuki-anime.github.io

no server, no database, just node scripts + github actions + github pages. a few things i figured out along the way:

• weekly full fetch, daily light fetch: the full catalog (18k anime) is only rebuilt on sundays. other days the script reuses the published json and only refreshes airing shows, which cut api calls by ~90%
• safety guards: if the api returns way less data than what’s live (it happened), the build refuses to publish, so the site never goes half empty
• wikidata as a second source: one SPARQL query adds french titles and extra streaming links that the main api didn’t have
• watch order guides: built automatically by walking the prequel/sequel graph of each franchise

everything is free, no ads, no account. happy to answer questions about the setup!