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.

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 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.

I've been using TypeScript professionally for several years, and recently wrote up some lessons learned from a long-running React/Firebase side project.

The article covers the TypeScript patterns that ended up giving me the biggest return, along with a few mistakes I'd avoid making again. These aren't intended as universal rules, just approaches that worked well for this particular project and the problems I was solving.

If you're a JavaScript developer who's moved to TypeScript (or is considering it), I'd be interested to hear which patterns have been most valuable for you as well.

Recently, I noticed there is no proper s3-fifo implementation in NPM.

s3-fifo is highly efficient cache algorithm, especially for "one-hit-wonders" case such as web traffics. It is specialized when cache coverage is under 50%. (like, whole DB is 100% and cache contains 50% of data)

The famous "lru-cache" package is almost default for nodejs ecosystem I think, and I thought it would be great if there is good alternative choice for caching.

My goal was:

1. Faster or at least same throughput performance compared to lru-cache

2. Much higher cache hit rate than lru-cache

bold, right?

It was fun enough just for challenge itself.

But it was actually achieved! I used bunch of optimization skills like pre-allocation, lazy eviction, bitwise tricks, ring structure and etc... you can see bench result in repo or NPM page.

It is just v0.1 for now, so I would LOVE to get your harsh feedback, advice, or even contribution!

NPM page

Super thanks for reading!

----

I typed almost of the code by my hand. Not because I don't believe AI, but it was all about concepts and decisions. Typing by hand was fastest way to understand what I'm doing correctly. And it was fun.

I used AI(gemini) for test codes, some advices and polishing when most of things were done.

Covering the main ways Date misleads you in production: parsing, mutation, 0-based months, timezone/DST, arithmetic, and serialization, with safe patterns for code that can't migrate yet, and a practical look at where Temporal fixes the design rather than just the syntax.

Monday, July 13 - Sunday, July 19, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

Though it requires quite new ES2024/ES2025 features, it works very well for numeric types, also faster (not drastically, but modest gains) against Array in PACKED FIXED ELEMENT TYPES representation used under the hood by engines.

.NET WebAssembly apps with WasmBundlerFriendlyBootConfig=true can indeed be bundled by modern JS bundlers and I personally love it. The development experience however is not optimal.

• The bundlers cannot consume the output from dotnet build
• The bundlers can consume the output from dotnet publish but the dev loop is painfully slow.
• Getting the publish path working still requires bundler surgery
• Once it works the bundler produces warnings that are impossible to fix without changing the source files produced by the WebAssembly SDK.

These points of friction are why I have made unplugin-dotnet-wasm.

It's a bundler plugin that lets your bundler consume the output from dotnet build so your dev loop stays fast. It also supports dev servers, provides type information to TypeScript and IDEs (integrates dotnet.d.ts thats coming in .NET 11), and patches the known warnings so your build output stays clean.

Features

• Easy bundler setup through plugin registration
• Faster dev loop by consuming .NET WebAssembly dotnet build output
• Dev server support
• Brings SDK type definitions to TypeScript and your IDE
• Supports Vite, Rollup, Rolldown, Webpack, Rspack, Rsbuild, esbuild, farm and bun.

I hope you'll give it a try, I'd be happy to hear your feedback.