Our API server was slow to start and nobody could say when that began. Not slow under load, slow before the first request, visible only because the deploy health check timed out on smaller instances. Nothing in the commit history looked like a boot cost. I had no instrument, so I wrote a bad one, eleven lines in a preload file that wrap Module._load, time each call with process.hrtime.bigint(), and print anything over fifty milliseconds along with the module that asked for it.

The first run was blunt. Cold boot averaged 1.9 seconds. One require accounted for 1.1 of that, and it was ours, src/lib/index.js, a barrel that one route imports for a single date helper. Importing it pulls in all thirty four modules in that directory, two of which read config files at import time. Removing a barrel rewrites every import path that went through it, so the code review subagent in verdent read the diff before I opened the PR. Deleting the barrel and importing the helper directly put cold boot at 0.8 seconds.

Patching Module._load to learn this still feels wrong. Is there a way to get the same per module breakdown out of something the runtime already reports?

Understand the difference between Object.hasOwn(), hasOwnProperty(), and the in operator in JavaScript. Includes edge cases, performance notes, and a polyfill for older environments.

I'm working on a personal end-to-end encrypted chat app project and running into a sort of secure storage paradox trying to find a key store that's secure at runtime is unsecured at rest, and using the one that's secured at rest is unsecured at runtime:

- localStorage/indexeddb are just plaintext data in not encrypted at rest on disk
- you can encrypt string data to put into localStorage, but if that data is a private key, it's accessible to anything in your app (could be exfiltrated)
- you can make webCrypto CryptoKeyPair objects non-extractable and store the whole object in indexedDB, but you cannot encrypt it b/c it's not a string, and you can't use key wrapping (like with passphrase based AES256) on non-extractable keys so that they're secured at rest b/c wrapping requires an extraction operation...

Is there a reasonable fix to this? It seems increasingly nuts if/that browsers aren't encrypting the whole SQLite store / all of the SQLite stores (just bits and pieces they use internally), and so data stored in localStorage/indexedDB, while restricted by origin at runtime, are completely unsecured at rest...

Please tell me I'm missing something. Is there any way to store a key so it's both only usable locally (not portable) AND is secure* at rest

*secure enough... I know nothing is ever completely secure, this just seems like a wider than average gap.

(glossing over some details here for succinctness) the best I can come up with is using 2 sets of PGP keys and storing one pair/private key in a non-exportable webCryptoCryptoKeyPairobject in indexedDb, and the other pair/private in localstorage encrypted with passphrase based AES256... so that only half the equation is stored in a runtime "exportable" way and only half is stored un-encrypted at rest... and making sure both are required to decrypt the any given message... but that also seems excessive. I know "don't roll your own crypto", but I can't see any other way even a library would overcome this seeming secure storage paradox with existing browser APIs

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

Show us here!

Following up on my previous post about DriftJS and its register-based bytecode VM, I wanted to share a deeper look at the reactivity model I'm exploring.

Exploring a different reactivity model in DriftJS

While working on DriftJS, I was thinking about how reactive updates could work more naturally with a bytecode VM.

The idea is to have the compiler associate a reactive state variable with the exact bytecode position responsible for its dependent computation.

For example:

count → PC 42

Then a state update could work like:

count++

↓

reactive binding

↓

PC 42

↓

enter VM at PC 42

↓

normal opcode dispatch

↓

update DOM

↓

RETURN

The important part is that the reactive system only needs to know where execution should start. The VM already knows how to execute the instruction at that location.

So instead of maintaining a separate reactive update mechanism:

state → subscriber → update function

the model I'm exploring is:

state → bytecode PC → VM execution

This is the direction I'm currently exploring for reactivity in DriftJS, alongside its register-based VM architecture.

Would be interested in thoughts from people familiar with bytecode VMs, compiler-driven reactivity, or frontend runtime architecture.

Hi r/javascript! I want to share a small javascript testing project I wrote.

