I just published a blog post to my website about a pattern I've been using for a while that I think you will find interesting (and probably very divisive!): Magic Objects.

class Parrot extends MagicObject {
    __get(property) {
        return `${property}! ${property}!`;
    }
}

const parrot = new Parrot();

console.log(parrot.foo); // "foo! foo!"
console.log(parrot.bar); // "bar! bar!"

Basically, I'm borrowing the idea of Magic Methods from PHP and porting them to JavaScript. You've probably seen something like this done with proxies before, but I still like to use some OOP in my JavaScript, and I also came up with a way to make it work nicely with TypeScript.

It may seem a bit over the top at the beginning, but I've been using this for a while and I've found it very useful.

Let me know what you think!

Places.js is a lightweight Javascript framework for creating interactive websites promoting in person interaction. The framework supports the following features and has no external JS dependencies.

• Asynchronous data fetching.
• Components with Shadow DOM to encapsulate styles and deter bot scraping.
• State management that integrates with components and data fetching logic.
• Support for creating pages that are a combination of static HTML and islands of interactivity.

To get started, download the places-js-latest.js file from this repo. See the places.js documentation at https://createthirdplaces.org/tech/placesjs.html for a more detailed guide

• This repo has an example of how places.js is used.
• This website has shows how places.js is used in a production environment

Monday, July 06 - Sunday, July 12, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

Hey Community,

Meta has open-sourced Astryx, an eight-year-old internal design system built on StyleX that offers out-of-the-box themes, context-aware padding, and dedicated CLI tools for AI agents. We also look at super-calendar, a gesture-driven calendar library that leverages Reanimated shared values and Legend List virtualisation.

Speaking of agents, our sponsor Maestro is pushing that idea further: your coding agent can now launch the app, drive an iOS simulator, Android emulator, or Android physical device, inspect the screen hierarchy, tap through flows, take screenshots, and help create repeatable Maestro E2E tests.

Additionally, Android developers get a dedicated on-device AI solution with Callstack's new react-native-ai adk wrapper, enabling seamless integration with the Vercel AI SDK and local Gemini Nano models on the New Architecture.

Theres been a lot of talk about the downsides of barrel files in the last couple years with many people actively recommending against using them due to the effect they can have on treeshaking. I am wondering though if there is an alternative solution in the ecosystem to enforce/define boundaries on slices/domains?

I've seen it said they often cause circular dependencies but in my experience its the opposite. The main and pretty much only way I use barrel files are to enforce boundries on slices of cohesive logic, sometimes going so far as to enforce it in the linter with custom rules. Code inside the slice never imports from its own barrel. Each slice kind of defines its own code API in a way and feel like this lets me control the coupling between slices alot better.

I am struggling to justify letting that go and the only alternative I can think of is using a monorepo and having them all as packages which is just not an option for me in many cases and also not one I particularly like.

Are barrel files really that bad?

Over the last few months, an experimental JavaScript runtime has been in development, built on top of Mozilla's SpiderMonkey, as a way to dig into how JavaScript engines and runtimes work internally.

One thing that stands out while building it is the separation between the JavaScript engine and the runtime.

JavaScript (more formally, ECMAScript) is just a language specification. Engines like V8, JavaScriptCore, and SpiderMonkey execute JavaScript, but they don't define things like:

• setTimeout()
• setInterval()
• fetch()
• console
• Workers
• File system APIs
• Process APIs

Those come from the runtime built around the engine.

That raises a question worth putting to the community.

Most modern runtimes are built around APIs that have evolved over many years. Browsers expose Web APIs, while server runtimes expose things like file systems, networking, streams, and processes.

If JavaScript were being designed today, without worrying about backwards compatibility — what APIs should every JavaScript runtime have by default?

For example:

• Better concurrency primitives?
• Structured task scheduling?
• Actor-style APIs?
• Built-in channels?
• First-class cancellation?
• Better binary data APIs?
• A different file system API?
• Better networking primitives?
• New async abstractions?
• Something completely different?

Are there APIs in use today that feel outdated? Are there APIs that should never have existed? Or APIs from other languages worth having in JavaScript runtimes?

Not necessarily about browser APIs specifically — more about what an ideal JavaScript runtime would look like if designed from scratch today.

Different perspectives are welcome from anyone who's worked with Node.js, Deno, Bun, browsers, or other languages.

The project is open source — link in comments for anyone interested in following along

