There are a number of serialization libraries that outperform JSON in NodeJS.

It's important to avoid generating extraneous garbage when doing these kinds of benchmarks.

It's important to provide an appropriately sized buffer when performing serialization.

If you care about serialization performance, consider using a different programming language with better tradeoffs.

In contrast to the frozen NPM package pages, npmx delivers some improvments:

• Transitive install size (similar to bundlephobia or packagephobia)
• Install script disclosure: any preinstall, install or postinstall script is rendered on the package page along with the npx
• outdated and vulnerable dependency trees
• version range resolution
• module replacement suggestions for features that become built-in ECMAScript. The dataset comes from https://github.com/es-tooling/module-replacements
• module format and types badges: ESM, CJS, both. Typescript types, node engine range
• Multi-forge repository stats instead of GitHub only
• cross-registry availability: npm, JSR
• side-by-side package comparison
• version diffing between two versions of the same package
• release timeline with size annotations: Every version of a package is plotted on a timeline with markers where install size jumped by a meaningful percentage
• download distribution by version (avoid download breaks with major versions)
• command palette
• i18n
• accessibility as default
• agent skill detection
• social features on AT Protocol
• Local-CLI admin connecter
• dark mode and custom palettes

An alternative to the frozen NPM which delivers more useful informations per package

JavaScript Patterns Patterns focused on plain Javascript and Node.js

A great FAQs. CommonJS and ESM is still a mess, especially. Yes I am looking at you NestJS.

Topics covered:
How can I move my CommonJS project to ESM?
Can I import ESM packages in my TypeScript project?
How can I make my TypeScript project output ESM?
How can I import ESM in Electron?
I'm having problems with ESM and Jest

Some CSS variables are computed in JS, and the rest is made by CSS and the browser. Each item is a <div>:

<div class="wall" style="
  --start-x: 2560;
  --start-y: -2112;
  --end-x: 2560;
  --end-y: -2496;
  --floor-z: 32;
  --ceiling-z: 88;
">

All the geometry calculation is made in the browser.

JavaScript passes raw DOOM data in. CSS does the trigonometry.
JavaScript runs the game loop. CSS does the rendering.

See https://npmx.dev/

The yearly survey about Javascript (features, libraries, tools, usage, resources, demographics)

Great utils

The author creates a project to gather statistics about the top most starred projects on Github or the most downloaded packages on NPM.

1. 9-27% of JS/TS projects declare themselves to be ES Modules
2. Less than 6% of JS/TS files declare that they are ES Modules via the .mjs, .cjs or .mts file extensions.

Some ideas:

1. kill .mjs, .cjs and .mts should be replaced by the type="module" in package.json. Let's stick to .js, .jsx, .ts and .tsx
2. Make type="module" the default and warns when the type is not set to module.
3. We should upgrade the most common libraries used by the community to ES Modules
4. The NPM registry can require an explicit module field on new packages, making it clear when a package intentionally uses CommonJS.
5. NodeJS can officially drop support for require and module.exports in a future version, creating a bit more pressure to migrate.

The JS Date object is not consistent: there are quirks with its constructor, the JS date is a time object, no sense of time zones beyond one and GMT, absence of daylight savings time, a need for third-party library that is a performance drain. "My problem with Date is that using it means deviating from the fundamental nature of time itself."

The Time is a location in the flow of which events occurs.
Date represents a (readable for human) time

The date object is itself mutable, so it's ok to set a day in place. It can cause unintended side-effects in codebases.

So Temporal comes in. it's a namespace object like Math. There are multiple useful functions, but another magic is in the prototype chain: equals, add, inLeapYear, monthCode.

First, there are plenty of methods and properties devoted to access, format and manipulate the details of the temporal object.
Secondly, "none of these transformations required us to manually spin up any new objects, and that the value of the object referenced by nowTemporal remains unchanged."

Using temporal reduce the boilerplate so much!
Temporal.Now.plainDateISO().add({ days: 1 })

Also Temporal have some time for experimentation.

The permission system should handle folders and files.

Strategies:

1. (naive) read-time permission queries
2. A simple table (RBAC role based access control).

-- RBAC: Pre-computed permissions
-- access_type: 'owner' (full control), 'shared' (read only), 'path_only' (visible but no access)
CREATE TABLE permissions (
  user_id INTEGER NOT NULL,
  resource_id INTEGER NOT NULL,
  access_type TEXT NOT NULL,
  PRIMARY KEY (user_id, resource_id),
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (resource_id) REFERENCES resources(id)
);

3. Attribute-Based Access Control

This approach is very clear and composable. It works great for single-resource access checks: "can user X access resource Y?" It struggles when listing resources, as we would need to execute the policies for each resource and can't directly query the resources table with simple filters.

4. Zanzibar and ReBAC

Unobtrusive logging for modern javascript

Zero dependencies. Universal runtime. Optimized performance.

The library avoid overhead and boilerplate compared to other logger library such as Winston or Pino.

I restart the project

New generation of tools:

• Speedy Web Compiler
• ESBuild
• BiomeJS t combines code formatting and linting into a single high-performance JavaScript toolchain.
• Oxc is a collection of Rust-based Javascript tools focusing on linting, formatting and transforming Javascript and typescript tools.
• Fast Node Manager / Mise
• Typescript in Go

Another notable efforts are Turbopack and Turborepo, Bun and Deno.

Contributing becomes less accessible to the majority of JavaScript developers of course. The shift demonstrates other skills in system programming that will drive even more innovative tooling in the coming years

Testing sucks because you try to test implementation details. This results in you writing tests to pass your code. That’s not useful, because…

Instead, you should…

1. Write an empty test, with one comment for each external behavior your code should display.
2. Write the code to test each comment below it.
3. Then write the actual code to make it so.

The author provides some code sample.

1. Creating Blob Objects Safely and Efficiently
2. Chunking Large Files to Avoid Memory Explosions
3. Image Compression and Format Conversion on the Front End (with the canvas API)
4. A Unified File Preview Component
5. Data Export and Download with Blobs (JSON, CSV, “Excel”)
6. Blob URL Memory Management and Leak Prevention

Not ready for ruse in production

A new API that aims to improve the history API