Was untangling the various classes/protocols/methods involved, and couldn't find such a diagram, so I made one. Might be helpful as a complement to the MDN pages.

While I've previously posted this in r/cybersecurity the given answer, "lock versions / read on incidents / hope for the best", was not really what I was hoping for nor satisfactory. So I'm re-trying in a more specialized group.

----

I'm new to JS (at least JS from the last decade) and am getting paranoid with the new JavaScript ecosystem.

- The first thing I did was switch from node to deno.

- Then configure { "minimumDependencyAge": "P30D" }

But each time I looked at the dependency tree, the hundreds of thousands of files downloaded from the most various sources gave me the chills. So eventually:

- Started running the project inside a podman container

But then I started thinking that as much as I was pointing the IDE (IntelliJ) to run things inside the container, I would eventually miss something, and the IDE would eventually run whatever exploit might be inside that myriad of dependencies I can't keep track of.

So now:

- IntelliJ runs inside the container. I access it via the "remote server" option.

But, after all of this, looking at this setup, it's starting to look a bit too much for something that should be much simpler.

It's just a Nuxt frontend; how did this happen?

What is the community-recommended approach?

I've been open-sourcing a charting toolkit built on top of TradingView Lightweight Charts that includes drawing tools, indicators, replay functionality, pane synchronization, and broker integrations.

One area I'm still refining is the plugin/extension architecture.

For developers who have worked with charting libraries:

• What extension points do you expect?
• How would you structure custom indicators?
• Would you prefer a plugin registry, hooks, middleware, or something else?
• What API mistakes have you seen charting libraries make?

I'd love to hear opinions before locking down the architecture.

I spent a few weeks building a 2D physics engine from scratch in vanilla JavaScript. No libraries, no build tools, just Canvas 2D and the browser.

It does SAT collision detection, a sequential-impulse solver with friction, sweep-and-prune broadphase, fixed-timestep simulation, and five interactive demo scenes including a stack stability test and Newton's cradle. (With a lot of bugs)

https://github.com/CAPRIOARA-MAGIKA/physis

The hardest part was getting box stacks to settle without jitter or sinking. Turned out to be a combination of Baumgarte stabilization tuning and warm-starting the solver. The stack-stability gating test caught more bugs than I can count.

It's not perfect. It has a lot of bugs but I cannot figure out how to fix them (if you know a way please open a PR or comment below). This project was done for learning and with minimal AI involvement (only for debugging and polishing the readme file).

If you have any more suggestions of projects that I could do in the near future to improve my reasoning and my coding skills, comment down below. Thanks for reading!

The backend is down. Your PM wants a demo in 2 hours. You need `/api/users/42` to return a specific payload and you can't touch the server.

I've been in that situation enough times that I built something for it.

