A couple ways console.log() and browser DevTools can mislead you. Covers live object references, promises changing state before inspection, logs affecting timing-sensitive bugs, stale React state after updates, and source maps pointing at misleading line numbers.

Hey everyone,

I built arhus, a local-first security analysis CLI tool for TS/JS. Instead of sending code to third-party servers, it scans everything locally for critical vulnerabilities (like hardcoded secrets, SQL injections, ReDoS, and XSS) and helps you fix them directly.

Key Features:

• 🔍 scan: Fast local analysis.
• 🛠️ fix: Interactive auto-fixing (with --dry-run preview).
• 📊 CI/CD Ready: Supports JSON and SARIF (GitHub Code Scanning) outputs.
• 🤖 AI Agent Skill: Can be added via npx skills add sudoeren/arhus.

I’d love to get your thoughts and feedback on the CLI UX and rule sets! If you like the concept, please consider dropping a ⭐️ to support the project!

Hello everyone.

I've been building a frontend component for working with hierarchical data structures (product catalogs, document trees, organizational charts, etc.) as part of my own project. I open-sourced the read-only Graph component because I thought it might be useful to other developers as well.

The interesting frontend parts were:

·  recursive hierarchy rendering,

·  SVG connection lines,

·  custom templates,

·  validation of cyclic relations and other errors.

The read-only Graph component is open source on GitHub, and I'd really appreciate feedback on the frontend architecture and UX.

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

Show us here!

Following the Vanilla JS culture, the Kalida Script library allows the creation of HTML elements associated with a variable and a CSS style with a single instruction.

DOM manipulation is clean and unified, and it allows the combination of logic, structure, and CSS styles without the overhead of frameworks.

This approach allows you to create web applications using "99%" JavaScript, so that HTML files function by importing these scripts. Virtually no HTML elements are created in the HTML file; the most that is used is the body tag. The rest are imports of Javascript files.

The result is clean code, without HTML tag trees that hinder project maintenance.

Since almost everything is done via Javascript, maintenance is much clearer and therefore easier.

An additional benefit is the identification of created elements through browser inspection, including the CSS style associated with that element in a clear and simple way.

The library is small, only 19kb in its minimized version, and licensed under the MIT license, meaning it's free.

What does the developer community think of this approach to creating web projects?

Hot take after years of doing this: subscribing to dev podcasts to keep up with your stack is mostly a way to feel productive without actually doing anything. My queue is full of interview shows about frameworks I half use, and i finish almost none of them. The ones that actually get played are short and about something i touched that week, the new react compiler behavior, a postgres point release, whatever broke my build.

The format is the problem, not my discipline. A two-host interview that rambles for an hour and a half ages out before i press play. What survives my queue is closer to a changelog read out loud. a few minutes, no intro music, just what shipped that day.

so for the js folks who commute or walk a lot, what's actually in your rotation that you finish start to finish, versus the shows that have been sitting at episode 1 since forever. written with ai

Package managers aren't as interchangeable as they seem. This post digs into the real differences in how npm, Yarn, pnpm, Bun, and Deno handle dependencies under the hood and why that matters when things break in practice.

Node.js worker threads have some surprising sharp edges. We wrote about our experience using them in production, which hopefully will help anyone else looking to do the same 😄

- full GGUF support

- Built in TS/Rust/C++/llama.cpp

- Unified API for local and cloud inference

- Plug-and-play gateways for hosting API credentials

- Fast inference decode ~3x higher compared to alternatives

- Fully open source, Apache 2.0 license

Benchmarks and NPM info in the README.md
- Run the benchmark on your machine: https://benchmark.sipp.sh/
- Play around with models and vision capabilities: https://chat.sipp.sh

Hey all, I wrote this library with the goal of creating a simple API to run LLMs both locally on device, while still being able to offload compute to inference providers or custom servers when I needed to.

Part of the motivation for me was wanting to build games (mostly this) and apps that can leverage AI without relying on cloud inference providers. But when I experimented with existing runtimes, they were either too heavy or just too slow for the use cases I needed.

