Sass, Prisma, native DB drivers, or any other project using node-gyp or Node's NAPI are valid examples.

As a sibling comment posted, Node packages have no issue distributing non-JS assets. Since the very beginning, the "package.json" file had support for the "arch" and "postinstall" fields to distribute precompiled binaries or compile on install, for example using node-gyp. If you split your precompiled binaries and use optional dependencies then only the right package for your machine is downloaded.

In all package managers, distributing native code may be uncommon but it's always supported well enough (Node/npm/yarn, JVM/Gradle, PHP/Composer, Ruby/gem, Rust/Cargo, etc). What's unique about Python is how messy all the packaging handling is compared to other languages.

The native JS semantics are UCS-2. Saying that it's UTF-16 is misleading and confuses charset, encoding and browser APIs.

Ladybird is probably implementing support properly but it's annoying that they keep spreading the confusion in their article.

If the logic is merely about validation, then an IDL with codegen for TS and some backend language is probably better. There are also some more advanced languages targeting transpilation to both JS and a backend language such as Haxe, but they all have some trade-offs.