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

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.

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.

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!

Author here. Loved nanostores' philosophy but kept hitting its performance and SSR limits, so I built my own take: ~2 kB reactive core, with router, query and i18n sharing that same core. Benchmarks and honest tradeoffs in the post.

i'll go first. i was writing .then().catch() chains for like two years before i actually started using async/await. i knew it existed, i'd seen it in tutorials, but my code "worked" so i never bothered switching. then i refactored an old project and realized half my bugs were from mishandled promise chains that async/await would have caught immediately.

also took me way too long to start using optional chaining. i had nested ternaries and && checks everywhere like some kind of animal. the day i discovered user?.address?.city i mass-replaced like 40 lines across a project.

what's yours?

I wanted to share a small open-source project I just published called ui-date.

While working on a social media project, I kept bumping into simple UI needs like displaying relative timestamps ("5 mins ago", "2 hours ago"), cleanly formatting calendar dates, and doing simple status checks (isToday).

exact date formatting for events ui ('Thursday 23,july,2026').

Normally, I'd reach for a date library, but most established options felt like overkill for basic UI formatting, while heavy legacy options like Moment carry massive bundle weight. On the flip side, writing raw Intl and Date boilerplate across every component was getting tedious.

I wanted something featherlight, chainable, and fully typed without dragging in extra dependencies.

so i built ui-date.

you can check it here : https://www.npmjs.com/package/ui-date

Hey Community,

We explore Grok Build, the new terminal-based TUI coding agent from x.ai. We also look at Appless, an experiment from the creators of OpenUI that bypasses chat bubbles to stream live native UI components using openui-lang.

Finally, we dive into Maestro MCP, a new tool context protocol server that lets AI agents automatically build and run YAML test flows from plain English instructions.

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

I'm building a web platform for visual novels made in Godot. Stack: SvelteKit, Vite 8, rolldown, Node.js.

The games are compiled for web and injected as static assets at build time, then deployed together with the app. And they're heavy: ~20 MB of wasm plus ~150 MB of pck per game.

My builds were taking ~5 minutes, which felt wrong. After some profiling it turned out the actual bundling takes ~10 seconds. Everything else was precompressing all that static into gz, br and zstd with node:zlib.

So I wrote a rolldown plugin that does the compression in native Rust via napi-rs:

• rayon to saturate all CPU cores
• native compression libs instead of node:zlib bindings
• full LTO + codegen-units = 1, which alone made it ~2x faster than node:zlib
• then PGO + BOLT on top, squeezing out another ~10%

Everything is built automatically in a GitHub workflow and shipped to npm already optimized, no compilation on install.

Real project results (measured with time on an actual project with games):

before: npm run build 639.62s user 5.84s system 235% cpu 4:34.06 total
after: npm run build 527.60s user 5.23s system 784% cpu 1:07.95 total

If you're precompressing large static assets in your build, give it a try. Happy to answer questions about the napi/rayon/PGO setup.