We recently encountered a "Maximum call stack size exceeded" error in Safari with our online AJAX calendar design tool (http://www.zazzle.com/design/calendar). The first culprit one tends to suspect in a case like this is an infinite recursion. However, after heavily scrutinizing and tracing through the code, double checking, triple checking, and quadruple checking, it turned out that a finite chain of recursion triggered the "Maximum call stack size exceeded" error. The code in question was performing an iteration that could possibly involve asynchronous processes, of the form... function _processElementsAsync (_elements) { var _elementsLength = _elements.length, _elementNo = -1 ; function _handleNextElement () { _elementNo++; if (_elementNo < _elementsLength) { _someAsyncFunction (_elements [_elementNo],_handleNextElement /* the continuation function */); } else { // completion code } } _handleNextElement (); } AJAX development inevitably involves more functional style programming, with more anonymous functions / lambda closures. This has effects on the patterns of memory usage. The more extensively one utilizes asynchronous coding, the more closures one tends to introduce. The application (and code) in question worked without a hitch in IE6 and FF2, but produced the "Maximum call stack size exceeded" error in Safari 2.04 (419.3). An Internet search reveals a number of cutting edge JS / Web 2.0 developers encountering this issue. Since JavaScript's functional programming facilities are being utilized more and more in RIA's, more state memory is going to find its way into the call stack rather than in deliberately created objects. In the light of this, it seems Safari's configured limit on the call stack size is a little bit too aggressive and may over time snag (and frustrate) more and more serious / hard core Web application developers.