Given the same argument x, what can Array.from(x) do that the array spread [...x] cannot?

## Two conversions with different input contracts `[...x]` is defined purely in terms of the iteration protocol: get `x[Symbol.iterator]()`, pump `next()` until `done`, collect the values. If `x` has no `Symbol.iterator`, it throws a `TypeError` immediately. `Array.from(x)` accepts a strictly larger set of inputs. Its algorithm checks for `Symbol.iterator` first and, when present, iterates exactly as spread would. When it is absent, instead of failing it treats `x` as an *array-like*: it reads `x.length`, converts it to a non-negative integer, and reads the properties `"0"` through `"length - 1"`, substituting `undefined` for any that are missing. ```js const arrayLike = { length: 2, 0: 'a', 1: 'b' }; Array.from(arrayLike); // ['a', 'b'] [...arrayLike]; // TypeError: arrayLike is not iterable ``` The classic array-likes are objects returned from older APIs and anything you build by hand with a numeric shape. Note that `arguments` is *both* — it has a `Symbol.iterator`, so spread works on it too. ## The mapping function `Array.from(source, mapFn, thisArg)` calls `mapFn(element, index)` for each produced element and stores the result. It is not merely sugar for `.map()`: the mapping happens while the array is being built, so no intermediate array is created, and — importantly — it applies to positions the array-like never actually defined. ```js Array.from({ length: 5 }, (_, i) => i); // [0, 1, 2, 3, 4] Array.from({ length: 3 }, () => []); // three distinct arrays ``` That second line is the standard way to create a grid of independent rows. Attempting the same with `new Array(3).fill([])` gives three references to *one* array, a bug that surfaces the moment you push into a row. The difference also shows on sparse arrays. `new Array(3)` has holes, and `.map()` skips holes, so `new Array(3).map((_, i) => i)` still returns a hole-filled array. `Array.from({ length: 3 }, (_, i) => i)` visits every index because `Array.from` reads each index explicitly rather than iterating existing elements. ## Where they agree For any genuine iterable, both produce the same array: ```js const s = new Set([1, 2, 2, 3]); [...s]; // [1, 2, 3] Array.from(s); // [1, 2, 3] [...'hi']; // ['h', 'i'] Array.from('hi'); // ['h', 'i'] const m = new Map([['a', 1]]); Array.from(m); // [['a', 1]] ``` Both also drain the iterator exactly once and to completion, so both leave a single-use iterator exhausted. ## Choosing between them In real code the guidance is simple: - Source is an iterable and you want a plain copy: use `[...x]`. It is shorter, and it composes inside a larger literal — `[first, ...rest, last]` has no `Array.from` equivalent. - Source is array-like, or has no `Symbol.iterator` and you cannot change it: use `Array.from(x)`. - You want the elements transformed as you convert, or you are synthesising a sequence from a bare `length`: use `Array.from(x, mapFn)`. One further practical difference: spread expands into an argument list in the `f(...x)` form, and very large expansions can exceed the engine's argument limit and throw a `RangeError`. `Array.from` builds an array without going through an argument list, so it is the safer conversion for sequences that might be enormous. That limit applies to argument spread specifically, not to `[...x]` in an array literal. ## The pitfall to name in an interview The single most common mistake is assuming `Array.from` silently rescues *anything*. It does not rescue a plain object with named keys: `Array.from({ a: 1, b: 2 })` returns `[]`, because the object has no `Symbol.iterator` and no `length`, so the length reads as `undefined`, converts to `0`, and produces an empty array. Returning an empty array rather than throwing makes this failure quieter — and therefore more dangerous — than the `TypeError` spread would have given you. When the source is a record, `Object.values` or `Object.entries` is what you actually want.