In general, if NaN1 and NaN2 are different (there are 23 bits in a NaN that can be set to an arbitrary value, the NaN payload) then combining them isn’t deterministic. NaN1 + NaN2 might produce NaN1 or NaN2 depending on the processor model, instructions etc. IEEE754 only says that the result must be one of the two input NaNs (or at least it did last time I checked the standard.)
In practice, NaN payloads are seldomly used so it doesn’t matter much. NaN canonicalization involves transforming all NaNs to specific NaN values, and AFAIK it’s expensive because technically you need to check for NaN all the time.
> They are aiming to provide an "all-in-one" solution with the parser, transpiler, bundler etc all in one place. Which means they have perhaps too much work to do.
They seem to re-use quite a lot. I don’t think any of them, besides ESBuild, roll their own transpiler. For example, Farm uses SWC:
> The performance gains in the recent past have mostly been due to moving away from single-threaded JavaScript to multi-threaded compiled languages.
This is overly simplistic. Parcel had far better performance than Webpack before they added native code or threading.
Webpack remained slow because it didn’t have a good public/private interface for its plugins, so the changes that could be made were limited.
> Vite can adopt the partial bundling of Farm, but dispensing with its remaining JavaScript tools is a major breaking update.
Turbopack and Parcel both have excellent performance without any compromises to their bundling strategy. Vite skipping this likely just simplifies it’s architecture. Bundling creates an opportunity to be slow, but it doesn’t necessitate it.
Which circumstances?