I tried this pattern but ended up fighting lonely exceptions

A weak object doesn't prevent the garbage collector to remove the object from memory. It can be useful to keep track of objects during the program lifetime (or a request handling from example).

Render the charts as particles

@media (scripting: enabled) and @media (scripting: none)

There's also an initial-only value, which is for scripting that is enabled during page load but not after

Before this feature, one approach for detecting JavaScript support was by setting a custom selector on the opening html tag—a common one seen in the wild is the no-js class name.

There are cluster wins:

• i18n: Intl.RelativeTimeFormat, Intl.PluralRules, Intl.NumberFormat, Intl.DurationFormat, Intl.ListFormat
• HTTP Clients: fetch can be used instead of axios. Limitations: fetch doesn't reject on HTTP errors, no interceptors, no automatic retries, no upload progress.
• UI Primitives: <dialog>
• Lodash utilities
• sometime in the future: Temporal

That’s also the reason NaN !== NaN. If NaN behaved like a number and had a value equal to itself, well, you could accidentally do math with it: NaN / NaN would result in 1, and that would mean that a calculation containing a NaN result could ultimately result in an incorrect number rather than an easily-spotted “hey, something went wrong in here” NaN flag.

How to check the value can be used for a calculation?

• typeof theValue === "number": to me too, it feels clunky th compare strings in order to use a number
• Number.isNaN() does exactly what it means: it checks for the NaN
• but the global function isNaN() returns true "“if I tried to make you into a number, would that work, or would you end up being NaN?"

It's a 9MB binary that can run npm packages.

The packages can live on ants.land.

The startup time is two times faster than Ant, 4.5 faster than Deno and 5.22 faster than NodeJS.

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