Libraries for Node.js

Node-compat is not 100%. Joined Anthropic — watch ecosystem/governance noise, but license remains MIT. Not Deno. Some packages still assume Node quirks.

Fuzzy finder only - not a file manager, not ripgrep itself (pairs with it), not a shell. You wire the pipes. Not Atuin shell history sync.

Vs Hono: Bun-first ergonomic lane; Hono is multi-runtime edge-first. Ecosystem and hiring still Bun-skewed. Not Nest/Fastify full Node default.

Task runner only. Not a bundler. Not Nx. Not Bazel.

NuxtHub Admin sunset Feb 2026 — self-host or provider-native deploys. Optional Nuxt UI Pro is paid; framework itself is free.

Core client is free forever; Pro (~$6/user/mo billed annually) and Ultimate (~$11) unlock in-app Git UI, OpenAPI sync quotas, and org admin. Golden Edition is sunset for new buys. Not a mock/monitor platform like Postman Cloud. Hoppscotch is the web-first alternative.

Vs Bruno (git-native *desktop* collections as files): Hoppscotch is web/self-host first, not “collections are just commits” by default. Cloud/workspace features and self-host ops are the real product surface — Enterprise exists for orgs. Not a mock/monitor platform.

typst.app collaborative cloud is a separate product with its own free/paid seats — the compiler CLI here is the OSS gem. Vs Pandoc/Quarto and vs LaTeX: smaller package ecosystem and different mental model; migration is a rewrite, not a flag. Not a slide tool.

Vs depcheck (deps-only) and eslint unused-import rules: Knip is the *project-wide dead-code map*, not a runtime tracer and not a type-checker. False positives show up with dynamic imports, config plugins, and “used by tooling not by app code” — you still tune entry points and ignore rules.

Vs React/Next SPA defaults and Hotwire/Livewire cousins: htmx is *HTML-first progressive enhancement*, not a component tree with client routing. Complex client state, offline, and rich widgets still push you toward a heavier front-end — or you accept server round-trips as the model.

Vs Zod (de-facto TS schema): Valibot wins on *modular/tree-shakeable bundle size*; Zod wins on ecosystem gravity (tRPC/forms/examples assume Zod). Migrating is real work — action APIs and helpers differ. Not a form UI and not an API gateway.

Vs Zod/Valibot (schema validation): Effect Schema is one piece; Effect is a whole effect system and runtime, not a drop-in validator. Learning curve and import surface are real — teams that only need parse/validate should stay on Zod/Valibot.

Node ≥22 and a real render pipeline (Puppeteer/ffmpeg class of deps) — not a one-liner SaaS render. Skill registry can lag main; use `hyperframes skills update` when you need HEAD. Vs Remotion (React compositions) and browser-use (page agents): HyperFrames is HTML→deterministic video for agents, not a general browser agent or React timeline editor.

Local GPU/CPU and model downloads are on you; macOS/Windows desktop footprint is heavier than a REST TTS call. Large open-issue count — treat cutting-edge engines as experimental. Vs ElevenLabs-class cloud TTS (paid APIs) and Whisper-only STT stacks: Voicebox owns both ends of the loop locally, with agent voice as a first-class surface.

Vs Notion/Drive dumps: this is a document archive appliance, not a knowledge wiki or agent memory layer. GPL-3 copyleft for modifications; OCR/ML quality depends on language packs and scanner hygiene; public docs/demo endpoints may be WAF-gated from some networks — use the GitHub tree and Compose files as source of truth.

Not a drop-in ripgrep — ~10 lines/sec on a laptop CPU and modest zero-shot accuracy; author says check on your data. Early Show HN: ★1 on GitHub. First-run 1.3 GB model download is a disk/bandwidth hit.

v10 is a rewrite, so v8-era plugins and tutorials will not drop in — check what you depend on before upgrading. It is a player, not hosting or transcoding: you still need a video source and a CDN. Vs a bare `<video>` tag: worth it when you need consistent controls, skins, and streaming formats across browsers.

