Quote:
Originally Posted by Philip M
filter is a JavaScript extension to the ECMA-262 standard; as such it may not be present in other implementations of the standard.
It beats me why anyone would want to use the "workaround" filter code to cater for older browsers when the same result can be achieved in a few lines of "antiquated" Javascript code. Seems to me to be a fine example of "Never use 5 lines of code where 20 will do". 
|
filter() is is ecma 5, and every browser maker supports ecma 5.
for a small classroom example, you are probably right, there is no glaring superiority to filter() over a procedural loop. When you work on large projects, having such logic named and re-callable pays large dividends by actually lower the line count, making documentation more generic, providing a private scope so that things like setTimeout and event handler behave as expected, providing more opportunity for JITs to re-use byte-code versions of the logic, and by providing more precise error information to firebug/error consoles.
it also is nice that you can modify crucial joint in your pipes system-wide in one spot, rather than find-and-replacing 10 for loops.
lastly, i don't think it's an honest comparison to your "5 lines where 20 will do" quip. people like jQuery because "i can do XXX in on line of code!". If you run a trace on jQuery, you'll see it's actually using hundreds of lines of code over thousands of function calls to accomplish that "one line". But does/should the coder care about the work/sweat/tears that others did to build the base of his pyramid? I don't think they do, and according to the developer "it's one line", an assessment i could embrace or shun depending on the wind currents.
and let's look at the forest, not a single tree:
let's see which pattern can filter out 100 different arrays in less code...