Develop Reference

Why use DOMStringList rather than an array?

I've recently discovered the DOMStringList, which can be found in an IndexedDB's list of store names. It seems like a DOMStringList is just a simplified version of an array, which has only two methods item() and contains(). There is no useful methods like indexOf, filter, forEach that you'll find on an Array. Why use this kind of object? What are DOMStringList's advantages?

The existence of DOMStringList is a historical accident. Today, in modern APIs, the same use cases are met by using an Array instance.
It was introduced into web APIs because we needed something array/list-like, that cannot be modified. The "cannot be modified" part is important, because there's no good answer for what would happen to a modifiable array in scenarios like
db.objectStoreNames.push("foo");
db.objectStoreNames.push(notAString);
db.objectStoreNames.shift();
At the time the first API using DOMStringList was introduced, the people designing the API did not know how to make this work with Arrays. So, they designed DOMStringList. It was used for a couple of APIs, namely location.ancestorOrigins and db.objectStoreNames.
But then, the people designing such web APIs figured out how to introduce non-modifiable arrays. This actually took two separate tries:
Introducing the use of frozen Array instances, via the FrozenArray<> Web IDL type. See whatwg/webidl#52, and the linked bug there.
Introducing the use of proxies around Array instances, via the ObservableArray<> Web IDL type. See whatwg/webidl#840, and the linked bug there.
The difference between these two is that frozen Arrays cannot be modified, even by the browser; whereas proxies around Arrays can be modified by the browser. (Or even by the web developer, if the spec in question allows that.)
So, can we move everything using DOMStringList to use one of these modern solutions? No. Because there is code in the wild which depends on db.objectStoreNames.item() and db.objectStoreNames.contains() working, and that would break if we moved to actual Array instances, which don't have those methods.
So we might need a third Array wrapper type if we want to fully obliterate the legacy array-like classes from the web platform, and start using true Arrays. It would be a subclass of Array, with an extra method or two, and possibly a proxy wrapped around that. Nobody has yet made moves in that direction.
(Other legacy array-like classes, you say? Yes: in addition to DOMStringList, we have TouchList, AnimationNodeList, CSSRuleList, DOMRectList, FileList, ... see this list of classes on the web platform with an item() method, most (but not all) of which are of this sort.)

Array.filter vs $filter('filter')

Which one should i use in an angular app and why?
array.filter(o => o.name === myName);
or
$filter('filter')(array, {name: myName}, true);

The key difference is the shortcuts or syntactic sugar provided by the $filter('filter'). For example, the following syntax can be used to get the items containing the keyword string in any of the item's string properties:
$filter('filter')(array, 'keyword')
Which can not be as simple using the standard ES5 Array.prototype.filter.
Whereas the general idea is the same for both approaches - to return a subset of a given array as a NEW array.
Update:
Under the hood angular uses the Array.prototype.filter:
function filterFilter() {
// predicateFn is created here...
return Array.prototype.filter.call(array, predicateFn);
}
So, if you don't use the shortcuts - angular simply delegates the call to the standard filter.
To answer your question: use the one that lets you write less code. In your particular case it would be array.filter(o => o.name === myName);

While using $filter('filter') can be easier and more syntactically attractive, I can think of four good reasons to use Array.filter over $filter('filter')
Efficiency
While it is true that $filter('filter') uses Array.filter under the hood, it also uses other code, including deep comparisons, in addition to Array.filter. In most cases the speed difference is negligible, but in some use cases it can be substantial. When working with large data objects for example, I've found that using Array.filter makes a difference.
Angular 2+ does not support AngularJS-style filter
From the angular migration guide:
The built-in AngularJS filter and orderBy filters do not exist in
Angular, so you need to do the filtering and sorting yourself.
If there is any possibility that you may upgrade to Angular 2 or higher in the future, then using Array.filter will save you some migration migraines. Even if you don't plan on upgrading, clearly the Angular team didn't think the AngularJS filter was worth keeping, which leads me to think it's probably better to avoid it anyway.
Favor native code over library code
Libraries and frameworks like AngularJS are amazing tools; But if you have to choose between using vanilla javascript or using a library, and there isn't a good reason to use the library, you should always use the vanilla javascript. It is more universally understood, less dependent on 3rd party code, etc. There are a plethora of online articles arguing this point.
"$filter" inhibits type-checking in Typescript files
This one only applies if you use (or plan to use) Typescript. At the time of writing, the #types library for angularjs defines the return type of all $filter functions as any, which can lead to some serious type-checking problems if you aren't careful. By contrast, Array.filter always returns the expected array type.

You should use Array.filter and then assign the result. When you use $filter, it is re-applied at the end of every $digest cycle for all the bindings and that is performance intensive to watch for the values and update the results after every $digest cycle. Instead you should filter your result and assign it to your scope variable explicitly

node.js utility library for working with objects and arrays?

Is there good utility library for working with objects and arrays.
For example functions like: extend, forEach, copying objects/arrays ect,
What is common in node.js environments? I wonder are there decent alternatives to underscore.js?

