​

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.

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.

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!

Please provide some stories that has worked for you. I want to start from basics.

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

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.

Monday, August 17 - Sunday, August 23, 2026

Top Posts

Most Commented Posts

Top Showoffs

Top Comments

If anyone is interested in reviewing and approving PFA and PFB support i tried to bring to opentype.js check my pull it will give more chances to get approval on merge.

I posted an earlier version of ffetch here a while ago. I've continued working on it, and it has grown into a production-ready, TypeScript-first drop-in replacement for native fetch or any fetch-compatible implementation.

It preserves the familiar fetch API and native Request and Response objects while adding resilience features:

• Timeouts
• Abort-aware retries with exponential backoff and jitter
• Circuit breaking
• Bulkheading with concurrency and queue limits
• Hedged requests to reduce tail latency
• In-flight request deduplication

It also has optional convenience plugins for:

• client.get(), .post(), .put(), .patch() and .delete()
• client(url).json(), .text() and .blob()
• Download progress callbacks
• Stable context IDs across retries and hedged requests

The core also supports lifecycle hooks, per-request overrides, pending-request monitoring, configurable HTTP error handling, specific error classes, and custom fetch implementations for SSR, edge and framework environments.

Everything optional is implemented through tree-shakeable plugins, so you only include the features you need. The core is around 3 kB minified and has zero runtime dependencies.

I recently gave the project a substantial maintenance pass: extensive property-based and fuzz testing, hardened and pinned CI workflows, CodeQL analysis, dependency auditing, npm provenance, release SBOMs, and a strong OpenSSF Scorecard (for a solo project).

I've also built three related tools for injecting network failures into tests:

• chaos-fetch: inject failures directly into fetch, without running a proxy
• chaos-proxy: a standalone Node.js proxy
• chaos-proxy-go: the same idea as a lightweight Go binary

Depending on the tests, failures can be injected inside the process, through a Node.js proxy, or through a standalone Go proxy.

Feedback is welcome.

tsx /** * @evidence docs/discount.md#coupon-stacking States the per-issuer stacking limit this section defines, in the buyer's words. * @evidence POST:/orders/{orderId}/coupons Explains the rejection this endpoint returns for an over-stacked coupon set. * @evidence {@link hooks.useCouponStacking} Renders the limit this hook resolves. * @evidence docs/principles.md#no-hard-coding Renders limits from props instead of branching on known issuer names. * @evidenceExclude docs/principles.md#fix-root-causes-not-symptoms No failure to fix. */ export function CouponStackingNotice(props: IProps): JSX.Element;

I built Evidence Graph, a compiler rule that turns requirements skipped by coding agents into compile errors.

You declare which code, tests, schemas, or documents owe which specification units. The agent must cite each unit and state why the artifact satisfies it. Checklist mode can also require every selected function to answer project-wide principles such as "No hard coding" and "Fix root causes."

This does not make the agent's statements automatically true. It makes omissions mechanically detectable and narrows human review to checking the truth of explicit claims. Reviews carry fingerprints that expire when the cited content changes.

I tested it on four frozen application tasks. Plain runs covered 51.6-85.5% of the predefined requirement edges; Evidence Graph runs covered 100% while using 4.8-13.3x fewer tokens.

• Project: https://github.com/samchon/ttsc/tree/master/packages/evidence
• Benchmark: https://ttsc.dev/docs/benchmark/evidence
• Raw sessions: https://github.com/samchon/evidence-benchmark-results

I wanted to see how far I could push the idea of writing an app using mostly the HTML syntax developers already know.

The interesting part is the template API. There are only a few places where OlumJS treats an attribute as code:

• when
• each
• on*
• key
• html

Everything else is a string, with {expr} interpolation when you need a value.

So instead of introducing directives like :class, v-if, *ngIf, etc., the idea is to keep the distinction HTML already has between something like onclick="..." and class="...".

For example, the component itself is just:

<script>
  const state = { name: "Olum", taps: 0 };
</script>

<h1>Welcome to {state.name}!</h1>
<input value="{state.name}" oninput="(e) => state.name = e.target.value" />
<button onclick="state.taps++">clicked {state.taps} times</button>

State is also intentionally simple — you mutate it directly and the DOM reacts to the changes.

There’s routing, scoped CSS, and a small store as well, but the main experiment is really: can you get SPA-style reactivity while keeping the component model close to vanilla HTML/JS?

