This post runs three controlled chaos scenarios against the same endpoint to compare retry-only, Retry-After-aware retries, and hedging. One recurring result is that reliability gains can come with significantly worse p95/p99, while 429-aware retry behavior outperforms blind retries under rate limiting.
I implemented atomic hot config reload in both Node and Go with the same external contract, then reran benchmarks on the same machine and methodology. In this setup, Go remains about 1.92x higher throughput, while both versions show steady-state overhead from reload-safe runtime design.
Summary: Explains backpressure as producer–consumer rate control in JS, covering Node.js streams (write()/drain, pipe()), Web Streams, and pitfalls with async/await and Promise.all().
Drop-in replacement, zero deps, ~2KB. Has lifecycle hooks for auth/logging, exponential backoff with jitter, respects Retry-After headers, and proper AbortSignal composition. Preserves all native fetch behavior.
Hey,
I write a tech blog and I need to create lots of diagrams for it. I like using Mermaid, but I quickly ran into the same frustrating pattern with most of the existing editors and renderers: the free options were either too limited or came with barriers that slowed me down. I wanted something simple: just open the page, paste/type in Mermaid code, preview the diagram, and export it without worrying about limits or accounts.
Here are some concrete problems I ran into with other tools:
- Mermaid Live Editor (the official one): Great for quick editing, but exporting diagrams is capped by a rate limit on their free tier. After a handful of exports, I’d get the dreaded “free tier limit exceeded” message.
Kroki.io: Supports rendering, but running it online requires trusting a shared service with my diagrams. Hosting it myself means extra setup, Docker, and server resources — not ideal if I just want to save a few diagrams.
- Excalidraw & Lucidchart: Both have nice UIs, but they’re general diagramming tools, not native Mermaid editors. Lucidchart especially locks useful features (like unlimited diagrams or high-quality export) behind a paid plan.
- Other browser-based tools Almost all I tried had some kind of paywall, signup requirement, or watermark on exports. For something as text-based and simple as Mermaid, that felt unnecessary.
So I built my own tool with a few core principles:
- No limits: you can create, edit, and export as many diagrams as you want.
- No signup: the tool works straight from the browser, nothing to install.
- No tracking: privacy-friendly, just you and your diagrams.
- Open source: https://github.com/gkoos/mermaid-editor
Now this is a very simple v0.0.1 and needs a lot of refinement, but hopefully it can be useful to some even in its current state.
Looks neat. A few things though:
1. Deep equality checks on every dispatch may become expensive for large, deeply nested objects.
2. Auto-generated partial dispatchers can obscure what actually happens in updates.
3. Middleware API is Redux-like, but can't see support for async flows (like thunks or sagas).
Good start, covers the big GitLab pitfalls (auth, runners, vars, project config). The the fun part to be added: runner isolation/cleanup, built-in scans (SAST/dep/secret), logging/audit trails, push-rules (signed commits), and secret management practices. Solid so far tho.
In every JS/TS project, be it frontend or backend, you usually have to fetch some data. And when you go into production, you realise you need something more resilient than the native fetch.
There are some libraries on npm, but I found them either too dumb or doing too much, so I built my own.
- Timeouts - per-request or global
- Retries - user-defined, defaults to exponential back-off + jitter
- Circuit breaker - trip after N failures
- Hooks - logging, auth, metrics, request/response transformation
- Per-request overrides - customize behavior on a per-request basis
- Universal - Node, Browser, Cloudflare Workers, React Native
- Zero runtime deps - ships as dual ESM/CJS
- Written in TypeScript
In Guix, packages are typically dynamically linked against libraries in the store. Static linking changes not just the configure flags, but also how dependencies are pulled in - you'd have to make sure every dependency is available as a static .a library for the target platform and many Guix packages aren't built with static artifacts at all.
I guessit's a mix of market size, monetization difficulty, and investor expectations:
- a CLI or build tool can get huge love from devs but still serve a small, finite market
- many devs will happily use a free open-source tool but won't pay unless it's mission-critical
- funding is biased toward sales-driven models
- successful paid devtools usually have enterprise-grade support
- PH and X are cool but not for validating a sustainable business
Web bloat is coming from every angle, including - surprise - LLM's. So no, I don't think it's over. Also wdym AI companies rendering UI? You mean the chatgpt textbox?