JavaScript ES6 is Doing Too Much

Swiss Army Knife

This is a Swiss Army Knife. The Handyman, to be precise. According to the site, it has 24 functions. Can opener, scissors, nail file, pliers, wine opener, bottle opener, wood saw, toothpick, nail cleaner … the list goes on.

Conceptually, it’s really great to have one thing that does so much.

Realistically, Swiss Army Knives have not replaced the need for single-purpose devices in any of those categories.

It’s doing too much to be good enough at one task to replace a device crafted specifically to solve a single purpose in any of those categories.

I fear ES6 is introducing tools that make JavaScript do too much.


Let me give a tangible example. We’ve heard JavaScript is a language where functions are first-class objects.

This is really a fancy way of saying functions can be treated like any other data type. Just like you can take a number, string, array or object and store it in a variable, pass it as an argument to a function or return it as a result of processing a function,  you can do the same with a function.

This means functions are very important in JavaScript. Using them properly is a Major Key to Success.

How do you create a function Pre-ES6?

To be honest, nobody really uses the third method so you can pretty much ignore it. Which leaves method one and two as the only practical candidates.

Named and Anonymous Functions are syntactically identical. The difference is while one creates a function called shout, the other creates an unnamed function and stores it in a variable named shout. The way to create them is identical. There’s no mistaking a function declaration when you see it.

How do you create a function in ES6?

Yup you’re seeing correctly. In addition to the original three two ways (which the creator of that gist boiled down to one way because they were practically the same thing), there’s an additional 3 official ways to do the exact same thing!

This comment on the gist pretty much summarizes my thoughts on the matter.

Having multiple options to write the same thing will only decrease readability.
Instead of spending 2 seconds to write the “function()” string, you will spend more time to read code, on the long run.

So, I’m not happy at all about the new ES6 syntax.

– andreipfeiffer


I get that the compact new way of writing functions is attractive to very experienced programmers, but I don’t think pros are what made JavaScript the popular language it is.

People who knew C or Java, who had a familiarity with JavaScript’s “C-like Syntax,” had nothing to do with JavaScript’s success. At the time the web saw its first boom these programmers were still betting on Java and .NET. JavaScript succeeded because it made what those programmers did accessible to people without their background, not those with a background similar to their own.

– Mikeal Rogers

ES6 is an attempt to make JavaScript look like other programming languages. For all the other advantages those languages have over it, those languages are harder to learn and they are way less approachable. ES6 is turning JavaScript into a more complicated language with arguably dubious benefits. After all, virtually nothing it brings to the table was previously impossible in the first place.

ES6 is making JavaScript more complicated to appeal to people who program in more complicated languages and I think this is a terrible decision.

Get New Posts via Email

I don't always post, but when I do, you can get it sent directly to your inbox.