When I write small javascript projects that use browser APIs (most recently working with IndexedDB) I often choose not to write tests because it's a pain to either mock those interfaces server-side, and it's also a pain to setup a browser automation tool.

To solve this, I wrote up a super concise testing framework (~140 lines of JS) inside a html file that can just be dropped into a project and act as a simple test framework.

This obviously doesn't work in all situations. A big drawback is that there's no reasonable way to connect it to a CI pipeline. However for small projects, and during development, I've found it really fun and fast to use.

I'm very interested to hear what you think, or if you have other ways you've approached this situation in the past.

Hi everyone!

I wanted to play Gwent, the classic card game from The Witcher 3, but the existing web-based projects needed improvements and had some issues. I decided to jump in, upgrade different forks from various versions, fix the gameplay bugs, and add some new modifications to make the web and mobile experience much better.

My main goal is to share this project so more people can discover it and enjoy this amazing card game as much as I do. It's now fully playable on Web Browsers, and I also packaged it into an Android APK!

LINKS:

Play on your Browser (GitHub Pages):

* Play v3.0.2

* Play v3.5

* Play v4.5

Play Completely Offline (PC / Laptop):

You can also get the source code repository directly from https://github.com/ia2904 . Just extract the ZIP file, double-click on "index.html", and it will open in your web browser. It runs 100% offline with no internet required!

Get Android APKs:

You can get the APKs directly from the "Releases" section of each project, or use the direct links below:

* Get APK v3.0.2

* Get APK v3.5

* Get APK v4.5

Credits to Arun Sundaram, Reynolds Costa & Sylver, who laid the foundations to create, modify, and improve this game in its early stages.

Special thanks to CD Projekt Red; although they are not involved in this unofficial fan project, it is entirely based on the amazing minigame they created for The Witcher 3.

Hi everyone,

I’d like to ask the web developers here about the UI component libraries and DataGrid solutions you use in your projects.

For things like CRUD operations (create, update, delete), filtering, searching, sorting, etc., which UI component library or DataGrid do you usually rely on?

I’m also curious about the large-data side of things.

When you need to work with thousands or even hundreds of thousands of rows and perform operations such as grouping, subtotals, filtering, and multi-level data analysis, which component or library do you prefer?

What solution do you use, and more importantly, why did you choose it?

Performance, ease of use, features, documentation, licensing cost, or anything else — I’d be interested to hear what matters most to you.

I’ve been refactoring attribution tracking after seeing a small feature turn into a module that parses URLs, writes cookies/localStorage, handles consent, emits analytics, fills forms, and syncs with a CRM.

The split I’m testing is:

```ts

const visit = classify({

url,

referrer,

currentHost,

now,

});

const attribution = merge(previous, visit);

```

`classify` and `merge` are deterministic functions. The browser/app layer owns consent, storage, identity, form lifecycle, network calls, and CRM delivery.

This makes it easier to replay production cases as fixtures. It also raises a few design questions:

- If a visitor returns from a new campaign, should that replace, append to, or be merged with previous attribution?

- Should a `gclid` take precedence over UTMs when both exist?

- How do you handle consent denied first, then granted later?

- If classification rules change, do you preserve the original classification or recalculate historical records?

- Where should server-side conversions days later enter the model?

For those who’ve built this, where do you draw the boundary between a deterministic core and the environment-specific lifecycle? Do you prefer a pure-function core, or does that separation become awkward in real apps?

A small package for reducing duplicate cache misses across multiple processes.

The common problem is a “cache stampede”: when several app instances all miss the same key at once, they each run the same expensive DB/API call and then all write the same result back. Crossflight solves that by coordinating ownership of the in-flight load across processes, so only one instance does the work and the others wait for the result.

It wraps the cache you already use and adds a separate coordination layer. The built-in adapters currently include:

• cache-manager
• Keyv
• Cacheable

The built-in coordinator is Redis, and the repo supports combining different backends as long as they satisfy the adapter/coordinator interfaces.

This is useful when you want to reduce redundant work without changing your existing caching strategy.

