Funny enough my impression of JS (the kind you'd write in 2007 more than the type you see now, mind you) is that it's remarkably tolerant; many idioms and operations which would cause, in other languages, runtime errors or compile errors, would just get steamrolled over in JS because of just how much built-in flexibility the uber-weak type system (plus liberal use of the prototype pattern in the stdlib) allows for.

- Wanna subtract a string from a number? That's not a type error, that's a `NaN` -- which is just a perfectly-valid IEEE 754 float, after all, and we all float down here.

  - Hell -- arithmetic between arbitrary data types? Chances are you get `[object Object]` (either as a string literal or an *actual* object), which you can still operate on.

Frankly, while I haven't had a frontend focus in about 15 years, I struggle to think of any situation where calling a stdlib function or standard language feature would result in an actual exception rather than just an off behaviour that'll accumulate over time the more of them you stack on eachother. I guess calling an undefined variable is a ReferenceError, but beyond that...

(This comment shouldn't be taken as an endorsement of this school of language design)

It is also (nearly) impossible to completely crash a web page. There isn't a main loop that can panic out. No matter where an exception gets thrown, the overall application keeps going and responding to events.

Can't access a network resource? API returns an unexpected error? Library crashes? Browser extension breaks something? Doesn't matter. The user can still view and scroll the page, and the rest of it will probably keep working, too.