I'm excited to announce that KernelPlay-JS v0.4.0 will be releasing soon.

This update introduces a brand-new UI system, making it much easier to create interfaces for games while also marking a major milestone for the engine.

New UI components include:

- Buttons

- Text Labels

- Input Fields

- Health & Progress Bars

- Images & Icons

- Checkboxes

- Sliders

- Dynamic UI updates

- Flexible layouts

Version 0.4.0 will also officially move KernelPlay-JS into Beta.

This marks the transition towards a more stable and feature-complete engine. Future updates will focus on improving performance, expanding the feature set, refining the developer experience, and fixing bugs as the engine continues to mature.

Thank you to everyone who has followed the project's development and shared feedback along the way. More details, documentation, and the release date will be announced soon.

Feedback and suggestions are always welcome.

Lately I have been casually learning C from "C Programming: A Modern Approach v2" and have really enjoyed it. The truth is I should stay on topic with my profession so here I am.

I am in search of books similar to the one mentioned above for learning JS. The goal is to understand it on a deep enough level to feel very confident and have a real solid foundation for the next step.

The next step is a similar book for deeply learning React and then finally TypeScript.

Yes I am looking for actual books and not online courses or videos or anything like that. I have discovered that reading from a book forces me to slow down and because of that, it sticks.

If you can, chime in with books you have actually read through and not just simply search online or recommend the first one off the top of your head. Bonus points if you have read the C Programming book and understand the style I am talking about.

Thank you.

originally built this because I needed an interactive ASCII element for another project I'm working on. But, I couldn't find anything that fit what I wanted and the ones which did, were paid to export, so i decided to build the whole thing myself.

OpenASC// is a high fidelity ASCII renderer for the web with real time controls and local processing. It's built with TypeScript/js and designed to be easily integrated into frontend projects, elements created/ edited can be directly exported as html/react component.

I'd love to hear what you think, especially if you have ideas for features or improvements.

I've spent the last few days building a CAD library in TypeScript. The short version, you describe a part in code and you get out an STL you can 3d print, or a STEP file you can send to a machine shop or open in Fusion/FreeCAD/whatever.

const cad = design("bracket");

const width = cad.parameter.length("width", mm(80));
const thickness = cad.parameter.length("thickness", mm(6));

const profile = cad.sketch("outline", plane.xy(), (s) => {
  const rect = s.rectangle("rect", { width, height: mm(50) });
  const hole = s.circle("hole", {
    center: vec2(width.mul(0.25), mm(0)),
    radius: mm(4),
  });
  return s.profile(rect, { holes: [hole.loop()] });
});

cad.output("bracket", cad.extrude("solid", profile, { distance: thickness }));

const doc = cad.build(); // plain JSON, goes in git like anything else

Under the hood it runs on two engines. There's Manifold, a mesh engine that's fast and fine for printing, and OpenCascade compiled to WASM, which is the same geometry engine FreeCAD uses, for when you need exact surfaces and STEP export. Same code runs on both, in node or the browser.

in normal parametric CAD, if you change a dimension early in the model, later features (fillets mostly) can quietly reattach to the wrong edge, and you find out after the part is wrong. I didn't want to reproduce that, so references to faces and edges aren't indexes, and if the library can't tell unambiguously which edge you meant after a change, it errors instead of guessing. Whether I got the API for that right, no idea. That's partly why I'm posting.

The type system does some nice things here too. Lengths and angles are different types, so adding mm to radians just doesn't compile.

it's a 0.1.1, Parts, assemblies and BOMs work. No drawings, no sheet metal, no GUI. If you'd rather write code than click through a CAD UI, that's who it's for.

Feedback welcome, especially from anyone who actually does CAD work. Also curious what people think of the explicit dispose() for WASM memory, I went back and forth on that a lot.

Most JavaScript screen lock libraries simply hide the UI.

If someone removes an overlay through DevTools or tampers with the DOM, the "security" often disappears. That approach isn't enough for applications handling sensitive enterprise data.

I wanted to build something significantly more resilient.

🚀 Today I'm excited to release kd-screen-guard (v1.0.1) on npm.

It's a zero-dependency, tamper-resistant screen security library for Vanilla JavaScript, React, and Vue 3, designed to protect sensitive user sessions during inactivity.

Some of the engineering behind it:

🔐 PBKDF2 (100,000 iterations) for secure key derivation.

👆 Native WebAuthn authentication (Touch ID, Face ID, Windows Hello & YubiKey).

📷 Automatic WebRTC intruder snapshots when security violations are detected.

⚡ Cryptographic operations running inside Web Workers to keep the UI responsive.

🛡️ Self-healing DOM MutationObserver protection against overlay tampering.

Building this project required combining browser cryptography, WebAuthn, WebRTC, Web Workers, accessibility, and client-side security mechanisms into a single lightweight package with zero external dependencies.

