Given the JavaScript string "<a><b>", what does the regex /<.+>/ match and what does /<.+?>/ match, and what rule explains the difference?

## Greedy is the default JavaScript's quantifiers — `*` (zero or more), `+` (one or more), `?` (zero or one) and the counted forms `{n}`, `{n,}`, `{n,m}` — are **greedy**. A greedy quantifier consumes as much input as it possibly can before letting the rest of the pattern try to match, then gives characters back one at a time only when forced. Walk `/<.+>/` over `"<a><b>"`: 1. `<` matches the `<` at index 0. 2. `.+` is greedy, so it consumes everything it can: `a><b>` — to the end of the string. 3. The pattern still needs `>`, but there is no input left. Failure. 4. The engine **backtracks**: `.+` gives back one character, now holding `a><b`, leaving `>` as the next input character. 5. `>` matches. The overall match is `"<a><b>"` — the whole string. The result surprises people who read `<.+>` as "a tag". It is really "a `<`, then as much as possible, then the *last* `>` that still works". ## Lazy quantifiers Putting `?` immediately after a quantifier makes it **lazy** (also called non-greedy or reluctant): `*?`, `+?`, `??`, `{n,m}?`. A lazy quantifier consumes the minimum allowed, then expands one character at a time only when the remainder of the pattern fails. Walk `/<.+?>/` over the same input: 1. `<` matches at index 0. 2. `.+?` takes the minimum for `+`, which is one character: `a`. 3. The pattern needs `>`; the next character *is* `>`. It matches. 4. Match complete: `"<a>"`. Note that `?` is doing double duty in the syntax. On its own it is the quantifier "zero or one". Directly after another quantifier it is the laziness modifier. So `a??` means "zero or one `a`, preferring zero". ## What laziness does not do The single most common misconception is that lazy means "find the shortest match in the string". It does not. Match position is decided first: the engine tries to match starting at index 0, then index 1, and so on, and the **leftmost** successful start wins regardless of length. Laziness only influences how much a quantifier consumes once a start position is being tried. A second misconception is that lazy quantifiers never backtrack. They backtrack in the opposite direction — expanding rather than contracting — and can do just as much work. `/^.*?x$/` on a long string with no `x` still explores every expansion before failing. A third: laziness is not automatically faster. On text where the target is near the start, lazy wins. On text where the intended match runs to the end, greedy wins. Neither is a performance rule. ## The better tool most of the time When you write `<.+?>` you are usually expressing "characters up to but not including the delimiter". A **negated character class** says exactly that, without relying on backtracking at all: ```js "<a><b>".match(/<[^>]+>/)[0]; // "<a>" ``` `[^>]` matches any character that is not `>`, so the quantifier physically cannot run past the delimiter and never has to give anything back. The class version is clearer about intent and does far less work, which also makes it much harder to write a pattern that degrades badly on adversarial input. The equivalence breaks down only for multi-character delimiters, where a lazy quantifier really is the natural spelling. Also worth knowing: JavaScript has **no possessive quantifiers** (`a++`) and **no atomic groups**, the two features other flavours offer for saying "take this and never give it back". Every quantifier in a JavaScript regex is backtrackable, which is exactly why a negated class is the tool of choice for cutting off runaway matching. ## A worked contrast to keep ```js const s = 'name="x" id="y"'; s.match(/".*"/)[0]; // '"x" id="y"' - greedy, spans both quotes s.match(/".*?"/)[0]; // '"x"' - lazy, stops at the first close s.match(/"[^"]*"/)[0];// '"x"' - class, same result, no backtracking ``` Being able to produce that three-way comparison on demand — and to say why the third line is the one you would ship — is what a strong answer looks like.