[Demo](https://imgur.com/a/IoaDdPP)

JediMock — you configure the mock in a UI, it generates a script, you paste it once in the DevTools console. The next request is intercepted. Refresh the page and it's completely gone. No service worker registered in your app, no proxy running, no certificate to install, no cleanup.

It replaces `window.fetch` and `XMLHttpRequest` with wrapped versions that check a rules table before forwarding. When the page unloads, the originals are restored. That's the whole trick.

Beyond basic mocking:

- Wildcards — `/api/users/*` catches every user endpoint in one script

- Response Rules — return different data per call count. 401 on call #1, 200 after. Exact auth retry flows without a real server.

- Fallback mode — if the server doesn't respond within your timeout, the mock fires. Useful when the backend is flaky, not just absent.

- Async ID mode — captures a dynamic job ID from a trigger request and injects it into a polling response. No callback server needed.

- Request interception too — not just the response. Modify the body going out.

It's also a full toolkit in the same file: bulk JSON editor, validator with line-level errors, diff, beautifier. Session persists across reloads.

No build step. No dependencies. No account.

- App: (https://jedimock.com)

- GitHub: (https://github.com/machopicchu/jedimock)

Curious — for those of you using MSW or a proxy setup: what made you go that route instead of a DevTools-first approach? Genuinely want to understand the tradeoffs I might be missing.

Hi everyone, I'm the author.

I tried turning a minified production stack trace back into its original function names entirely by hand, and hit something that surprised me: the source map gives you perfect locations but gets every name wrong, and it turns out that's structural, not a bug. The format is a list of points with no concept of where a function starts and ends, so you can't recover names from the map alone, you have to parse the bundle too. Writeup has every step reproducible.

I thought this was interesting, and digging into it taught me a lot about how source maps actually work. I’m working on an open source symbolicator, so if you have any thoughts on the article, or if I've gotten something wrong, I'd really like to hear it.

Hey there,

The PHP/Laravel community recently got this package: laravel/pao
which basically compact the response of your test run to save on taken and be more AI friendly.

Do we have a tool resembling this in the JS/React community?

Hey Community,

We dive into react-native-runtimes by Margelo and Callstack, which bring multiple JavaScript runtimes to React Native to isolate heavy tasks from the main thread. We also look at Headroom, a context compression layer that slashes token costs by up to 95% when running Claude Code on your codebase.

Finally, we share our experience porting an Expo game to Amazon Fire TV with Amazon Devices Builder Tools, focusing on the practical steps of cleaning up monorepo scripts and using concurrently to keep your bundler alive.

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

Pessoal, boa noite. Estou na metade do curso de Análise e desenvolvimento de sistemas, mas ainda não sei para que caminho ir. Pesquisei algumas linguagens de programação, e vi que o Java Script está em alta. Eu gostaria de recomendação de cursos de JS e dicas para iniciar na área, por favor.

I've been working on numpy-ts since last fall, and began performance optimization in January. Lots of my assumptions / intuitions were wrong, and it turned out that memory ownership was a bit of a missing piece to reaching performance parity with native.

So I drafted this technical write-up with some of the lessons learned. Many/most might be obvious but would love to hear your thoughts!

Disclaimer: this project was built using some AI assistance. Read my AI disclosure for more info.

Author here (I'm building Plain, a GitHub alternative), so flagging the affiliation up front.

The writeup is about treating sync as the substrate instead of adding realtime to features one at a time. Two engines, because there are two kinds of state:

- Rows (issues, PRs, CI, messages) stream out of Postgres via ElectricSQL as "shapes" over HTTP. The browser holds a live query. Electric is read-path only, so writes go through server functions and reconcile optimistically via a Postgres transaction id

(pg_current_xact_id()) that Electric stamps on the row when it streams back.

- Document bodies are CRDTs over Yjs/Hocuspocus, since people type into the same paragraph at once. Presence/typing is just Yjs awareness, so no heartbeat table.

I'm honest about the costs in the post too: two stateful services, Postgres on logical replication, and the auth proxy in front of Electric as the obvious choke point. Curious how others have handled the rows-vs-documents split, and where people expect this to strain at scale.

I've been working on NativeDocument for about two years. The goal was simple: write front-end code that feels natural, performs well, and doesn't require a build step to be productive.

Most frameworks solve the same problems in similar ways. NativeDocument takes a different approach on a few things.

No virtual DOM. Reactivity is fine-grained. When an observable changes, only the exact DOM node that depends on it updates. No diffing, no tree reconciliation, no unnecessary re-renders.

No re-renders on navigation. The router preserves layouts between route changes. When you navigate within the same group, the layout stays intact. Only the content updates. Scroll position, sidebar state, all preserved by default.

The store has explicit access modes. use() for two-way sync, follow() for read-only, get() for raw access. You can export a store that's read-only by design via protected(). Mutations from the wrong place throw at runtime.

Inspired by SwiftUI's declarative style. The API is chainable and reads close to natural language. No JSX, no template syntax, just JavaScript.

```js const $count = Observable(0);

const Counter = () => Div({ class: 'counter' }, [ Button(Span('-')).nd.onClick(() => $count.$value--), Span($count), Button(Span('+')).nd.onClick(() => $count.$value++), ]); ```

A more real-world example — a reactive todo list with zero diffing and surgical DOM updates:

```js import { $ } from 'native-document'; import { ForEachArray, Div, Button, Span } from 'native-document/elements';

export function TodoApp() {

const todos = $.array([
    { id: 1, text: 'Learn NativeDocument' },
    { id: 2, text: 'Build something fast' },
]);

const addTodo = () => todos.push({ id: Date.now(), text: 'New task' });

return Div({ class: 'todo-app' }, [
    Button('Add Task').nd.onClick(addTodo),
    // Zero diffing
    ForEachArray(todos, (todo) =>
        Div({ class: 'todo-item' }, [
            Span(todo.text),
            Button('×').nd.onClick(() => todos.removeItem(todo)),
        ])
    ),
]);

} ```

No compiler, no transpilation, no framework-specific tooling required. It runs in the browser as-is.

Still early but the core is solid. Happy to discuss the architecture and tradeoffs.

https://github.com/afrocodeur/native-document/tree/develop

Been using dynamic OG image generators for side projects and always ended up tweaking templates, fonts, spacing, and layouts manually.

So I built ogimagecn, a shadcn/ui-style registry for beautiful Open Graph images.

Some of the features:

• Built on Satori
• Zero config, one command setup.
• shadcn/ui compatible (simply copy-paste)
• 10+ image components
• 100% free and fully open-source.

No design tool exports. No starting from a blank canvas every time you launch something.

If you're shipping products, blogs, docs, or OSS projects, this should make generating share images a lot less painful.

GitHub: https://github.com/shadcn-labs/ogimagecn
Docs: https://www.ogimagecn.com

I feel like Service Workers are an underused technology with a lot of benefits, but very complex to set up and often misunderstood, and what they do. Here are some case studies from Slack, Mux, and me on where and how to use Service Workers