ES6 is Over-Engineering JavaScript

Don’t let acronym fool you. npm is more than node’s package manager; it’s the package manager for all of JavaScript.

It houses great big libraries like React, Electron and It also contains itty-bitty snippets of code. Code so small you’d expect their behavior to be native to the language.

This has turned JavaScript into a language with a small, serviceable core and lots of useful extensions available in npm.

ES6 is expanding the core of JavaScript.

Not by adding things that currently don’t exist in the JavaScript + npm realm, but by introducing new ways to do things we could already accomplish before.

This seems like a very bad idea to me.

On a package level it’s perfectly fine to have overlap. Packages compete on API, implementation, performance and reliability. This is expected. Preferred even. Overlap in functions and syntax is totally ok. It creates fragmentation, but it is not compulsory. I can pick between lodash and underscore. I can choose neither. Everything is awesome.

On a language level, overlap is a problem. If there’s more than 3 ways of doing a thing, I must know all three and everyone I’m working with must know all three.

The more ways there are to do a basic thing, the more ways there’ll be to screw up. More pointless arguments over style, readability and execution. Syntactically correct versus better.

I feel JavaScript should have a simple API with a defined package manager where you can access code that allows you to do more.

Nothing I’ve seen about ES6 is impossible to accomplish in ES5. These changes really should have been packages officially blessed by the committee in charge of pushing JavaScript forward.

Imagine going on npm to look for a way to manipulate arrays and finding a package with a “recommended by the JavaScript Working Committee” badge.

Although this means a less-than-stellar standard library, I feel this might be a better way to progress JavaScript. Maybe I’m completely wrong. What do I know about making a language?

All I’m certain of is ES6 is over-engineering JavaScript. I really hope I’m wrong but I think this is a very bad thing.

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

  • Josh Burgess

    It’s not all bad. ES6 also brings tail call optimization, making functional programming in JS a more viable option. I also think things like lambda expressions (arrow functions) & even the newly proposed |> (pipe) operator are very useful things to have.

  • I find the argument “nothing I’ve seen about ES6 is impossible to accomplish in ES5” problematic, because you could also use it to argue in favor of assembly language instead of JavaScript. Much in ES6 is about comfort and unifying a currently quite fragmented ecosystem (many inheritance libraries, AMD vs. CommonJS, etc.).

    Three features that you can’t emulate in ES5 (in a straightforward manner): proxies, subclassable built-in constructors (e.g. Error and Array), tail call optimization.

    WeakMaps, let/const and generators are also far more than just syntactic sugar.

    For more information on why ES6 modules really do bring completely new things to the table, check out “The importance of import and export”.

    • Théo FIDRY

      Also “If there’s more than 3 ways of doing a thing, I must know all three and everyone I’m working with must know all three.”: there is so many way to create an object or a class instance, at least the new `class` keywords helps to get it straight even if it makes cringe every functional programmer because that’s easing OOP in JavaScript.

      And I won’t thank enough ES6 for bringing modules, WeakMaps, let and const. So much nicer.

      • I tend to avoid classes so the benefit ES6 brings there is lost on me.

        Doesn’t make it any less of a legitimate benefit so .. I’ll accept my loss on this point.

        • If you are using functions, you are, in a way, using classes. Are you talking about inheritance?

          • I’m not sure I understand what you meant by “If you are using functions, you are, in a way, using classes”.

            Could you please explain what you meant?

          • A class is defined as a template that creates object providing initial values and encapsulating behaviors.

            That’s a function my man. It might not be your “Java” or “C#” class. But at a conceptual level? It is.

            Think about “Java” or “C#” class for a minute. What is the constructor but a method/function? It just returns itself.

            The other functions on your class? Well… they are automatically attached to your object when created. Just like it can be done with Javascript functions. 🙂

          • > The other functions on your class? Well… they are automatically attached to your object when created. Just like it can be done with Javascript functions. 🙂

            Keyword being “can be done”. JavaScript functions don’t automatically enforce you carrying all this baggage around.

            Even if you look past that point, these functions are stateful and can’t really be reused. That’s a waste.

            I just came across an article that explains my dislike for classes from a different perspective. Hope it helps shed light on where I’m coming from.


    • Thanks for taking the time to explain to a complete newbie.

      Admittedly I know nothing about weak maps, but I’m sure there’s much more for me to bone up on.

      Thanks for the link and more importantly using the time to help me learn more 🙂

  • Rory Bradford

    The problem with JavaScript here is “don’t break the web”, what’s already there, good and bad, logical or broken HAS to remain.

    • This is a great point.

      Some browsers well never get ES6.

      Is Babel now a permanent build step for writing JavaScript in the browser?

      • LPGhatguy

        With evergreen browsers being the new norm, ES6 features will eventually be implemented by a significant enough base for actual use. The days of browsers like IE 6/7 plaguing the world for more years than they should are over.

  • stakamur

    It is an important point of view because otherwise our codebase of JavaScript can be mess. What if one of our colleague says “I won’t use let/const and class, var and prototype are enough for me.” ? Or, someone can say “I use newer syntax only because it’s cooler/shorter to write”.

    That’s why we need a lint tool. ESLint encourages us to use newer syntax such as let rather than var. I want ESLint to be enhance more. Or a coding style guild considering of new syntaxes might be also nice.

    We need solid rules to restrict “3 ways of doing a thing”. Managability of codebase and runtime speed should always take a priority to everything. And yeah I believe most of additions to ES6 meets the condition 😉

  • As Axel said weakmaps go beyond being syntactic sugars. There’s huge performance benefits and more from using them. Template strings are also very relevant and I don’t see a way to do them in ES5. Would you rather concatenate variables with strings when the use-case does not warrant a complete templating package like handlebars. How do you find doing this: 'My name is '+name over this `My name is ${name}`?

    • oh I forgot default parameters in functions too

  • Pingback: ES6 is Over-Engineering JavaScript | DrFoxyCleo()