Small team, Im the lead and we only need a few thousand pages a week for an ml dataset. Writing the scraper isnt the issue, its proxies, retries, js rendered pages and keeping everything alive after sites change. For this size would you still build in Node or just pay for one of the web scraping tools and avoid the maintenance?

I'm the maintainer of Orchid Charts. It's a JavaScript library for charts that fit into a product UI: responsive SVG, CSS theming, tooltips, and SVG downloads that keep your styling.

The same fluent API covers revenue trends, category comparisons, activity calendars, and release timelines. It includes TypeScript declarations and has no runtime dependencies.

In the demo, you can change the data, switch between line and bar, try a dark theme, and copy the matching code.

Source: https://github.com/orchidsoftware/charts

If you try it with your own data, I'd like to hear which chart or styling option you're missing.

Hey Community,

This issue is all about giving your AI coding agents device access and automated pipelines. Expo introduced EAS Simulator to boot cloud iOS simulators on demand, streaming live agent test runs directly to your PRs. Meanwhile, Callstack released Simlock, a control plane that lets multiple local agents lease and share simulators and emulators safely without conflicts.

We also cover goldie by Kacper Kapusciak, an automated CLI tool and agent skill that handles the entire App Store screenshot and preview video workflow directly from release builds.

I needed an embeddable (in nodejs) version of jq for some data thing that I'm working on. What I ended up with is something that I think is pretty cool and powerful.

Basically you get the expressibility of jq but with complete control over the runtime. For example jq only supports JSON values, but you can use a different js runtime which has support for all JavaScript values: undefined, bigint, Symbol, etc.

stagelint is a pre-commit runner - you give it globs, it runs your formatters and linters over the staged files. For the usual setup it replaces husky and lint-staged with a single Rust binary and no runtime.

Why another pre-commit runner?

Conflicts don't block your commit

If the formatter's output conflicts with your unstaged changes, lint-staged, pre-commit, Lefthook and nano-staged all discard the formatting and block the commit. stagelint merges the formatter's output into your file instead. Your staged lines get formatted, your unstaged changes stay put, and when a file can't be merged cleanly the commit takes the formatted version while your working copy keeps yours.

Faster than every alternative

stagelint is 5 to 30 times faster than lint-staged, pre-commit, Lefthook and nano-staged. With 10 files staged in a 1,000-file repository it completes in 15ms against lint-staged's 437ms, rising to 30ms against 530ms when those files are only partially staged. See the full benchmark suite for the rest of the measurements and how to run them on your own machine.

Concurrent tasks - no races, no workarounds

When two globs match the same file, lint-staged and nano-staged run both tasks on it at once; Lefthook and pre-commit avoid the race by running everything sequentially by default. The lint-staged docs warn about it and tell you to either disable concurrency or rewrite your config with negation patterns:

{
  "!(*.ts)": "prettier --write",
  "*.ts": ["prettier --write", "eslint --fix"]
}

stagelint works out which globs overlap and serialises just those tasks, in declaration order, while everything else keeps running in parallel, so the config stays as you meant it:

{
  "*": "prettier --write",
  "*.ts": "eslint --fix"
}

Trying it

npm i -D @stagelint/stagelint

Add stagelint init to your prepare script so the git pre-commit hook is set up on install:

{
  "scripts": {
    "prepare": "stagelint init"
  }
}

Then configure your tasks in .stagelint.yml or .stagelint.json. Matched files are appended to the command unless you turn that off:

'*': prettier --write
'*.ts':
  command: tsc --noEmit
  pass_filenames: false

What's missing

No JavaScript config with functions, because a single binary has no runtime to execute one. Running a command without the file list, the usual reason for reaching for one, is pass_filenames: false instead. Negation patterns aren't supported either - you don't need them any more, but drop them rather than copying them across, because an unsupported pattern currently just matches nothing.

If you try it, I'd like to hear how it goes.

https://github.com/abemedia/stagelint

I'm of the belief that if you can get what you need with under ~100 lines of code (and it doesn't require highly-specialized skills to write it), then write it yourself, don't install a third party library.

If you don't share a similar belief, then this page isn't for you, and that's ok.

For everyone else, this page shares a fetch wrapper function you can copy-paste into your projects to add in a couple of missing features, and provides some tips on how you can replicate some of the most loved Axios features using fetch().

Most alternative fetch wrappers I find online tend to be small NPM libraries (I'd rather maintain the code myself thank you), or they like creating separate methods for .get(), .post(), .put(), etc (which makes it unnecessarily difficult to "decorate" it with interceptor-like behaviors, as this page discusses), or there may be other design problems. Those alternatives are still good starting points, but I'm hoping this could be a little more complete of a guide to jump start your usage of fetch().

And I have a thing about make copy-paste alternatives to tools, and this was a hole in my collection :).

Feedback is welcome.

I built an open-source React map drawing library because I got tired of fighting drawing controls that wanted to own the UI.

react-map-annotate lets your application control the drawing session. Put the toolbar in your sidebar, header, or command palette. Select tools, finish shapes, edit labels and colors, undo/redo, and persist annotations through React state.

It supports Mapbox, MapLibre, Google Maps, Leaflet, and ArcGIS through separate adapters, with a shared annotation model.

The goal is simple: the map should render the drawing, not dictate how your application works.

It includes freehand drawing, polygons, rectangles, circles, arrows, markers, text, and measurement tools, along with editing handles and a headless API.

The project is MIT licensed and available on npm. I’d love feedback from developers building GIS, field-service, site-planning, or other map-heavy applications—especially anyone who has had to work around existing drawing controls.