Join 15 other subscribers

  • Function declaration and anonymous function expression, to be precise. You can also write a named function expression if you like, the distinction is not whether it is named, but whether it is a declaration or an expression.

    • > Named and Anonymous Functions are syntactically identical.

      This too is extremely wrong. They behave differently. One of them is hoisted, the other is not. One of them is an expression, the other isn’t.

      • Syntactically identical means their syntax is similar.

        Doesn’t say anything about their behavior.

        Functions are hoisted, so it doesn’t matter where you declare them in a scope, they’ll be available by the first line. I get that much.

        What I meant to convey is beyond the hoisting (and one not giving you the function name in the stack trace), both methods will let you shout( msg ); and there’ll be virtually no difference.

        • It matters hugely that declaration are hoisted and expressions are not!

          Hell, the declaration will work with if (false), too! The expressions won’t.

          • This seems like a highly contrived example.

            1. If you don’t know about hoisting, you wouldn’t be trying to use the function before you declare it.

            2. If you know about hoisting, you’ll know the variable is also hoisted, but the value isn’t set til later in the code. You wouldn’t be trying to check the type of a variable before you do any assignment.

            3. let is block scoped. That’s just being slippery now 😉

          • Okay, so what was your point, then?

            All the methods you mentioned in your article let you call shout( msg ) and there will be no difference, too (except for the array example, which as far as I can see is a misunderstanding on your behalf).

          • True, the array thing is a misunderstanding on my part. I wouldn’t try and downlay that I made a serious error there.

            My point is the way you declare a function looks VERY different. A function has function in front of it.

            I have no issues if this were optional. I ignore coffeescript. My issue is that this new syntax is less newbie friendly. It makes JavaScript seem scarier to newbies and I’m not happy about that.

            It’s the first language I truly learned and I don’t know if I’d have had the courage to pick it up if it is as technical-looking as it does now.

            Could be completely wrong, and I hope I am, but this is the concern I’m trying to express.

          • Fair enough—and your comment here is the reason I don’t use fat arrow functions much. The rest of your article, however, I’m not so convinced by, even though I agree with your overall point!

  • Gord

    I’m scared of evolving specifications! And those C guys really give me the heebie-jeebies!

    This article is an admission of either ignorance or incompetence. Possibly both. Let’s hope it doesn’t trend.

    • You definitely got me .. sorta.

      1. If the evolving specs didn’t change the basic look of what a function is, I’d be at peace.

      2. I’m ignorant. Or incompetent. Possibly both.

      Here’s the thing though. Me learning won’t guarantee I’ll never be sharing or importing a code base from someone who is ignorant or incompetent. Today it’s me tripping up on these. Tomorrow its the new dev on your team.

      I admit ignorance, but I don’t think this means there isn’t an issue in the first place.

      • Gord

        Nah, you’re incompetent and irrelevant. I’d say “see you around”, but I absolutely won’t.

        • Good comeback. That made me laugh.

    • erye

      typical c guy raging on articles lol

  • I am unclear on the difference between an arrow and destructuring assignment. I don’t see how destructuring assignment is another way to declare a function.

    But if you want another way to declare a function, in ES6 transpilers, the class keyword creates a function, although it’s a function that cannot be called.

    • Exactly. I’m not sure the author of this article understands the specification.

  • Those three new functions are, well… silly. They’re the same thing. One of them, you’re using a block instead of an expression. A block is an expression. It’s the same way of declaring a function, you’re just doing a different thing in the function.

    The third way is also the same way of declaring a function, you’re just returning an array. The hell?

    Look at these two different ways of declaring a function:

    No. It’s the same way of declaring a function. You’re just returning an array with one of them…

    • arrows are very different from functions, so much so that I’m trying to get out of the habit of calling them functions.

      • Thanks for taking the time to comment. I’ve stumbled on your name in enough corners of the internet to know you’re a big deal in the JavaScript community. I really appreciate you taking the time to post here.

        I love JavaScript and clearly I don’t know enough about where it’s heading. It doesn’t appear as beginner-friendly as it did to me when I started. Maybe this is FUD driving me to write. I really hope I’m getting the wrong impression of what’s going on ES6-wise.

        I’m really curious what you mean by arrows are so different from regular functions you’re trying to avoid calling them functions.

  • I started to really learn JavaScript around the time ES5 landed. By the time ES6 landed, I had learned a few of the idioms and conventions and so it didn’t seem that opaque. Based on my own experience with the language, and I’m just getting started with ES6 syntax, it is a bit easier to write idiomatic JavaScript.

    I’m of a split mind on it (also called ES2015 for even more fuzziness). On one hand, I’m itching to explore the new syntax and see if it really improves anything. On the other hand, the syntax changes are enough of a departure from ES5 that its growing pains are going to be hell.

    It’s true that it hasn’t added anything to JavaScript that wasn’t possible before the spec. It’s also true that the syntax changes, after the season of ES6 to ES5 transpilers passes, are going to make authoring and reading code extremely hairy for a while. This is a sensitive time for ES6, because its cord has barely been cut.

    The arrow closure syntax is the most polarizing addition because it adds more considerations to an essential part of the language. The confusion comes from the fact that we’ve been using anonymous functions for closures for such a long time. It looks like another way to define a function (and will undoubtedly be used that way), but it doesn’t work quite the same.

    It’s why I now insist on calling it arrow closure syntax. It’s the only way I ever use it. And it’s honestly my hope that using an arrow closure as a standalone function will become a code smell, because it is a needless complication otherwise.

    It’s similar to the problem I have with devs thinking that let and const kills var.

    The thing that worries me about the new ES6 syntax: I don’t want it to become prescriptive. I don’t want a wave of developers writing with ES6 syntax just to show that they can use it without understanding why. That’ll make it harder for everyone. Harder to write, read, or learn.

  • rbrtsmith84

    Just to clarify here – Arrows are not meant to replace normal functions. Arrows do not have a ‘this’ binding and as such the ‘this’ value when referenced within an arrow will lexically access the ‘this’ value from the function the arrow was declared inside. This means you don’t have to add extra cruft to pass an outer functions ‘this’ value to an inner functions like if you are using a click handler or similar.
    This is very different to how a regular function works. both are useful. Arrows are an additional tool not a replacement.

    • Exactly, arrows are not a replacement for “function”.
      Do that and ur code will brake.

      The title of the article is misleading

    • Thank you for the clarification.

      In my casual reading, arrow functions primary benefits appear to be two-fold: fixed scope and cleaner syntax.

      Are there other tangible benefits I’m missing / ignoring?

      • rbrtsmith84

        Not that I know about. But I’d certainly spend more time learning ES2015 before dismissing it, there are many extremely useful tools. Possibly some bad ones too (Class). If you want more details on this then Kyle Simpson has a book published on ES2015 that is also available on GitHub.
        One thing I always see with developers is that as a whole we reject new ideas and change. It’s kind of a toxic mindset that we just want to continue using what we are comfortable with – it stifles innovation and progression. And ES2015 is definitely a step in the right direction for the language.

  • Shu Kin

    Agree. I’m a newbie, when I first time seeing something like “=>”this, I have absolutely no idea what it is is a function. But that thing could be considerd as a OK, since it smplify the script. The things that really make me sick is those 2000 and late program syntax such as “import xx from xx” or “class xx “, why we need them when people can simple use var xx = require(xx) and function(){}? All those thing just put so many limitation on a dynamic script programming, totally a nightmare for beginner.
    I think there maybe some other perfect way for evloving a programming language, but not like this, not like this…not like this

    • Really glad I’m not alone in loving require.

      Having a standard way of importing other code is great. Not sure I’m sold on class though … feels very forced and unnecessary.

  • protopop

    I am glad to see there are others who feel like I do. I have been worried that JavaScript will follow the same fate as Flash. Flash gained popularity with artists, animators and designers in part because it was very accessible to non programmers and quick to iterate. When ActionScript 3 arrived it brought a more programmer friendly syntax that alienated some artists. It may have been more logically structured, but that’s not how the minds of many artists work. Many of us ended up dropping flash for this reason. What I love about JavaScript is its accessibility, so while I can appreciate these new additions, I hope it continues to remain accessible to non programmers as well.

  • Turk Turkleton

    I agree. Writing code is not the hard part usually. It’s having other people read it and make sense of it that’s the hard part and all these weird looking short hands and symbols that don’t follow familiar C patterns is just a disaster waiting to happen.