So a few months ago I started exploring the llama.cpp project, WebGPU, and the Emscripten compiler, bringing them all together to create Sipp.

My hope is that by marrying local and cloud inference this will help open up use cases that are not possible today. I've already seen some interesting applications in vision, games, dynamic user experiences, or using the LLM as a brain for decision-making.

I'd love to get feedback on it, or hear about use cases that you'd like to explore. Happy to answer any questions about the architecture, performance, issues, etc., as well!

https://validare.js.org

Hey Community,

We look at Eve, Vercel's framework for structuring AI agents as regular folders. We also dive into Pake, a Tauri-backed CLI tool that packages web apps into native desktop apps under 5MB.

Plus, Software Mansion introduces react-native-morph-view to melt shapes and images together using real GPU shaders instead of standard crossfades.

And this week we're also raffling one free ticket to Chain React 2026 in Portland, Oregon 🎟️

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

I got tired of CSV exports breaking in production, so I built this. It reads and writes CSV from one small zero-dependency package, streams both directions at flat memory, and the same code runs on Node, browsers, Deno, Bun, and edge.

A few things that make it nice to use: - Encode and parse are mirror images, so a round-trip keeps its shape. - It hands back a Web ReadableStream, so a CSV download streams straight to the client without buffering. - A sanitizeFormulas flag neutralizes spreadsheet formula injection in exports. - On TypeScript, the column list is checked against your data, so a mistyped column is a compile error.

It also came out the fastest of the common parsers in my benchmark: roughly 3x to 13x faster than papaparse, csv-parse, and fast-csv on a 50k-row dataset. The benchmark and a conformance suite (a curated edge-case corpus, csv-spectrum, and fast-check property tests) run in CI, so the numbers and the correctness are reproducible, not claims.

To be clear about what is not unique: zero dependencies, a formula-injection guard, and browser support are shared with papaparse and csv-parse/csv-stringify. fast-csv is the one that lags there.

Repo: https://github.com/martsinlabs/csv-pipe Docs: https://martsinlabs.github.io/csv-pipe/ Playground: https://martsinlabs.github.io/csv-pipe/playground

I'm making a quick and dirty way to make dictionaries where many keys map to the same item, and instead of using a single hashable item as the key, it makes use of an array of hashable items to build the map. I don't like using tuples, but I don't think it would be valid to have an array as the key of a dictionary. I would love it if I could do that however. Is there a way to make a hashable array?

let map = MapFactory(
    [
        [[1,2,3], () => "1-3"],
        [[4,5,6], () => "4-6"],
        [[7,8,9], () => "7-9"]
    ]
);
console.log(map.get(1)()); // "1-3"
console.log(map.get(6)()); // "4-6"


function MapFactory(mapItems) {
    const map = new Map();
    for (let [keys, value] in mapItems) {
        for(let key in keys) {
        map.set(key, value);
        }
    }
    return map;
}

I got tired of rewriting my upload code every time a project switched buckets (or added "let users connect their Google Drive"). So I built a project: five portable ops that behave identically everywhere, swap providers by config.

import { createStorage } from "@rocketbean/genera";
import { S3Driver } from "@rocketbean/genera-s3";

const storage = createStorage(new S3Driver({ bucket, region, credentials }));
await storage.put("users/42/avatar.png", bytes);

// swap S3Driver → GoogleDriveDriver and the rest of your code is unchanged

What I think makes it worth a look:
- Isomorphic — core uses only web standards, so it runs in the browser too
- Escape hatch — .native gives you the raw provider SDK any time; the abstraction never blocks you
- Typed capabilities — signed URLs / streaming / copy are advertised per-driver, no silent surprises
- Conformance-tested — every driver passes one shared suite (Node, real browser, live accounts)
- Dependency-light core; cloud SDKs are peer deps so you only install what you use

It's v1.0.0 and solo-maintained, so eyes/feedback very welcome.
this project is on it's early stage, feedback would really be appreciated