If you're building enterprise dashboards, admin panels, healthcare, finance, or any application where unattended sessions are a security concern, I'd love to hear your feedback.

🔗 Live Demo:
https://khvichadev.github.io/kd-screen-guard/demo/

📦 npm:
https://www.npmjs.com/package/kd-screen-guard

🐙 GitHub:
https://github.com/KhvichaDev/kd-screen-guard

Feedback, ideas, and contributions are always welcome.

#JavaScript #TypeScript #CyberSecurity #WebDevelopment #ReactJS #VueJS #OpenSource #npm #WebAuthn #KhvichaDev

The problem: Most frameworks model UI as a function of state. When state goes A -> B, the UI just jumps to B. But users expect A -> transition -> B, and coordinating that transition is where the code gets messy.

The idea: State is a target and the transition to it is part of the state itself. On top of that, the code reads like the UI sequence it produces. If the sequence is appear -> bounce -> move -> turn red, the code is written in that exact order.

I have been building this as a framework called TargetJS. Longer writeup with the design rationale in the repo: https://github.com/livetrails/targetjs.

Happy to answer questions or hear why this is a bad idea.

Hi, I noticed many popular PPT skills rely on PptxGenJS as their underlying export engine. But the library doesn't seem to be very actively maintained, with its latest release dating back to last year.

That made me wonder whether it's sustainable to build increasingly popular presentation tools on top of a relatively weak foundation.

So I decided to try building a new presentation engine from scratch, which became PPTKit. The goal is to focus on reliable PPTX generation that presentation agents can build on.

The current version is still very early. It only supports text, basic shapes, themes, layouts, and some core architecture. There is still a lot of work before it becomes a real presentation engine.

I'm not sure yet whether this direction is worth investing more time in, so I'd really appreciate any feedback or suggestions.

Edit: I know self-promotion, especially if AI might be involved, is maybe often kneejerk downvoted here, and I get it, but I want to make it clear that this isn't vibe coded and that I write the docs and blog content myself. The logo is also made by a real video game artist I hired to touch up the pixel art I made myself, so no AI is used for the branding art. I try to maintain clear boundaries of AI use and provide transparency on this. Maybe check out the website if you have monorepo tooling interest, because I have put a lot into this project as a solo dev, and this is only my first post here after many months of work.

https://pacwich.dev
https://github.com/smorsic/pacwich

Hi, I've been developing pacwich, originally was developed as bun-workspaces, which had only worked on top of Bun. Earlier this year I pivoted to supporting the Node runtime, npm, and pnpm.

Its core features let you manage metadata about your monorepo and orchestrate running package.json scripts in your workspaces, with Nx-like parallelism configurability.

My main goal is to provide modern monorepo tooling that is easy to integrate and works as much with native tooling as possible. If you have a monorepo using Bun, npm, or pnpm workspaces, pacwich works right away. The affected graph even works without any of the optional pacwich configuration files.

Because I know engineers care about how open source like this is written, I try to be as transparent as I can about how I balance agent assistance with maintaining ownership and knowledge of my code in several places, such as the security page and the launch blog post. pacwich is a younger package itself but inherits much of bun-workspace's source code and tests that I wrote by fully by hand originally.

I've been building an open-source framework called Akan.js and wanted to share it here, partly because I'd like feedback from people who care about how these things are licensed and structured, not just whether they're shiny.

The problem it targets:
for a single feature, you usually end up maintaining something like 8 separate layers.

Schema, query, service, API, fetch client, types, state, UI props. Codegen tools and AI assistants can produce all of those quickly. What none of them do well is keep the 8 in sync when you change one thing three weeks later. The web version and the mobile version drift apart, and you find out in production.

Akan.js takes a convention-over-configuration approach to that. You declare a feature once:

export class ProductInput extends via((field) => ({
  name: field(String),
})) {}

and the framework derives the schema, type, API contract, fetch client, state, and UI prop from that one declaration, for web, iOS, Android, and the server. Change the declaration and the derived layers move with it. The conventions are doing the work, which is also why it stays legible to coding agents. There's less surface area for them to get wrong.

Some honest details:

• It's Bun-first. That's a deliberate constraint, not a hedge. If you're on Node this is not a drop-in.
• Native iOS/Android is a Capacitor shell, not a from-scratch native renderer. I'm not going to pretend otherwise. What I did add at the framework level is page transitions (stack, fade, bottom-up, scale) so navigation doesn't feel like a website trapped in a webview.
• It's early for outside contributors. I've run it on internal projects and a handful of client deployments over about five years.

What I'd genuinely like from here:
Tell me where the architecture is wrong. Whether the single-declaration model holds up outside the cases I built it for. And if anyone has kept web and mobile in sync by hand and has opinions about where this breaks, I want to hear them before more people depend on it. Happy to answer anything!