It's currently aimed at prototypes and small apps rather than large production codebases.

For those who work with JS frameworks: do you think keeping components as plain HTML files is a useful abstraction, or does it become limiting as an application gets more complex?

Made a small library called strokes.js. Instead of using a "handwriting" webfont (which looks identical everywhere it's used), it renders each letter as an actual hand-drawn SVG path — real strokes, drawn in with stroke-dashoffset, with small random variation (rotation, baseline drift, glyph variants) so no two renders of the same word look identical.

Demo: https://a-elhaag.github.io/glyphed.js/

npm:

npm install glyphed.js

LilScript is a typed, compression-first language that compiles into js and sometimes into exec(will be more stable in future). The compiler mangles, reshapes the program into optimized js that happens to be 5-40% smaller (after gzip/br compression or raw) compared to the best performing JS toolchains like oxc/esbuild/terser/..

What has been proven to work with LilScript?

• makes VSCode's core js modules 20% smaller on average
• makes the world's most performant & small markdown rendering npm library, marked, 5-7% smaller and 10% faster
• and many more demos.. works with pretty much any js/ts library
• https://yeargun.github.io/solidlil/
• https://yeargun.github.io/monacolil/
• https://yeargun.github.io/markedlil/ (Some numbers on the websites aren't fair comparisons, especially for SolidLil. Highly optimized JS libraries see fewer benefits(Still, the app code/logic, gets pretty great optimizations). LilScript is designed to be at least as efficient as the best-performing JS/TS toolchains.)

How it is compressing js finer than vite/oxc/terser/esbuild/..

1. By changing the app.

``` class Vector { float x; float y;

init(float x, float y) { this.x = x; this.y = y; }

float lengthSquared() { return this.x * this.x + this.y * this.y; } } int[] values = [1, 2, 3, 4]; auto doubled = values.map((int value) => value * 2); int sum = 0; for (int i = 0; i < doubled.length; i++) { sum += doubled[i]; } Vector vector = new Vector(3.0, 4.0); if (vector.lengthSquared() == 25.0) { print(sum=${sum}); } ```

Above code compiles into this:

var b=[1,2,3,4].map(a=>a2|0); var a=0,c=0; while(a<b.length){ c=c+b[a]|0; a=a+1|0; } console.log(`sum=${c}`)

This is not minification of the same program. The compiler changed the app.

oxc / esbuild / terser / .. starts from JS and mostly keeps the shape of the app. Meanwhile LilScript the language is designed from scratch to give compiler any extra knowledge that could help the compiler's compilation. Just like Google Closure Compiler - Advanced Mode, and beyond.

2. Tryhard property mangling.

Visit the world's most used web applications, chatgpt.com, and read the shipped js codes. You will see that, there are lots of framework related js properties that dont get minified, and are indeed human readable.

Those names stay in the bundle because the toolchain cannot prove they are local. A property might be a public API, a DOM field, a framework hook, or something a plugin reads by string. So the minifier leaves it.

LilScript:

• a- does both eliminates the objects, weird code structures into more optimized variables/arrays - b- rename any variable into mostly occured, short versions, field cleverly to minimize entropy (based on the objective compression algorith. gzip/brotli) so that the end result is highly compressed.

(a) is the same move as the Vector example, at library scale: objects and classes that only exist as a programming convenience get flattened into scalars, arrays, and tight loops.

(b) is not "make every name 1 letter." gzip and brotli win when the same short tokens repeat. The compiler picks the names that show up the most, and scores the spelling against the compression algorithm you asked for (gzip, brotli, or raw). Different cost_model → different names → a different file that is smaller after* that codec.

That is why the same program can be 5-15% smaller after gzip/br compression or raw: the JS is shaped and named for the compressor, not just for a human reading the AST.

How well do LLMs write LilScript?

Since 1.5 years ago, you haven’t been writing the code yourself anyway. So why worry about what language the agent writes in? I myself have pretty much rewritten 6–7 of the most popular npm libraries from scratch in LilScript in just 1.5 days-while actually designing the language itself.

Feel free to PR, experiment (Please respect the modified MIT license)

Please share your opinions, would love to discuss about the future direction for the language and the compiler

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

Show us here!

structuredClone() preserves more than JSON, but class instances, proxies, getters, errors, and transferables still have surprising behaviour. This article covers what survives, what changes, and what throws.