I think the other user meant that ls output is not supposed to be treated as parsable, because the tool doesn’t offer any guarantees in that regards.

Shells have built-in support for globbing files anyway. xargs is also not needed. If someone is allergic to using a shell for loop, find always had -exec with ; instead + which wouldn’t trip on too many arguments.

can execute TypeScript directly.

Did the word “directly” get the same fate the word “literally” got? As in, it completely lost its real meaning?

Bundling a compiler/transpiler and directing inotify at a source directory (for glorious hot-reloading) doesn’t a language “runtime” make. Otherwise, I can create “runtimes” for any language in three lines of code right now.

unless you’re saying that Bun is slower.

Are you saying JavaScriptCore is faster than V8? Or is the majority of time in webshittery operations not spent on actually running code, and that’s how bun “wins” ?

First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.

Second of all, bun binds against JavaScriptCore, which is the JS engine used in Safari. Node binds against V8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.

Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.

Bun is a TypeScript runtime, like a faster NodeJS.

I guess the target audience is non-coding AI skeptics looking for pseudo-intellectual takes, which appears to be a growing market. Because getting the very first technical detail, and a very basic one at that, this wrong is not a good look.