Destructuring is a concept introduced in ES6 that allows developers to destructure objects into variables without explicitly setting a variable to the object key/val. Confused? Yeah you’ll be even more confused as you start reading.

What is happening in this statement?

1

2

let obj={first:'Tom',last:'Alexander'};

let{first:f,last:l}=obj;

Is it obvious to you that f and l are new variables created from the values named first and last in the “obj” object?

I bet not.

How about this one?

1

let[x,y]=['a','b'];

Is it obvious to you that two new variables are being created, x= ‘a’ and y = ‘b’?

I didn’t think so either.

It gets worse.

1

let{x:x}={x:2,y:3};

What the bleep is going on here? Would you guess that we’re only creating a variable x (set to the value of x) and ignoring y?

It gets even uglier.

1

2

let obj={t:[{first:"Tom",last:"Alexander"},{}],a:true};

let{a:[{t:f}]}=obj;

Go ahead. Tell me seriously what’s going on here at first glance.

It gets even worse.

1

let{length:len}='Tom Alexander';// len = 3

So you can call a property of a string value too? That’s fun and clear, isn’t it?

The syntax is absolutely confusing and is going to introduce some ugly, ugly code and bugs. It *can* be useful and enable you to write some pretty clean code, but its potential for misuse outweighs its benefit.

Tread lightly and be sure to not misuse its power. These are pretty contrived examples for the purposes of demonstration, but I wanted to show that just because it can shorten the number of lines in your code doesn’t mean that it enhances readability. Readability is much more important than breviloquence in code.

I’m with you on renaming during destructuring – it’s almost too terse to make sense, plus order is inversed, which means the local reference is hard to find at a glance.

But if you can say the same about a lot of features in Javascript. Array literals?! They’re a disaster waiting to happen!

[] + [] === ”

The above is something you’d never do. You wouldn’t write it, and you wouldn’t have any other expectations of it. It gives some indication of how type coercion works, so it’s somewhat useful as a demonstration of that particular feature, but without any explanation or intent, asking people who are new to this functionality if they’re confused is going to get you a resounding “yes” – because it’s a straw man.

In the situations where you’re assigning object properties to local variables len, t and f, it’s not clear what purpose is being served (presumably none). But if we ditch the renaming aspect, things get a bit clearer:

let { length } = ‘Thomas Alexander’

…this gets us closer to understanding how destructuring might be useful as a way of extracting properties from objects as local references. That code above is pretty much the same as

let length = ‘Thomas Alexander’.length

…But it saved us some bytes. It gets far more useful if you want to grab several references from an object in one sweep, especially in function signatures. Here’s a dumb function for getting peoples’ full names in ES5:

Destructuring is not a new concept and has been successfully implemented in other languages like Python, Clojure, Perl, etc. It is simply another tool to boil code down to its intent without extra fluff. New syntax can be off-putting at first, but I don’t think the sky is falling.

I have to agree with you there. Further to that I feel strongly that ES6 should of been focussed primarily around simplifying the language and ironing out the ‘bad parts’ instead of borrowing concepts from other languages to appease people who are too stubborn to part with their classical OO languages and tools.

Tyler EichJune 12, 2015 @ 6:08 pm

Destructuring hinders readability the same way ternary operators, || short-circuiting, and !! boolean casting hinder readability. They’re powerful shortcuts with potential for abuse, but I can’t imaging any JavaScript dev advocating their removal. And with experience, parsing the shorthand becomes second-nature.

Object destructuring is not the problem. Developers who write spaghetti code will do so regardless of the available shorthands.

Very good point. It’s so odd to have comments that aren’t overly negative and berating, so thank you!

I think the concept is cool, but I find it hard to read. It’s a syntax that is so inconsistent with traditional JavaScript that it just sticks out like a sore thumb, ya know? I don’t doubt its usefulness, however!

I’d actually rather not have the ternary operator but have if be an expression itself. Though since that’s not the case, I do use the ternary operator in its place.

Short circuiting is fine.

I don’t see a reason to use !! instead of Boolean().

Object destructuring is fine. I could read each of those examples perfectly. And it’s not calling a function, it’s grabbing a property off of a string. Which is /weird/ but entirely possible. I’d probably use “abc”.length in that case.

A lot of language features look uncomfortable at first. Long form, deep destructuring may be ugly but the functionality exists for consistency. Just because it exists doesn’t mean you need to use it and you can rely on linters to enforce sane styling.

Destructuring combined with object shorthand makes the syntax let {x} = someObject palatable and once the idiom becomes recognizable then deciphering its meaning becomes second nature (akin to IIFEs or nearly any pattern in JS).

I’m firmly in the “enabling” camp here:I think destructuring is a great feature because of the open-ended expressive power it provides, despite the likelihood that some will abuse it to create hard-to-read incantations.

