Eww… ES6/CoffeeScript/ES2015/Harmony/TypeScript

by  on  in Programming • 7,146 Comments

That fact that it has so many names should be enough to inform anyone that ES2015 is grossly over complicated. I enjoyed learning JavaScript because it was so easy to learn. Now they are trying to convert it from a web language to a hardcore programming language like C#. So… I don’t like ES2015 and I’m not the only one.

The other day I tried to use ES2015 for one of my new projects and it was so painful, I quit. I decided to use ES5. ES2015’s over complicated design got the best of me. I mean, ES2015 has arrows… =>, why? Why do I need these, this just complicates the code and makes it less readable. I spent the majority of my time trying to import modules using a umd standard. When I found out you needed to import each component of the module separately I decided I had made the wrong choice.

There is a reason Arch Linux is best Linux distro, it follows the KISS ideology. Everything in ES2015 is comprised of so much garbage and complexity. JavaScript is not known for complexity and it shouldn’t be. I would like to point out 2 additions in ES2015 and why I especially don’t like them.

Template Strings –

Seriously, why would I want to use a Bash syntax like ${name} in order to do sterilization. If want to protect against injection attacks I’ll use one of the dozens of sterilization libraries on npm. I mean just look at this example, wtf is going on here?

// Unescaped template strings
String.raw`In ES5 "\n" is a line-feed.`

// Construct an HTTP request prefix is used to interpret the replacements and construction
GET`http://foo.org/bar?a=${a}&b=${b}
    Content-Type: application/json
    X-Credentials: ${credentials}
    { "foo": ${foo},
      "bar": ${bar}}`(myOnReadyStateChangeHandler);

Why can’t I do what I’ve always done?

// Construct an HTTP request prefix is used to interpret the replacements and construction
get('http://foo.org/bar?a='+sterilize(a)+'&b='+sterilize(a)
    Content-Type: application/json
    X-Credentials: sterilize(credentials)
    { "foo": sterilize(foo),
      "bar":  sterilize(bar)}', myOnReadyStateChangeHandler);

It’s easier to understand what’s going on in my code and I’m probably going to do it even after ES2015 since the internal sanitization doesn’t do all of what I want to.

 

Module Loader –

I seriously hate this feature. It took what Require/CommonJS and node.js did great and implemented a python like import system. Seriously? You took a good system and used a full fledged programming languages module system. Why can’t use just do var angular = require('angular')? And if we really need to import components from modules we have var component = require('angular').component. This system is so much simpler.

 

 

Even after my rant, there are a few things ES2015 gets right, and I mean very right.

  • Promises – Amazing synchronous code construction. I will never go back!
  • Lexical this – Allows an object to reference itself during initialization. Something I tried to do before I found out you couldn’t.
  • Defaults – The syntax is perfect. Looks like what it does. I think I also tried to define defaults this way when I was learning JS. If something is intuitive, it makes sense to add it.
  • Let and Const – Doesn’t break anything (in most cases) if it’s not used. Kind of like an upgrade. Simple concept and gives developers simple and enhanced tools.
  • Math, Number, String, and Object APIs – Adds more simple functionality and no syntax changes. Nothing complex. — Although, you could say use a library of your choosing if you wanted this.

 

let futureJavascript = () => {
    let ES2015 = 'awesome';
    console.log(`The future of JavaScript is ${ES2015}`);
};

Oh, now I understand why I should jump on the bandwagon. It’s so simple to understand. let futureJavascript = () => {

 

People say ES2015 is a step backwards and I agree. It attempts to destroy the language I love and it’s over complicated!

Leave a Reply