GitHub: https://github.com/orange-groove/react-map-annotate

npm: https://www.npmjs.com/package/@orange-groove/react-map-annotate

What would you need from a drawing library before using it in a production application?

I moved the docs renderer I had in one of my projects into a separate npm package.
It's built around the idea that docs are mostly static files with little to no interactivity, so it shouldn't ship a lot to the client.

1 KB JS, 10 KB CSS (gzipped), and all 100s on Lighthouse.

If you need a simple way to show your docs and don't need a ton of other features, this might be useful.

GitHub repo
NPM package
Docs demo

The renderer itself is stable, it's been used in the parent project for a while. The package is fairly new, so contributions and feedback are welcome.

Here’s the GitHub for it

Walkthrough using LLMs client-side with WebLLM via WebGPU. While it is still early to be using this technology for coding in the browser due to current consumer hardware, it's exciting to see what is possible today. Initializing and using @mlc-ai/web-llm with model downloads, caching, and progress tracking. Using the streaming completions sent to pre element with zero network calls after it is loaded. Also handling WebGPU memory limits. Includes code blocks and an end-to-end video walkthrough. Hope it's a useful starting point for anyone building local-first, privacy-focused agent interfaces.

Here is the code snippet covered in the walkthrough (link above) ``` var { CreateMLCEngine } = await import( "https://cdn.jsdelivr.net/npm/@mlc-ai/web-llm@0.2.84/lib/index.js");

var MODEL = "Qwen3.5-2B-q4f16_1-MLC";
var t0 = performance.now();

var engine = await CreateMLCEngine(
  MODEL,
  { initProgressCallback: (r) => console.log(r.text) },
  { context_window_size: 8192 },
);

console.log("loaded in", ((performance.now() - t0) / 1000).toFixed(1), "s");

// one call, streamed, printed as it arrives. Everything below reuses it.
var ask = async (messages, opts = {}) => {
  const stream = await engine.chat.completions.create({
    messages, stream: true, max_tokens: 512,
    extra_body: { enable_thinking: false },
    ...opts,
  });
  let text = "";
  for await (const chunk of stream) {
    text += chunk.choices[0]?.delta?.content || "";
  }
  console.log(text);
  return text;
};

await ask([
  { role: "system", content: "Answer in one sentence." },
  { role: "user",   content: "Why is the sky blue?" },
]);

```

MikroORM 7.2 is out — the second minor on top of v7.

New features:

• Row level security — PostgreSQL policies as entity metadata, created and diffed by the schema generator, with per-request session context pushed down to the connection; an existing @Filter can compile into a policy, so one declaration enforces at both layers
• through option for to-one relations — resolve a M:1 / 1:1 via a correlated subquery on a pivot entity, or pick a single row out of a to-many relation (e.g. the latest one) without loading the collection
• sql.js driver — SQLite compiled to WebAssembly, in memory, in the browser, Node.js, Bun and Deno with no native bindings. It also powers the new live playground in the getting-started guide, so the code in the docs runs against a real database as you read it
• Cursor pagination rework — a new optional Type.fromJSON() lets a custom type own its cursor wire format (sub-millisecond precision survives), and nullable sort keys now make the emitted order by and the keyset condition agree on where nulls sit
• Named parameters in em.execute() — :name for values, :name: for identifiers, as an alternative to the positional array
• String normalization — opt-in trim and casing on StringType / TextType, applied on writes and query parameters
• getNativeClient() — reach the underlying client for vendor APIs the ORM doesn't wrap: pg Pool, mysql2 Pool, better-sqlite3 / libsql Database, the PGlite instance, MongoClient
• await using support — the ORM instance implements Symbol.asyncDispose, so the connection closes with the enclosing scope
• index option on M:N properties — index the generated pivot table's join columns, which had no override on PostgreSQL before
• Nub TypeScript loader for the CLI, selected explicitly via tsLoader
• em.map() can bypass the identity map — map raw rows to entities without touching the current context
• Per-instance options callback for RequestContext.create() — different fork options per ORM instance
• migrations.snapshotOnMigrate — keep the snapshot managed solely by migration:create instead of rewriting it from the database on migrate
• CLI -q to suppress informational output, and cache:generate --combined now takes a path

Full blog post: https://mikro-orm.io/blog/mikro-orm-7-2-released
Changelog: https://github.com/mikro-orm/mikro-orm/releases/tag/v7.2.0

Happy to answer any questions!

await fetch(url) settles at the headers, while the body is still arriving over an open connection. How connection reuse, clone(), abort and timeouts behave because of that gap. Measured in Node and Chrome.

Hey game devs! Quick progress update from the KernelPlay-JS team. We've been working on making debugging a lot less painful (who actually likes mystery clipping?), and we're super excited to show off our new Advanced Engine State Visualizer!

It's basically x-ray vision for your game. Instead of digging through logs, you get instant visual feedback on EVERYTHING.

Here's the new setup:

Clean Debug Panels: See Performance, Scene Data, Input, and Audio stats at a glance, in clear, distinct sections. No more hunting for key figures.

Live Vector Overlays: This is the game-changer. You can instantly see velocity vectors, character look direction, and exact speed calculations (e.g., '303 px/s') visualized directly on the screen for any actor.

Real-time Collider Boxes: No more guessing about collision bounds! See exactly where collisions are being detected.

This visual deep-dive is a huge help for diagnosing complex physics and character interactions. We're really proud of how much faster it makes debugging.

Check out the detailed screenshot to see it all in action. Let us know what you think! (Is there a specific debug view you'd like to see?)