Being a Laravel developer for almost 10 years, when switched to Node.js I missed the simplicity of FilamentPHP , thats why I stared building KratosJs.

KratosJS is the full-stack admin panel framework for Node.js. Its core is HTTP-framework agnostic — official adapters ship for Express, Fastify, Koa, Hapi and NestJS, and you can write your own for any framework.

Features:

- Customizable

Create custom pages, widgets, fields, columns etc.

- Internationalization

Full i18n support out of the box. Register multiple translation locales, format plurals, and localize panels seamlessly.

- CLI scaffolding

Generate panels, resources and plugins from the command line and start building immediately.

- Plugin system

Drop in entities, resources, routes, widgets and hooks. Ship reusable features as packages.

- Slots

Slots are named injection points in the admin panel UI where you — or a plugin — can render your own React elements.

- Lifecycle hooks

before/after create, update, delete, validate and custom actions — stackable and type-safe.

If you've ever run a Node service with a big in-process cache (tens of thousands of entries, JSON blobs, that kind of thing) you've probably seen p99 latency spike during V8 garbage collection — the more live objects sit in the heap, the longer mark-sweep takes, and there's not much you can do about it from JS land since the GC doesn't know your cache entries are "just cache" and safe to deprioritize.

I built OffHeap to get around this: it's a cache that stores its data outside the V8 heap entirely (native memory managed from a small Rust layer via NAPI-RS), so the objects never show up in V8's GC graph at all. The JS-facing API is a normal cache — get/set/delete/TTL — with LRU, ARC, and W-TinyLFU eviction policies to choose from.

Under a synthetic GC-pressure test (500k keys, 1M ops), the worst single GC stop-the-world pause dropped from ~300ms (plain in-heap cache) to ~11ms. Average per-op latency is a bit higher than a pure in-heap Map (it's crossing an FFI boundary, that's not free), but the tail latency and memory behavior under load is the whole point.

It's on npm (`offheap`), dual-licensed MIT/Apache-2.0, docs at the repo. Full disclosure, this is my project — I actually shipped a broken cross-platform install for a bit (CI wasn't publishing the per-platform binaries correctly) and just fixed that, so if anyone tries it and hits install issues, please tell me. Genuinely looking for people to poke holes in it before I call it stable.

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

Show us here!

We took a look back at the history of JavaScript to explore its development from the earliest days to the present. This retrospective article is a good read for novice JavaScript enthusiasts who want to learn about the origins of the language, as well as for experienced ones who'd like to refresh their memories.

The Ask

Padding Line Between Statements rule is currently missing in Biome.js; it'd be a solid addition to the tooling.

If you're already using Biome and think this rule would be useful for keeping your code readable, consider giving it an upvote. Every bit of community support helps move features like this forward.

Why It Matters

The rule enforces blank lines between logical statement groups, which can make codebases feel less cluttered and easier to scan. It functions as follows:

// eslint.config.js

{
    "padding-line-between-statements": [
        "error",
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        ...
    ]
}

// index.js

function foo1() {
  var a = 0;
  bar(); // ! Incorrect
}

function foo1() {
  var a = 0;

  bar(); // * Correct
}

You run npm run dev or node server.js, and the app crashes because a teammate added a new required key to .env.example but forgot to tell you.

I wanted a tool that would catch this before startup, prompt me for the missing values, and append them without wiping out my .env formatting or comments. Since existing tools either crash on startup (dotenv-safe) or wipe out file layout (sync-dotenv).

To solve this, I built envrepair, a zero-dependency CLI tool that wraps your startup command, compares .env against your template, and interactively prompts you to fill in missing variables in the terminal before launching your process.

How to use it:

1. Install: bash npm install -D envrepair

2. Prepend your startup command in package.json: json "scripts": { "start": "envrepair node server.js" }

Optional type annotations in .env.example: ```env

@type number

PORT=3000

@type url

API_BASE_URL= ```

Key Features:

• Zero code changes: No schema imports or application-level setup required.
• Layout preservation: Appends missing values while keeping comments, blank lines, and formatting intact.
• Signal forwarding: Transparently passes Ctrl+C (SIGINT) and exit codes.

Written in TypeScript with zero runtime dependencies. The repo is fully open-source.

• GitHub: https://github.com/avenolazo/envrepair
• NPM: https://www.npmjs.com/package/envrepair

// the only state that needs tracking for a timeline, the read index
export function Timeline(index) {
    let state = {index};
    return {
        index: state.index, // pass through
        next: (events) => Next(state, events),
        prev: (events) => Prev(state, events)
    };
}

