r/javascript

sales kept saying the dashboard got too slow during long demos,not slow when it loaded, slow after a while, and nobody could tell me when, the best description I ever got was "maybe after lunch"...

every profiling session I ran,looked completely nice,open the app, click through the main flows, take a heap shot, flat line, ten minutes (and more) of use and no growth at all.

I closed the ticket as not reproducible twice, which I am not proud of.

Third time it came back I gave up on reproducing it in ten minutes and tried reproducing it in six hours instead, wrote a script that opened a record, opened the detail modal,closed it, moved to the next record, and did that all night, snapshot every five hundred loops, dump the heap if it dies.

by morning I had a chart going straight up and a dead browser tab at loop four thousand one hundred....yes....!

the modal added a resize listener when it opened,and the cleanup that was supposed to remove it sat behind condition that came out to be false, when you closed that modal by clicking the backdrop instead of X button,so every backdrop close left listener behind....

each one of thosee held closure,and each closure held onto that row data it rendered with,the whole record,not some small piece of it.

one leaked listener holding forty kilobytes is nothing,four hundred of them is sixteen megabytes of garbage that never goes away and plus four hundred handlers all firing every time the window resizes,which is why it showed up as slowness long before it showed up as crash,the symptom and the cause looked like two different bugs...but..:)

here is why nobody was ever going to find this by hand,you would have to open and close the same modal a few hundred times,using that one specific way of closing it,in one sitting,without refreshing,and then to notice something getting gradually worse with no clear moment where it got broked.

no tester does that,and not because they are lazy,it is just not reasonable thing to do with an afternoon or sessions end,pages get refreshed,and the moment you refresh the counter goes back to zero

the bug needed time,and time is the one thing you cannot get more of by being better at your job, everything else you can make for with skill and attention and etc,you cannot make up for eight hours of doing the same thing over and over and over again

we run that soak test every night now, it has found three more leaks since, none of them would have shown up in a session short enough for a person to sit through. this is basically what got me into QA tooling as a job, i work on autosana now and long running automated sessions are the whole point of the thing.

I want to learn js and react but i didn't find any good source online to learn on yt

Suggest me the best and the easiest perso6or playlist that helps me to complete js and react with in a month

I’m working in a VanillaJS repository (plugin type code for an existing project that I do not own) where I’ve written a signal implementation.

Today I was working on a tooltip like implementation and I found myself wondering how far to go with the signal/effect ecosystem vs running the “core” logic in the event handler.

The implementation detects the `<tr>` that the user has hovered and assigns that row to the “current row” signal. A computed signal identifies an IP address from the current row. An effect loads Whois metadata from the IP and assigns it to a `<div>`, and another effect shows that `<div popover>` from the parent `<tr>`.

The question I have is when in VanillaJS how would you decide when to use signals and effects vs writing the side effect directly in the event handler? In my case I find either to be equally readable, though I have less local variables to deal with when using signal/effect. Looking for reasons your might pick one over the other.

This was awful because a dirty workspace could make the package look complete.

I found a Worker runtime split into libwpd.mjs and libwpd.wasm. The build staged the JS loader. The binary came from another step and was not checked or copied by the Worker package. A clean package could not prove that it owned the runtime it shipped.

I fixed three boring things:

1. The Emscripten build refreshes both files.
2. The Worker build copies both files into dist.
3. The build hashes both files and fails if either one is missing or changed.

const runtime = [
  ['libwpd.mjs', expectedLoaderHash],
  ['libwpd.wasm', expectedWasmHash],
];

for (const [name, expected] of runtime) {
  const bytes = await readFile(resolve('vendor', name));
  const actual = createHash('sha256').update(bytes).digest('hex');
  if (actual !== expected) throw new Error(`${name} checksum mismatch`);
}

The useful rule was simple: the loader and binary are one release unit. "Offline" is not enough if a clean checkout can borrow yesterday's artifact.

Would you commit generated WASM for reproducible installs, or rebuild it in CI and verify the hash there?

Hey everyone,

I wanted to share an experimental project called DriftJS. It's a frontend framework prototype that explores using an in-browser register-based Bytecode Virtual Machine (VM) for UI rendering, rather than traditional Virtual DOM diffing or purely compile-time reactive models.

Repository: https://github.com/hrutavmodha/driftjs

The Architecture: Register-Based VM

Most frameworks either diff Virtual DOM trees (React) or generate reactive dependency graphs ahead-of-time (Svelte, SolidJS). DriftJS explores a different path:

It compiles .drift templates into compact binary-serializable bytecode streams. At runtime, a lightweight 256-register VM executes these opcodes directly against the DOM.

Key Architectural Highlights:

• Zero VDOM Overhead: Replaces tree-diffing with direct bytecode instructions (like CREATE_ELEMENT, SET_ATTR) for DOM execution.

• 256 Virtual Registers: Uses fixed virtual registers (r0, r1...) for DOM nodes and runtime values, drastically cutting instruction counts and memory allocations compared to stack-machine models.

• Targeted Reactivity: Basic state updates execute as direct O(1) mutations. Dynamic control flow structures (@if, @for) use comment anchors to bound surgical DOM updates without rebuilding subtrees.

Key Features So Far:

• 🛡️ 100% CSP Compliant: Built-in Acorn AST interpreter evaluates runtime JS expressions safely without using eval() or new Function().

