Challenge 2: Why esbuild/SWC Can Genuinely Parallelize, Unlike Webpack/Babel — Possible Solution
====================================================================

JAVASCRIPT'S OWN EXECUTION MODEL
------------------------------
Per this chapter's own explanation (drawing on js3-3's event loop
material), JavaScript's execution model is effectively SINGLE-
THREADED for actual CPU-bound code — Node can handle async I/O
concurrently (waiting on a file read or network request without
blocking), but running JS LOGIC itself happens on one thread at a
time. Webpack and Babel are themselves JavaScript programs, so their
own core parsing and transforming work — the actual CPU-bound part of
what they do — is bound by this same single-threaded limitation. Per
this chapter, Worker Threads exist as a real escape hatch (covered in
node2-4), but they're described as "genuinely heavier-weight," not a
natural default a tool like Webpack or Babel automatically gets for
free just by existing.

WHAT GO AND RUST OFFER INSTEAD
------------------------------
Per this chapter's own explanation, Go has native, lightweight
goroutines (go2-3) and Rust has native OS-thread-based concurrency
(rust2-5) — genuine, built-in multi-threading that isn't an
afterthought or a heavyweight opt-in mechanism, but a core, ordinary
part of how programs are written in each language.

WHY THIS TRANSLATES INTO GENUINE PARALLEL FILE PROCESSING
------------------------------
Because esbuild (Go) and SWC (Rust) are written in languages with
real, lightweight native threading, they can straightforwardly split
the job of parsing and transforming MANY files across MULTIPLE CPU
cores AT ONCE — genuine parallelism, several files being processed
simultaneously on different cores. Webpack and Babel, constrained by
JavaScript's own single-threaded-for-CPU-work model, would need to
reach for the heavier Worker Threads mechanism just to attempt
anything comparable, and per this chapter's own framing, that's not
how they're naturally built to operate by default.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains specifically why JavaScript's own single-threaded model
constrains Webpack/Babel's own CPU-bound work, explains specifically
what native, lightweight threading Go and Rust provide instead, and
connects that difference directly to esbuild/SWC's own ability to
process many files genuinely in parallel across cores.