underscore.js is a pretty good default for this kind of stuff. Here's a thread on compatibility issues that may be handy.
Edit, upon you're request for something beyond underscore:
As far as I know, underscore has become the defacto standard when you're looking for additional array operations (much like jQuery for DOM manipulation). Joyent maintains a pretty thorough manifest of node.js compatible modules, and the only seemingly comparable utility would appear to be an experimental library called fjs with an emphasis on currying (and judging from the source, most of the functionality comes from extending underscore functions anyway). There might be something else out there, but as far as I know nothing with the penetration and maturity of underscore.
Yet another edit - here are a handful of older libraries if you're so curious, but their maintenance has fallen off a bit - valentine, wu.js, Functional, and Sugar. Functional and valentine may be a bit thinner; wu.js looks to be about the same and sugar is even fatter.

lodash is a "drop-in replacement* for underscore.js" that you may also want to consider.
Lo-Dash v0.7.0 has been tested in at least Chrome 5-21, Firefox 1-15, IE 6-9, Opera 9.25-12, Safari 3-6, Node.js 0.4.8-0.8.8, Narwhal 0.3.2, RingoJS 0.8, and Rhino 1.7RC5

For extend specifically, you can use Node's built-in util._extend() function.
var
extend = require('util')._extend,
x = {a:1},
y = extend({}, x);
Source code of Node's _extend function: https://github.com/joyent/node/blob/master/lib/util.js#L563

Have a look at Ramdajs: http://ramdajs.com/0.22.1/index.html
The primary distinguishing features of Ramda are:
Ramda emphasizes a purer functional style. Immutability and
side-effect free functions are at the heart of its design philosophy.
This can help you get the job done with simple, elegant code.
Ramda functions are automatically curried. This allows you to easily
build up new functions from old ones simply by not supplying the final
parameters.
The parameters to Ramda functions are arranged to make it convenient
for currying. The data to be operated on is generally supplied last.
The last two points together make it very easy to build functions as
sequences of simpler functions, each of which transforms the data and
passes it along to the next. Ramda is designed to support this style
of coding.

Linq for JavaScript vs standard methods

I am an architect for a software development team. I have built a sizeable warchest of web controls and tools for us using ASP.NET and JavaScript/jQuery.
Part of the toolkit is a functional equivalent to .NET's IEnumerable LINQ methods (where, select, etc.) for JavaScript arrays. I was surprised how simple these were to implement using the js prototype feature. My hope was that our devs could leverage their knowledge of LINQ seamlessly on the client side, and the results have been great so far.
There is just one snag, as I discovered today: there are already a handful of functionally identical methods as of JavaScript 1.6. They are filter, map, some, and every, corresponding to LINQ's where, select, any, and all methods, respectively.
They aren't supported by IE8 or earlier (which might explain why I had not heard about them), but it is trivial to provide an implementation so that they work cross-browser. Note that there are dozens of LINQ methods that do not have a native equivalent, such as sum, max, avg, groupBy, etc.
My question is this: how should my development team address this discrepancy? I think we have three options:
1 - Ignore the native JavaScript methods (or consume them internally in a pass through method) and use only the LINQ methods. Forbid the use of the native methods so that our codebase is self-consistent.
2 - Use the native JavaScript methods whenever applicable, and the LINQ methods when there is no equivalent.
3 - Allow either to be used.
I will suppose that most of the community will side with Option 2, as it is arguably more standards-compliant, but I feel it will be disorienting for devs to have to know that some functions are identical in JavaScript, while others have a different, arbitrary name. It really jacks up the cross-platform consistency we have achieved so far.
Which of these would you choose, and why? Is there another alternative I am not considering?
Bonus Question: jQuery has neither native functions nor LINQ functions. What method names should my jQuery extensions use?

I would opt for #1 out of the three you provided, because I value consistency, but also because it allows you to provide a fallback if the method is not natively available.
That's also similar to what Underscore.js does for some of its methods --- uses native implementation if available, otherwise resorts to its fallback implementation.

You can try manipula package that implements all of C# LINQ methods and preserves its syntax:
https://github.com/litichevskiydv/manipula
https://www.npmjs.com/package/manipula

Javascript wrapper that gives us Rubyish Javascript?

Are there any frameworks/wrapper out there that gives us rubyish javascript?
Instead of the usual for() {} loop gives us the object.each {} loop like in Ruby?
Since javascript could be used in web browsers I do want to use it for the server side too, but I do like ruby syntax far more.

The Prototype library, having been developed by guys very close to Ruby on Rails, has a very Ruby-ish feel. It uses Ruby lingo (like mixins); for instance, the Enumerable mixin (which Prototype mixes in to arrays by default) adds the each method to an array, so you can do this:
["sample", "array"].each(function (item) {
console.log(item);
});

look up jQuery. it has a
$('.css-selector').each(function(i){
//do stuff
});
Ref: http://api.jquery.com/jQuery.each/

You might want to checkout JS.Class - Ruby-style JavaScript. From the docs,
JS.Class is a set of tools designed to make it easy to build robust object-oriented programs in JavaScript. It’s based on Ruby, and gives you access to Ruby’s object, module and class systems, some of its reflection and metaprogramming facilities, and a few of the packages from its standard library. It also provides a powerful package manager to help load your applications as efficiently as possible.
It comes with a well packaged standard library including modules and classes such as
Enumerable
Hash
Set
Observable
Command
The Enumerable module, for instance, is comparable to that in Ruby, and includes methods like
all
any
collect
drop
findAll
forEach
grep
partition
reject
select
zip

Here's a post by Ken Egozi which discusses adding .forEach and other helpers to the array prototype.