Used correctly, destructuring allows you write beautifully elegant code. (As a community we’re still figuring out what the limits of ‘correctly’ are – this article does indeed contain some examples of destructuring that are less readable than the ES5 equivalents, and you’re right to point out how bad they are.) It’s like arrow functions – odd at first, but your fingers will thank you for persevering.

Re ‘I recommend skipping over this in ES6’ – other people (me!) will be (and are) using destructuring. Choosing not to use it in your own code is one thing, but explicitly rejecting it means that everyone else’s code will become unreadable to you!

I think you’ve really missed the entire point of destructuring, which leads to your conclusions about its readability.

What you’re missing is the context of what it’s replacing. When you consider the before/after of many examples, the ES6 destructuring is way, way more readable. But not “readable” in the commonly misappropriated sense, like “can i glance at it and understand immediately what it means”. Rather, in the “does it have logical rules and consistency that I can learn and then be able to understand its various variations”.

As with most of the new syntax additions in ES6, the point is about taking the older idioms that are verbose and confusing and expressing them in a sensible and readable (aka, “learnable”) way.

Can they be abused? Of course they can. But power used correctly in the learned hand produces something much better in ES6 than they ever could in ES5. That’s one of the most important narratives about ES6.

Smaller isn’t always better. I can read the ES5 option much easier (and yes, I’d use short-circuiting and update my API accordingly to make it cleaner). The ES6 function using destructuring hides a lot of things behind the scenes and no longer makes your code straight-forward (imo).

I generally agree with you about the destructuring syntax, in that it’s insanely hard to read the more it’s used.
However, just a minor nitpick, the issue with your simplified form of Kyle’s example is that there’s a difference between a falsey value like 0 and undefined.
All of those numbers may want to accept 0 as valid.

Kyle, the one thing I would disagree with you on is about the readability statement.
The “can I understand it at a glance” is not a misappropriation of the term, but one of the ways in which it’s defined (and when it comes to code, IMHO, I think it’s one of the most important factors).
I think your quote of “does it have logical rules and consistency that I can learn and then be able to understand its various variations” is somewhat tautological, because we’re talking about a programming language. Of course it has logical rules and consistency that you can learn.
Assembly is readable by that measure.

But that’s not the issue here. And the issue isn’t even that it’s brand new syntax.
The main issue is that even after your familiar with it, there’s a ton of potential abuse in there for the sake of one immediate developer’s convenience.
It’s like single letter variables. Sure they’re allowed, and even totally acceptable in some cases, but only really bad or inconsiderate programmers ship code that use them liberally.

In general, though, I’m not against the syntax, and glad it’s available for those cases where readability isn’t improved by verbosity.
But I dread opening up someone’s code and finding some of the examples above 🙂

While I agree that deeply nested destructuring is unreadable, I believe that by-and-large this is a very readable syntax. Saying that the potential for misuse negates the benefits is a little too much. I’ve read through plenty of gross misuse of non-ES6 JS syntax too. Does that mean we eschew the language entirely?

I understand that readability is subjective, so this may not be your cup of tea, and that’s completely fine. I believe this is a common pattern that most people are used to in other languages and will adopt. I find the conciseness and readability to be a great boon to my code.

Traditional cooking as you call it is fading away thanks to ES2015. Destructuring can feel a bit out of place taken in isolation but it blends very well with other new features, mainly shorthand property assignment, default arguments and the rest operator.
Besides that, easiness lies in the eye of the beholder. The easiness of something is a subjective notion that rest entirely on your passed learnings and so doesn’t hold too much of intrinsic value.

if we were to make JavaScript adhere to the needs of only those with limited readability skills, we would then had not needed any new revisions of JS post ES 4. We would also have long and winding codebases that do allow readability at a micro level but prevent anyone from skimming code to get the bigger picture. We would also spend hours writing the code instead of using our mind to create any genius algorithm.

If readability is such a problem for some, IDEs can be equipped with AST parsers that demystify such lines of code.

I use destructuring & pattern matching in Clojure and Elixir where it is taken to the limit and, believe me, it certainly enhances the language and coding experience. This is a grate feature to have in ES6.

I totally agree with you that you shouldn’t overuse it. There must be a very good reason to use it for mapping object properties to variables with a different name, or to use nested destructuring.

It’s not really fair that you mostly show these advanced usages of destructuring in your article instead of the basic syntax of let {x, y, z} = point3d;. You will hardly need the advanced usages in practice, whilst the regular use case gives us a beautiful way to write your intent in a compact, readable way.

I can see this being discussed in a new edition of JavaScript: The Good Parts. I think the renaming syntax is backward from what you would expect, and doing something advanced with it is ridiculous, but the basic use case is awesome… so yea. Just tread with care.