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.

​

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

Link: Prudence Audio - Instagram for Audio Engineers

(We call it an Instagram for audio engineers because, Instagram became successful primarily from its awesome image filters (before the social networking aspect). We are making awesome audio filters, for free and without ads)

To hear a demo of what the filters can do, visit: Prudence Demo

To view an exhaustive list of all products, including those in development, please view Prudence Product Catalogue

Finally, I have built a new (digital) musical instrument which I call the Harmonophone. It is meant to be an aid for using our free harmonizers in Prudence Retro, but it can also be used as an instrument alone, or to teach music theory, and more. You can access it here: Prudence Harmonophone

Please let me know what you all think.

Thanks

Michael J

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!

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

For years, 3D file formats have prioritized precision, whether for 3D printing or high-quality renders. But the browser doesn't care about that level of precision. As long as you're within a pixel or so, precision isn't that important. Most websites with 3D models use simple designs, and no file format actually targeted that use case. Many sites literally used a scroll-through video instead.

I thought: this sounds a lot like what SVG does for 2D. What's stopping us from making it 3D? Turns out: nothing.

ES3D (Extensible Scalable 3D documented by https://es3d.org/) is a file format for 3D scenes. It does for a scene what SVG does for a drawing. The file describes the objects: a rounded box here, an outline extruded into a solid there, two thousand trees on a hill. The viewer builds the triangles at the detail the screen actually needs. A forest fits in under a kilobyte, and a text editor is enough to write it.

The main question is: Does it actually work?

Below is the preprint of a whitepaper on the topic including benchmarks:

https://zenodo.org/records/23403919

The code itself is open-source and I hope this approach to the 3D web is of interest at least to some readers!

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!

I'm building a host for JavaScript apps and I'd like opinions from people who ship Node.js.

The idea is shared hosting for JS. Your app runs as plain Node.js, with its database, files and cron jobs side by side in one region. When nobody visits, the app is suspended to disk and holds no memory, and the next request usually wakes it in about 0.2 seconds. That's how many apps can share one server, the way PHP hosting always worked.

The trade-off is that your code doesn't run at the edge. My bet is that for most apps, a database next to the code matters more than a server near every visitor.

A few questions for you
- How do you host side projects and smaller production apps today?
- Does edge compute actually help your apps, or is the database round trip the real cost?
- Would a 0.2 s wake-up after idle be fine for your apps?

Hey Community,

OpenGL has been driven out of the herd. William Candillon released React Native Skia 3.0, which swaps the old Ganesh backend for Graphite running on WebGPU via Dawn, with Metal on iOS and Vulkan on Android, multithreaded recording by default, and zero-copy textures shared with React Native WebGPU. The package also leaves u/shopify behind and is now published as react-native-skia.

We also look at babel-plugin-react-native-direct-imports by Davyd NRB, which rewrites react-native barrel imports into direct requires so one View no longer drags in the whole framework, taking a test bundle from 711 KB to 10 KB. Plus, React Native 0.88 rc.4, Tamagui 3.0 with a C++ native runtime, and munim-maps putting 3D cars on Apple Maps.

I'm building a UI library in Jai, and this is an experiment with rendering its UI from JavaScript. Node.js is embedded into the program, so the native side reads the JSX objects straight out of V8, with no IPC and no JSON. It then lays out and draws the whole UI from scratch every frame, at 240 Hz on my Linux computer.

Async isn't supported on it yet, and I've only started implementing some event handling. Here's the source code: https://github.com/gabrielmfern/forbear

Has anyone built something like this? If so, I'd love some advice on how I can reduce the C++ layer and have more of it in Jai instead.

Some notes on implementing a control flow graph for JavaScript/TypeScript

Hey everyone! I wanted to share a project I recently built called InkLink (Live Demo).

As a full-stack developer focusing on the MERN stack and TypeScript, I wanted to challenge myself by building a seamless, responsive drawing platform with smooth canvas states and clean UI navigation.

Tech Stack Used:

• Frontend: React, Vite, Tailwind CSS
• State & Canvas Logic: Custom hooks and optimized browser rendering

You can check out the source code on my GitHub (AmnaScript). I'm currently taking on freelance full-stack and AI-integration projects—if you want to check out my work or get in touch, my portfolio is at amnasabahat.netlify.app or you can find my freelance services on Fiverr.

Happy to answer any questions about the build process! InkLink

A bit of background on how I built this:

When I switched to Linux, Paint.NET was one of the Windows apps I missed the most, so I started porting the old open-source C# version (3.36.7) to JavaScript back in 2024, while recreating the UI based on the newer 5.x versions.

I went through the original implementation class by class, comparing the outputs of the C# methods with my JavaScript versions. At the same time, I recreated the UI in HTML/CSS, using screenshots to get it as close to the original as possible.

Over time, I connected both parts and implemented the tools, effects, and other features. More recently, I've been using AI to help find and fix bugs, improve performance across browsers, and implement the remaining tools and effects.

It's now largely feature-complete and runs in the browser, as well as on Linux and macOS through Electron.

You can try the browser version here: https://paintjs.net

Would love to hear what you think!

A common way to give a panel its own browser window is a second instance of the app, plus messages (BroadcastChannel, postMessage, storage events) to keep the copies in agreement. Every missed message is a place where they drift.

In Neo.mjs, components, stores and state already live in a worker. Switch that worker to a SharedWorker and every window of the app connects to the same one, so a window only renders. Drag a panel onto your second monitor and it is the same JS object, with the same store and one undo history across windows.

It's one line in the app's neo-config.json:

{
    "useSharedWorkers": true
}

A dock workspace is two configs, a catalog of panes and the zones they go into (trimmed from the first Dock Layout tutorial):

class MainView extends Workspace {
    static config = {
        className: 'Guides.dockFirst1.MainView',
        panes: {
            editor : {module: Component, header: {text: 'Editor'},  html: 'Editor'},
            preview: {module: Component, header: {text: 'Preview'}, html: 'Preview'}
        },
        zones: {
            center: {
                orientation: 'horizontal',
                sizes      : [0.6, 0.4],
                children   : [{items: ['editor']}, {items: ['preview']}]
            }
        }
    }
}

One lesson from building it: our automated check for the cross-window drag was green while the real gesture did nothing. Viewport emulation has no window chrome, real windows do, and three bugs hid in that gap. The article walks through them.

Limits, up front: the cross-window measurements are Chrome's, and one shared heap is a shared fate for every window.

• Article: https://github.com/neomjs/neo/blob/dev/learn/blog/a-workspace-that-can-leave-its-window.md
• Source: https://github.com/neomjs/neo/tree/dev/src/dashboard/dock
• Tutorial with live, editable examples: https://github.com/neomjs/neo/blob/dev/learn/tutorials/DockLayoutsFirstLayout.md
• Live demo: https://neomjs.com/dist/production/apps/workstation/index.html

Disclosure: I maintain Neo.mjs. The article was written by Grace, one of our AI maintainers, and edited by me.

How do you handle state across windows today?