• 🔄 Keyed LIS Reconciliation: Uses a Longest Increasing Subsequence algorithm to minimize DOM node movements during list updates.

• 🪶 Zero Framework Bloat: Implements reactivity and execution in the leanest bytecode form possible, avoiding heavy object models and monolithic runtime bloat.

• 🚀 Early Benchmarks (js-framework-benchmark vs React 19): • 10.8x FASTER on "Swap rows (1k)" • 3.05x FASTER on "Clear 1,000 rows" • ~1.8x LESS memory footprint • 5.75x smaller uncompressed bundle size

Current Status & Call for Feedback

DriftJS is currently an experimental prototype. It handles single-template compilation, AST evaluation, and keyed LIS list reconciliation.

Still on the roadmap:

• Component composition & props passing
• State management stores
• SSR & Hydration

I'm opening this up to compiler engineers, frontend performance nerds, and systems devs. Does a register-based VM architecture hold real promise for low-level web runtimes?

Check out the repo, run the benchmarks, and feel free to share your thoughts or ISA critiques!

GitHub Repo: https://github.com/hrutavmodha/driftjs

TypeScript 7 shipped in July as the Go port, billed as roughly 10x faster. The line that matters for linting is in the same announcement: 7.0 does not ship with an API, and typescript-eslint is named as one of the tools that still needs programmatic access to the compiler. There is a compat package, u/typescript/typescript6, that installs a tsc6 executable and re-exports the 6.0 API, with a new API expected in 7.1.

So the speedup that would matter most to typed linting is the one you cannot have yet. typescript-eslint's own performance page says that with type-aware linting your lint times should be roughly the same as your build times. Builds got most of an order of magnitude faster and the typed rules still sit on the 6.0 checker.

Which makes Biome's timing look luckier than it probably was. Its inference engine arrived with v2 in June 2025 and got its own types domain in 2.4 this February, and it does type-aware rules without loading the compiler at all. Their own preliminary figure for noFloatingPromises is about 75% of the cases typescript-eslint catches, at a fraction of the performance impact, with a warning right after it that the early numbers rest on a limited set of use cases. The docs also say a types domain rule makes Biome scan the whole project and switch the inference engine on, so that path is not free either.

On my repo the diff gets read by lint, by typecheck in CI, and by a review agent in verdent before anyone opens the PR, and I have no measurement telling me which layer is doing the work.

What are people doing in the gap? Pinning tsc6 to keep the typed rules, running Biome's approximate set on save, or waiting for 7.1?

This one is awful because the build succeeds.

The host app installs pdfjs-dist@6.1.200. A PDF renderer depends on pdfjs-dist@5.4.624. If asset-copy code resolves the Worker from the app root, it can copy 6.1.200. The renderer code still uses API 5.4.624. Vite serves the wrong Worker, and the browser reports a version mismatch.

The fragile version looks like this:

const worker = require.resolve(
  'pdfjs-dist/legacy/build/pdf.worker.mjs'
)

I changed the lookup to resolve pdfjs-dist from the renderer package that owns it. The build now fails if the resolved asset version differs from the renderer dependency.

I ran the harness today across npm and pnpm, nested and hoisted layouts, Vite dev and build, and real cold installs. In every case the copied Worker, CMaps, WASM, and fonts had to come from 5.4.624, while the app kept 6.1.200. The asset manifest also records the source package and version. No more "it probably resolved correctly."

Should build tools always resolve runtime assets from the dependency that owns them, or should packages force one PDF.js version across the whole app?

Did you find or create something cool this week in javascript?

Show us here!

I've been programming on the side since 2017 and I've never really hunted a developer job. I've always thought about building my own things, mainly to supplement things I do like woodworking, tutoring, video editing and others.

Since then, I've programmed mainly with JavaScript, I started with C++ and Python but never really built anything solid outside JavaScript.

So I'm fluent with JavaScript and its ecosystem.

One of my 2026 goals is to be job ready for a Developer role, as a Fullstack or Backend Developer.

One of the recommended languages is Typescript, which I've been learning since March. I must say, it's not my favorite 😂

I'm curious to know if there are any companies that are not enforcing Typescript or are there freelancers who are still using vanilla JavaScript over Typescript for their clients' projects.

I am working on a P2P video calling client using webRTC.
I am using getMediaDevices() to get the users' stream. If I just do {video: true} it gives me a smaller stream than my device supports.
By default it gives me a 640 x 480 stream. I can set it manually to the max dimensions which is 1920 x 1080.

How can I find the max dimension for any device?

Another thing I wanted to know. I have the video element in a div, which has the width of fit-content. When the incoming stream first arrive from the other peer, The video starts smaller and keeps growing, why is this?

Hi, a few years ago I wrote a C99 compiler that generates a bootable binary which, once loaded onto a floppy disk, can be run in x86 real mode. It supports x87 floating-point operations, has a simple IR, optimizes the generated code, and produces output of fairly decent quality (by toy compiler standards). Maybe someone will find it interesting.

At SVAR, we build UI components for React, Svelte, and Vue. Just shared our experience with a data grid – how to make it fast in all three frameworks.

What surprised us: the expensive bits (virtualization, memoization, data flow) are almost entirely framework-independent, and framework overhead is a rounding error next to DOM size.

Curious if you have seen similar patterns in your projects?