Array.prototype.reverse() reverses in place and returns the same array, so nums.reverse() and [...nums].reverse() look almost identical but have very different semantics: the first form mutates the original and the second leaves it untouched. The newer toReversed() (ES2023, Node 20+) returns a reversed copy in one call, which is more declarative. Default to toReversed() if your runtime supports it; otherwise [...arr].reverse() is the immutable fallback. Reach for the bare reverse() only when you specifically want the mutation.

Two pointers walk inward from each end and swap until they meet. Time complexity is O(n) and space is O(1), which matches the built-in reverse(). The destructuring swap ([a[i], a[j]] = [a[j], a[i]]) avoids a temporary variable and is idiomatic in modern JS. Edge cases handled correctly: arrays of length 0 or 1 skip the loop body entirely because left < right is false from the start. This pattern shows up in interviews and in cousin algorithms (palindrome check, partitioning a Quicksort range).

The recursive form treats reversal as "reverse the tail, then put the head at the end." The base case is an array of length 0 or 1, which is its own reverse. Each step calls slice(1) to peel off the head and spreads the recursed tail before appending the head. This is great for teaching recursion but it is O(n^2) time and O(n) extra memory because every step copies the tail; do not use it on long arrays. For production reverse, stick to the built-in reverse() or toReversed() from accordion 1.