It is built for tools and debug UIs, not polished end-user interfaces: theming, accessibility and text input for complex languages are limited. Immediate mode means you manage your own state and layout in code. Docking and multi-viewport live on a separate branch.

It is a framework, not an editor-driven engine like Godot, so you build your own tooling. Web export relies on GWT or newer third-party backends, which adds friction. Releases are a few a year, and iOS support depends on RoboVM forks.

2D only, with no editor, scene system or physics built in, so you assemble those yourself. Mobile and console builds need Cgo. Xbox support is limited and not available to everyone. Mostly led by one core maintainer.

Modern C++ (C++17 and up) template-heavy code means long compile times and dense error messages. v4.0.0 brought breaking changes from the 3.x line. It is a toolkit, not an engine: rendering, physics and editors are up to you. Largely a one-maintainer project.

Activity has slowed: there are no recent tagged releases and the last code change was August 2026, so check open issues before relying on it. Turn-based only; it is not for real-time games. Hosting the server and storage is up to you.

It is a C++ library with no editor; integrating it into a custom engine takes real work. Mostly built by one main author. Fluid and cloth simulation beyond soft bodies are out of scope.

Performance and tooling are below dedicated engines for anything graphics-heavy, and there is no visual editor. The 3D package is early. You need to be comfortable with Flutter and Dart.

The editor is Windows-only; runtime targets are wider but the workflow assumes Windows. Smaller community, fewer assets and less documentation than Godot or Unity. Mobile and console paths are less mature.

It is a fork, so most features, docs and plugins come from upstream Godot and compatibility can drift over time. The community is a fraction of Godot's. Unless you have a specific reason to prefer its governance, Godot itself is the safer default.

Mostly a one-person project, so long-term support depends on its author. No editor or big plugin ecosystem. For larger 2D games, Phaser or Godot give you more structure.

The community is small and much of it remembers the Corona era, so newer tutorials are scarce. Lua is a niche language for many teams. 3D is out of scope.

The model file syntax (request, policy, matchers) takes time to learn, and mistakes are security bugs. Large policy sets need care for performance. It decides access; it does not handle authentication or user management.

Large files get slow in the graph view. The maintainer also builds ToDiagram, a paid product, and the open-source app gets fewer releases. It is a viewer and converter, not a full data tool.

v5 brought breaking changes, so older tutorials target v4. With Go 1.22 and later the standard library router covers many simple cases. Gin has a larger ecosystem.

Node only; browsers must use the native WebSocket. It is low-level, so rooms, reconnection and fallbacks are your job (or use Socket.IO). Recent Node versions ship a built-in WebSocket client.

Needs Go 1.26 or later for the latest release. Formula calculation does not cover every Excel function. Older .xls files are not supported.

Not Ory Kratos, the identity server with the same name. v3 is fresh, and many guides still target v2. A lot of the community and examples are Chinese-language.

Pre-1.0, so the spec can still move. The Python package is not released yet; the port in the repo is a source-only preview. The README pushes a hosted MCP endpoint first; for private or large data, run the local server instead. It is a layer on top of existing chart libraries, so you still ship Vega-Lite, ECharts or Plotly to render.

Low-level by design: no scene graph, physics, audio or editor, so you are building an engine, not a game. It uses its own GENie build setup and the companion bx and bimg repos, which takes a while to get comfortable with. No tagged releases; you track the main branch. For a ready engine, Godot or Raylib are the faster start.

It is built on fasthttp, not net/http, so standard-library middleware and handlers don't plug in directly; you need adapters or Fiber's own versions. v3 changed the API from v2, so check which version a tutorial targets.

v3 broke the v2 API, so older tutorials and Stack Overflow answers won't match; check the import path (v3) before copying examples.

Releases are slow (the last one was in February 2026). Since Go 1.22 the standard library's ServeMux handles method matching and path parameters, so a small service may not need a framework at all.