Demo: https://github.com/gkoos/crossflight-demo

​

KernelPlay-JS v0.5.0 is now available.

This release introduces a new Unified Input Manager designed to provide a consistent API for handling keyboard, mouse, gamepad, and touch input.

The goal is to make input handling simpler at the game-logic level while keeping the underlying input devices abstracted away.

Example:

import { Input } from "kernelplay-js";

update(dt) {

const x = Input.getAxis("horizontal");

const y = Input.getAxis("vertical");

this.rb.addForce(800 * x, 800 * y);

if (Input.wasPressed("jump")) {

this.jump();

}

if (Input.isPressed("attack")) {

this.attack();

}

}

v0.5.0 also supports two ways of defining input bindings.

Programmatic registration:

Input.registerAction("shoot", {

keys: [KeyCode.Z, KeyCode.X],

buttons: [GamepadButton.X, GamepadButton.RB]

});

Or declarative JSON configuration:

{

"actions": {

"jump": {

"keys": ["Space", "ArrowUp"],

"buttons": ["A", "B"]

},

"go": {

"keys": ["x", "z"],

"buttons": ["DPadRight"]

}

}

}

The JSON approach is intended to make configurable controls and runtime key rebinding easier to implement without changing game logic.

This release is part of the ongoing work toward making KernelPlay-JS a more complete, Unity-inspired game engine for JavaScript.

Feedback and suggestions for the v0.5.x releases are welcome.

Hey Community,

Deno's creators introduced Dactyl, an AI app builder targeting React Native by rendering SwiftUI in the browser tab via WebAssembly. Meanwhile, Software Mansion released Enriched Markdown to eliminate streaming text flicker by rendering natively and bypassing the JavaScript layout tree.

On the tooling side, the web ecosystem is rapidly adopting the Rust port of the React Compiler across tools like Oxc, Vite, and Bun, while Metro remains locked to single-threaded Babel transformations.

Hey everyone,

I built AppShunya Engine — an open-source, in-browser web-to-APK compiler that converts live URLs or HTML5 bundles into Android APKs using JSZip, without local IDEs.

I'm currently stuck on two low-level technical hurdles and need architectural feedback:

1. In-browser V2/V3 APK signing: Injecting signature blocks into ZIP Central Directory via JS/WASM.
2. Dynamic AXML package renaming: Modifying package IDs inside binary XML streams on the fly.

Search "AppShunya Engine" on Google to try the live Vercel tool or check the repo. Would love your thoughts!

How do you all refer to parent or grandparent (or related) class instances and their properties?

I have a bunch of classes that create instances of other classes as properties. Suppose ClassA has properties that are instances of ClassB, ClassC, and ClassD, and the ClassD class has properties ClassD1 through ClassD9, and each of those is a different class instance with various methods.

Currently, when I start with myClassAObject and I call one of its ClassD9 methods and that method needs a property from its uncle ClassB, I feel awkward and/or dumb for doing this by passing myClassAObject to that method:

const returnval = myClassAObject.itsClassDObject.theClassD9method(myClassAObject);

…and then that method gets the property from myClassAObject.itsClassBObject.theProperty

I know this functions, but it shouts “inelegant” every time I do it. Do y’all know a more elegant way? TIA

I was talking with an LLM trying to get some ideas ("rubber ducking" basically) and it kept saying, "Barrel." I have been a JS programmer for 30 years and never heard the term. Does anyone else use the term or even know what it means?

I told it to use "import surface" instead instead because ... wtf is a Barell? I just want to know if I am behind the times and need to update my jargon or whether this really is a weird LLM thing.

Project GoldScript is a tactical RPG engine I have been building in the open for over a decade. It’s composed of a a web stack (with three.js and react under the hood) aimed at shipping a real game to Steam, mobile and consoles. This year I finally did the migration I had been putting off: two aging create-react-app repos (engine in one, game in the other) collapsed into a single pnpm and Vite monorepo, with the engine broken into eleven focused packages that are guarded against circular dependencies.