objects? No... array, please!

genta profile image Fabio Russo ・1 min read

I don't like objects...that much!

This is an object:

const obj = {breed:"labrador",age:9}

But sometimes I prefer to work with arrays.

Why? Because they really look better to me... and there are really a lot of methods or loops that work just with [arrays]!

These are some tools used to "convert" objects to arrays.

//Object.values() will give you an array of all the object "values"

const obj = {breed:"labrador",age:9}

const values = Object.values(obj)


//-> ["labrador", 9]

//Object.keys() will give you an array of all the object "keys"

const obj = {breed:"labrador",age:9}

const keys = Object.keys(obj)


//-> ["breed", "age"]

//Object.entries()  will give you an arraysh version of the object. 
//Where the key and the value will be paired into an array... 
//and all of those arrays will be "pushed" into another array.

const obj = {breed:"labrador",age:9}

const entries = Object.entries(obj)


//->[["breed", "labrador"], ["age", 9]]

This is easy peasy stuff, but very often, at the beginning of my journey in JS, objects were very often a problem for me.

If only they had told me before ...


P.S: These tools are ok... if it’s ok to work with arrays instead of objects.
Sometimes you’ve to use objects... because of performance or long term maintenance.

Posted on by:

genta profile

Fabio Russo


Passionate with code... In love with Web Design, Videogames, Books and Jazz music. Years of experience in "document composition" and a Front-End Developer wannabe (since years)


markdown guide

Be careful falling into what you live vs. what works best for the solution. Many times, using an array might make you fall into an anti-pattern you won't be able to support. For example, when your dataset requires a map data structure, or a graph data structure, you can't very easily replicate those in an array in most languages.


That’s hm... obvious ? 😄


Obvious to whom? I found these examples, which you didn't mention in your article, to be a helpful caveat.

They’re... I can put those in the article if it’s ok for him.


Using arrays for everything will get you in the same place as using varchar columns for everything in an sql database: it might seem to save some effort and thinking in the short term, but it will be an enormous pain to maintain in the long run.


Just someway to do It.
I agree that sometimes you’ve to work with It.
Consider the DOM... most of the times it’s easier to work with arrays.


In the case of the DOM, you’re already working with objects, which just happen to be composed into larger hierarchies via arrays. Imagine if a DOM object were an array, where you’d have to look up each property in the array rather than having direct access to it. It’d be cumbersome to work with, not to mention the inherently poor performance that it would entail.

Most of the time with nodeList... I know what you’re talking about but I use to convert them in arrays if there’s not a HUGE amount of stuff to do.

Yes, that allows you to leverage the extra methods (i.e. power) of javascript arrays (since a nodeList is just a poor-man’s array anyway). But that’s quite different from the approach you discuss above, about using arrays instead of objects with fields.

Maybe It was not so clear ☹️


Hum, I find this odd... I also don't think this article gives a complelling reason to back up the claim (a claim which I do not agree with at all)... isn't this more or less unstructured programming? And how do you reliably work with arrays? Conventions for what index a given field should be present in? Seems dangerous and easy to screw up.


These are tools...
You can use It... you can also chose not to use It.
It’s not an article on what is better.
But I can understand your point of view


Absolutely, arrays are tools, essential ones! I guess it isn't obvious what the point of the article is... it reads like you're advocating packing data into arrays rather than data structures with named fields.

That’s why there’s a bold P.S. at the end of It.
If you’re conscious, you can chose to do It and use arrays.
If you dunno the differences, first you should learn those.

I use these tools when I work with the DOM or with very small amounts of data. Just to solve some problem I won’t care in the future about.

Ok I understand, that makes sense. Obviously for experimentation anything goes, and if arrays help you visualize the data then that's a neat perspective on how to use them!

Like I said, the article doesnt make this idea very clear, which is probably what lead to all the confusion in the comments.

I’ve to agree... I’ll do better next time.


There are times when you should use an object over an array for storing data. And if it is performance or efficiency that's your jam, using a Set is much more efficient than an array, again, depending on what you're looking to do. Swearing off objects because they don't look good is not an effective strategy in long-term development.


No one told... you’ve to... without considering It.


Have you looked at object destructuring much? Seems like it can be a decent way to get array-like access to objects, without giving them up entirely.

It's also worth noting that you pay an object-traversal performance penalty every time you extract keys or values.


I'm confused about why you find objects problematic. You've stated that arrays look better to you and that objects were often a problem for you when you started with Javascript. Would you elaborate on what is it that you find problematic about objects and why you prefer working with arrays?


More properties and during my work I do most of the stuff with data records... and arrays.
I started working a lot with katas... dunno why, most of them are about arrays.
It’s just that I feel more comfortable with them.