// the events are just passed around. They don't need to be encapsulated
export function Next(timeline, events) {
    let {index} = timeline;
    if(index === events.length()){
        return null;
    }
    timeline.index += 1;
    return events[timeline.index];
}

export function Prev(timeline, events){
    let {index} = timeline;
    if(index === 0){
        return null;
    }
    timeline.index -= 1;
    return events[timeline.index];
}

// before and after don't modify the state of their arguments
// so we don't use encapsulation

export function After(date, events){
    for(let thresholdIndex = 0; thresholdIndex < events.length(); thresholdIndex+=1 ){
        if( events[thresholdIndex].timestamp > date) {
            return events.slice(start=thresholdIndex);
        }
    }
    return [];
}
export function Before(date, events) {
    for(let thresholdIndex = events.length(); thresholdIndex >= 0; thresholdIndex-=1 ){
        if( events[thresholdIndex].timestamp < date) {
            return events.slice(end=thresholdIndex);
        }
    }
    return [];
}

I'm looking for a datepicker for a vanilla JS project, and somehow this seems much harder than it should be.

No, input masks aren't enough.
No, the native <input type="date"> isn't enough either.

My checklist:

• Accessible
• Localized
• Flexible formatting options
• Range picker support
• A decent set of events/hooks for integration

What I've looked at so far:

• flatpickr: hasn't been updated in about 4 years
• vanilla-js-datepicker: hasn't been updated in about 3 years, and the range functionality is pretty weak
• Vanilla Calendar Pro: Russian-maintained, which is ruled out by our dependency policy
• Air Datepicker: same issue, and it also hasn't been updated in about a year
• Litepicker: dead
• Easepick: dead

Most of the other options I've found are React-based, which is a non-starter for this project.

Am I missing something, or are there really no good options left?

TypeScript 7 dropped this week and my first move was the same as always. Open the release notes, skim, tell myself I'll come back to it. I didn't.

so as an experiment i started piping the changelogs for the libraries i actually use into a text-to-speech thing and listening on the walk to work, figured audio would make it stick. the surprising part wasn't whether it worked, it's what it exposed. most release notes are mostly housekeeping wrapped around the couple of lines that actually change how you write code, and you only feel how thin the signal is once a flat voice reads every bullet out loud. on a screen i'd been auto-skimming the filler for years and calling that keeping up.

so the thing that actually broke wasn't the audio, it was that i never had a filter for what in a release is worth remembering. what's the last js or ts release that genuinely changed how you write code day to day, versus the ten you 'read' and can't quote a line from. written with ai

Simple Release automates the whole release from Conventional Commits: version bumps, changelogs, publishing, GitHub releases. Monorepos supported, GitHub Action included.

What's new in v3:

- Snapshot releases: publish the current state of any branch as a temporary version under its own npm tag

- Maintenance branches: keep releasing fixes for previous major versions under the "release-N.x" tag

- A new addon for releasing GitHub Actions written in JavaScript: releases are published as built git refs ("latest" and "v2" branches, version tags) instead of npm

- An agent skill that sets up the release automation in your repository for you

To count unique visitors you have to recognise a returning browser. There are only ~5 ways, and each breaks differently:

1. Cookies. Work, but need a consent banner, and Safari caps script-set cookies at 7 days anyway.

2. localStorage. Same law, same banner. ePrivacy covers "storing information on the device", not just cookies.

3. Fingerprinting. Durable and invisible, which is why regulators treat it the same and browsers sabotage it.

4. Daily hash. What Plausible, Fathom and GoatCounter converged on: hash(daily_salt + site + ip + ua), salt rotated and deleted every 24h. No banner, accurate daily uniques.

5. Don't count uniques at all.

The under-discussed part is what option 4 costs. There are no cross-day uniques: "weekly visitors" is just seven daily counts summed, so a daily visitor counts 7 times. CGNAT merges thousands of mobile users into one visitor. A browser update splits one person into two. And the hash is pseudonymous, not anonymous, so it's still in GDPR scope.

Every "privacy-friendly" tool reports weekly uniques as a sum of dailies and none of them put an asterisk on it. Curious if that bothers anyone else.

Guides for getting started with Conventional Commits, CLI and JS API references for all packages, presets, and recipes.

Also from the recent updates: dropped Handlebars from the dependencies (the conventional-changelog package got 7x lighter) and added an agent skill that teaches AI agents to write proper Conventional Commit messages.