This is the right default when the inputs are not already sorted, when the combined size is small (under a few thousand items), or when readability matters more than micro-optimization. Time complexity is O((n + m) log(n + m)) because the engine sorts the concatenated result. The mandatory comparator ((x, y) => x - y) is the single biggest gotcha: omit it and Array.prototype.sort coerces values to strings and sorts lexicographically, which produces wrong order for any number with two or more digits.

When both inputs are already sorted, you can merge in O(n + m) linear time by walking two pointers and copying the smaller current value into the output. This is the canonical interview answer and it is also faster in practice than concat-then-sort once the combined size grows. The <= (not <) keeps the merge stable: equal values from a come before equal values from b, which matters when each item carries extra fields. Always test the empty-input cases; an off-by-one in the drain loops is the most common bug.

Preallocating the result with new Array(a.length + b.length) and writing by index avoids the push resize cost on hot paths. The cost difference is small for one call and meaningful inside a tight loop, where v8 cannot always elide the dynamic growth. The structure is the same two-pointer merge, just with index-based writes. Use this version inside a hand-rolled mergesort or when you measure that push shows up in a profiler; for one-off calls in product code, prefer the readable variant in accordion 2.