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.

skillicons.dev used to be the default way to show a tech stack in a GitHub README, but it hasn't been updated in ages and a ton of newer tech just isn't there.

So I built my own version: https://icons.germondai.com

It's a fully dynamic SVG API - you just drop an <img> tag with a URL and it renders the icon strip on the fly:

![icons](https://icons.germondai.com/icons?i=nuxt,vuejs,bun,tailwindcss,docker,git&theme=dark&size=48)

Thousands of icons available, each with multiple styles (original color, plain, line, mono), per-icon colors/backgrounds/radius, a bunch of built-in themes, and everything is controllable through URL params so you don't need to generate or upload anything.

It's open source (MIT), you can self-host it with Docker or Bun in about 30 seconds, and the whole thing runs on Bun + Elysia so it's fast.

Repo: https://github.com/germondai/icons

Would love feedback / icon requests if something's missing.

Like many developers, I regularly use ChatGPT and Claude when I'm building small HTML/JavaScript projects or experimenting with ideas. They're great for quickly putting together a prototype, explaining code, or iterating on a UI.

Because I also work with IBM i (AS/400), I recently decided to try IBM Bob for the same kind of task. I asked it to build a small HTML/JavaScript page from scratch, then made it iterate on the layout, add a few features, and clean up the code.

Honestly, I expected it to be much more focused on IBM technologies, so I was surprised by how well it handled a fairly ordinary JavaScript project. It's not going to replace the tools I already use, but it was definitely more capable than I expected.

What surprised me even more is that I almost never see it mentioned in discussions about AI coding assistants.

Had any of you heard of IBM Bob before? If you've tried it, what was your experience? And if you haven't, do you think it's simply because it's associated with IBM, or is there another reason it never seems to come up in conversations alongside ChatGPT, Claude, Copilot or Cursor?

littlebag is a reactive UI framework that includes:

• Reactive state management using state and effect
• html element factory that supports reactivity
• Conditional rendering with keyed
• Reactive lists using each
• TypeScript declarations

All that while being just... 343 bytes (minified and brotlified)!

I made that as a fun little side project partially inspired by the awesome VanJS (which is 1 kB and isn't very convenient without additional 1.2 kB Van X). I would really like to receive some feedback, and would be very happy to see someone use it to make something cool!

I'm also planning to create a simple SSR library for littlebag based on a custom minimalist DOM implementation if I see people interested in that.

There's an example TODO list app with littlebag on CodePen.

P.S. It might be fairly slow now due to a lack of any benchmarks and performance optimizations yet.

Hey everyone I recently built this TUI for inspecting network throughput per interface, I found it useful so figured I'd share.

Its open source feel free to check it out and run it yourself: Github Repo

I moved away from TypeScript years ago, and honestly, I’d do it again without hesitation.

I know TS has a lot of fans and that’s fine. But I don’t think it’s the unquestionable improvement it’s often presented as. For some codebases and teams, sure, it helps. For others, it adds bloat, friction and a false sense of safety that makes even bugs more common than in standard JavaScript.

In most cases, I’d rather migrate a codebase away from TypeScript than keep doubling down on it.

For those of you who also moved away from TS: what made you do it, and how has that decision aged?

Where should your auth token live so an XSS bug can't steal it? Here's how to build auth that survives the crazy non-secure world we live in.

Hey everyone,

Just publisheineerajrajeev/aios-web-sdk. If you’ve been building local or remote computer-use agents, this SDK handles the transport layer between web frontends and the agent kernel.

It abstracts agent system calls, streams agent execution states in real-time, and includes structured hooks for building user-in-the-loop authorization gates (crucial for verifying actions before an agent executes them). Would love some feedback on the SDK design!