Here what you need to know. If you want to see the version of a globally installed NPM package, run this:

npm ls -g package-name --depth 0

Replace package-name with the name of whatever package you’re looking for.

In most cases, adding --depth 0 isn’t necessary. But in rare cases, the global package you’re searching for is also a dependency of other globally installed packages. When this happens, you’ll see the package you want, but you’ll also see a partial dependency tree of all of the packages that use the package you’re searching for.

Adding --depth 0 eliminates this problem. Feel free to leave that part out and only add it if you need it.

The post How to find the version of a globally installed NPM package appeared first on Ryan Peden.

In the case of Array.prototype.push, the JS runtime must first call toObject on the argument passed to push. It must also do a bit of work to handle the case where more than one item was passed to push, since you are allowed to make a call like this: abc.push(1,2,3). After from calling toObject and checking how many arguments were provided, it then goes through each one and does a regular property set call, which ends doing the same as myArray[myArray.length] = obj.

If you’re only adding one thing to your array, you may as well call push, since it is easier to read and the toObject call and args length check is going to make an immeasurably small difference to execution time.

If you’re adding multiple things to your array, then call myArray.push(...things). because when you do that, the JS engine’s compiled C++ will handle all of the iteration, instead of thunking back and forth between native code and JavaScript if you’re looping through yourself and calling push every time. In reality, with all of the optimization and JITing that modern JS engines do, looping through yourself probably isn’t all that much slower than passing everything to pushat once. I haven’t tested this to verify, though.

The post JavaScript Array Push Performance appeared first on Ryan Peden.

Let’s take a look at the ECMAScript specification to see what it says.  

In the case of indexOf vs includes, you’ll find them right next to each other here in the ECMAScript spec. The only difference is that includes checks if you’ve passed it a regular expression instead of a string, and throws an exception if you have. indexOf will accept a regular expression but always return -1, which isn’t too helpful.

So while includes will be a tiny, tiny amount slower because it has to check if you passed it a regex, in reality this will make no difference to how fast your code runs. You should use indexOf if you care about where the substring is in the original string. If you don’t care, just call includes because it makes the intent of your code more clear.

You should also consider that indexOf won’t find the location of NaN values in an Array. For cases where you really need to find the first location of something that indexOf can’t find, and you don’t want to loop the array through yourself, then Array.prototype.findIndex is your friend. You can pass it a function that returns true when it sees the value you’re looking for. So [1, 2, 3, NaN, 4].findIndex(Number.isNaN) would return 3.

The verdict: in most cases, in terms of JavaScript indexOf vs include performance it doesn’t matter much whether you use index vs includes. You should pick the one that’s the clearest fit for the problem you’re trying to solve.

If you liked this, you might like these other articles I’ve written:
Using Web Components with React in 2019
An Angular Roadmap – The Past, Present, and Future of Angular
How do JavaScript Arrays Work Under the Hood?

The post JavaScript indexOf vs includes performance appeared first on Ryan Peden.

Not doing this doesn’t mean you’re a bad developer. It’s entirely possible to use JavaScript effectively without digging in to understand how JS arrays are implemented. But taking a closer look can help you understand performance issues your might run into, so it’s a worthwhile exercise.

How exactly they are implemented depends on the specific JavaScript interpreter or VM you’re using. I’m going to use the V8 JavaScript engine (used by Chrme and Node.js) as an example. Other JavaScript engines, such as Mozilla’s SpiderMonkey and Microsoft’s Chakra will be similar but not identical.

JavaScript Arrays in V8

In V8, if your array only contains integers, it’ll be backed by a C++ array of integers. Typically, the backing array will be bigger than the number of integers it currently contains. If it contains a mixture of integers and floating point values or only floating point values, it’ll be backed by an array of doubles.

If the array contains only objects, or a mixture of numbers and objects, it’ll backed by an array of pointers. Even though JavaScript itself doesn’t have a concept of ‘integer’ or ‘double’ – it just sees them all as ‘number’, V8 keeps track and makes it so arrays are a bit faster and more memory efficient if you only put integers in them.

If you call push() when the backing array is full, it’ll allocate a new, bigger backing array, copy the existing elements over, and then add the new value you pushed. This is similar to the implementation of ArrayList in Java or vector in C++.

All of the above only is only sure to apply if your array is packed, and not sparse – i.e. you don’t have any gaps in the array. If you do something like

let abc = [1,2,3];
abc[100] = 50;

you now have a sparse array. If is not too spare, it’ll still be backed by an array, with empty array indices replaced with a ‘hole’ value. If you look at V8’s C++ array source (linked below), you’ll see calls to element->is_the_hole(i). If an array is very sparse, it’ll no longer be backed by an array in memory. Instead, it will be backed by a dictionary/hashtable, and it’ll take longer to both access elements and iterate through the array.

If you’re interested, you can read through V8’s array implementation in C++ here. You’ll notice that it often checks the following constants:

• PACKED_SMI_ELEMENTS – a packed integer array
• PACKED_DOUBLE_ELEMENTS – a packed double array
• PACKED_ELEMENTS – a packed object array
• HOLEY_SMI_ELEMENTS – a sparse integer array
• HOLEY_DOUBLE_ELEMENTS – a sparse double array
• HOLEY_ELEMENTS – a sparse object array
• DICTIONARY_ELEMENTS – a very sparse array that is backed by a dictionary

And you’ll see that it always tries to do whatever will be fastest for the array it is operating on. Lots of builtin functions like push, pop, shift, unshift, and concat do different things depending on the array’s density and what kind of elements it contains.

Some other things to keep in mind: if you have an array that only contains integers, and you push a floating point number or other type into it, it will be ‘downgraded’ for the rest of its life, even if you purge the non integers from it.

Also keep in mind that none of these implementation details are guaranteed. A naive implementation of JavaScript’s Array object could be backed by a linked list, and it would still work the same way it does now. It would just be slower.

Actually, if you grab an early copy of the Mozilla source code from 20 years ago, you’ll find that arrays were backed by ordinary JS objects without much optimization, just some extra code to handle special cases like the `length` property.

Digging Deeper

If you’re interested in diving even deeper into V8’s internals, I suggest starting by reading through the source files I linked to above. If you’re not used to C++, understanding it will be a bit of a chore at first.

I recommend sticking with it, though. Learning and understanding a new language is always good – and every extra insight you gain into how JavaScript VMs run your code will make you a more effective JavaScript developer.

If you liked this, you might like these other articles I’ve written:
Using Web Components with React in 2019
An Angular Roadmap – The Past, Present, and Future of Angular

The post How do JavaScript arrays work under the hood? appeared first on Ryan Peden.