Unpopular take after years of bolting metrics onto my own js projects: velocity charts, commit counts, bundle-size over time, none of it ever told me the actual shape of a week's work. it's all lagging vanity numbers.

the thing that stuck was hearing the repo's week narrated back to me instead. the commits, the one or two PRs, the issues i opened then forgot about, out loud and in order. turns out my week has a storyline i never catch staring at green squares or a grafana panel.

What actually surprised me was how much of my 'progress' was me quietly undoing decisions i'd made earlier in the same week. you don't notice that reading a diff. you notice it when something walks you through the sequence.

so for anyone maintaining a stack of npm packages or one big app repo, be honest: is your dashboard telling you anything you couldn't already feel, or is it a comfort object. what's the last thing you learned about your own coding habits that no tool actually surfaced.

Built this for myself, sharing in hopes some may find it useful.

Features:

• Reduce supply chain risk with a .npmrc preconfigured with ignore-scripts and min-release-age enabled
• Test without extra tooling using the built-in Node.js test runner
• Run TypeScript directly in Node.js using native type stripping (erasableSyntaxOnly enabled to enforce compatibility)
• ESLint & Prettier preconfigured
• Husky pre-commit configured to lint, format & test
• Strict type checking on run and test
• Pinned dependencies to reduce supply chain risk

The theme for this year's edition is "DREAMING". Good luck!

I know this is not the subreddit for C language, but i have learned a bit of C and if I could try to relate and try to make things click as if some "concepts" were similar, then it would most likely make me understand faster and much better. Please understand me from where I'm at because I'm really struggling to understand the heap stack and stuff and copying by reference, so I'll start.

Note: I did many research on this and I have concluded that I am correct, but I would really wanna be sure if my understanding is correct and I would like to be corrected if what I think is wrong or right, hence the reason why I am posting this. Also, I am self studying and not enrolled in a school, no programming friends, so I have literally no one to confirm with. I just want to be confident that I understand what I learned, so please bare with me, thank you. Would be much better to reply this if you have some understanding on how pointers work in C, but will try to reiterate here.

1.) Pointers in C are basically special variables. Variables have their own memory addresses, so that doesnt excempt pointers from having one. Both normal variables and pointers have their own memory addresses. So the gimmick of pointers is that they refer (or point) to the memory address of the variable they are assigned. Basically, you assign a variable towards a pointer variable, and once you call that pointer variable, what pops up is the memory address of the variable it is assigned to.

2.) My understanding of copying by reference (this refers to objects, not primitives. primitives are copying by value) is similar to this, where a variable has its own memory address, and the memory address it holds ALSO refers to the memory address of the object. is this how it works?

e.g.

let person = {
name: "Joanna",
age: 18,
height: "195cm"
};

What's happening here is that person variable holds a memory address (say 0x100) and the object {...} has its own memory address too. (say 0x7ff...). 0x7ff...(object's memory address) is sitting at 0x100 (person variable's memory address) so basically we can conclude that person variable is referencing to 0x7ff... right?

Unlike copy by value where you do e.g.

let age = 18;

What happens here is that age has its own memory address (say 0x101) and the value 18 is represented by bits (say 10001 1010101 10001) and sits directly on the memory address of the variable.

Conclusion: In my understanding, they're similar to a point that they generally point or refer to something. For pointers in C, the pointer points to a memory address of a variable, while in JS, the normal variable points or refers to a memory address of the object (there are no pointers in JS, i'm just saying generally speaking they are atleast referencing a memory address)

Final question: are all of my understandings correct? Thank you for your patience with this one. I know i shouldn't be in too deep as a beginner but I genuinely want to learn the difference between copy by reference and copy by value. (please note i am not talking about pass by reference, but copy by reference.) Thank you once again!

Hello all, please dont be harsh with me cause I'm really new with JS. Doing free code camp right now and I am just wondering if destructuring assignments are often used. e.g.

I come from C and really the amount of syntax in this language is just overwhelming, is this normal when learning JS? when does this end T_T

const person = {
  name: "Bob",
  age: 25,
  job: "Designer",
  city: "New York"
};


const { job, city, ...remainingProperties } = person;


// { name: "Bob", age: 25 }
console.log(remainingProperties);

It's really hard for me to remember all these syntax to be honest so I'm not sure if its wraps for me in this language. I got so used to syntax where every variable is declared 1 by 1. Here are the questions once again to be organized:

1. is it just me or the amount of syntax in this language is just overwhelming like its just so many, is this normal when learning JS?
2. can I opt to not use it? or should I get used to it starting from now since it will really be beneficial?
3. Like how important it is that it must it be used? is it treated like an "alternative" way of a syntax or is it really required? I really dont get the importance of it. Yes I get it cuts off multiple lines of code, but wouldn't you have a better readability, which makes you able to trace which properties are assigned or whatever rather than having a super concise syntax whilst remembering that "oh, this goes through here"
4. I've searched all over the net and people say they like it for readability and conciseness, however i really dont see it being readable at all, i mean it is but it makes my brain lag for like a minute or two. Readability is usually defined by lesser time for you to have to read the specific line of code right? If it really is readable as they say, then is this something like a skill issue and I have to just get used to it?
5. I know this topic is usually about destructuring assignments, but I felt this emotion towards arrow functions too. Like are arrow functions just "alternatives" or at some point I must be required to learn it? I really feel comfortable with making normal functions rather than arrow functions to be honest.

Thank you all! Please dont give me remarks like "Just give up if you can't do the learning" cause that's what I'm here for, Im asking for genuine advice and looking to see if what I feel is normal. Thank you once again.

Hey Community,

We look at Rollipop, an early alpha, Rust-based bundler built on Rolldown that acts as a drop-in replacement for React Native, bringing standard Node module resolution, Yarn PnP, and a live visual dashboard.

We also explore expo-paperkit, an Expo native module wrapping Apple's PaperKit drawing and annotation canvas. Plus, we dive into PolyCSS, a clever web tool that renders 3D meshes using HTML bold and underline tags instead of WebGL or canvas.

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

I've been learning Rust for a while and wanted a real project to work onand i noticed that glob matching sits on the hot path of pretty much every JS bundler and file watcher, and picomatch is the go to library for that. It works great but it compiles patterns into regexes and leans on V8, which made me wonder if I could try a different approach in Rust.

So I built zeromatch. Instead of regexes it uses a small bytecode VM with fast paths for common patterns. The API is compatible with picomatch so you can mostly swap it in without changing code. It also supports matching directly against Buffers which avoids string conversion if you're working with raw fs output.

In benchmarks, one shot matching (compile + match once) is roughly 2x faster. For cached single matches picomatch still wins because of the FFI overhead crossing into native code. So it's not a "better in every case" thing, it depends on your workload.

Honestly this was mainly a learning project for me. I wanted to get more comfortable with Rust and napi-rs and this felt like a good excuse. It's at a point where it works and I'm using it, so figured I'd share it in case anyone finds it useful or has feedback.

Would love to hear thoughts, especially if you try it and hit patterns that don't work right.

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