I see a some people are fascinated by ES6/TypeScript/React (and the like)/Babel/Webpack features. However, not all the gold that shines. Let me explore couple of areas from my perspective and experience.

ECMAScript 6

Arrow functions

One of the most feature that I have no idea what was the purpose of invention. Most of the opinions says that it simplifies the code and solves the problem with this context. While I appreciate solving the problem with this then I strongly disagree that it simplifies the code. The main objection is that I claim that we should always use words to describe the meaning and not symbols.

The word function perfectly describes the meaning of the block. There is no need to replace programming words by symbols. First thing to think about it while programming is to find the answer to who you writing the code? I write first for the humans because machines doesn’t care about that. In other words: make the source code human readable.

Arrow functions doesn’t solve the problem with readability, but rather makes it harder to read as the word function has been replaced by symbol => and your brain needs a little more time to process the symbol than simple word. An example from Eric’s tweet:

const map = (fn, arr) => arr.reduce((acc, item, index, arr) => {
  return acc.concat(fn(item, index, arr));
}, []);

Does that looks really like a highly readable code? If so let’s use our imagination and make it even shorter and replace Array methods by symbols.

const map = (fn, arr) => :.((acc, item, index, arr) => {
  return +#(fn(item, index, arr));
}, []);

What I’d do is to use simple named function word and extract all the functions outside. Named function has also benefit as it’s clearly visible in the stack trace and therefore it increases a readability (the page is deprecated, but the tip is still valid).

Classes

If anyone thinks that ES6 classes works in the same way as in Java or Ruby then no – they are not working in the same way. They are just syntactic sugar on top of what we had before. Read more about that in article ES6 classes and JavaScript prototypes.

Shorthand property names

Object literal property value shorthand lets you abbreviate the initialisation of a property within an object literal, provided that the property key matches an existing variable name.

Example without shorthands:

const myObject = {
    a: a,
    b: b,
    c: c
}

However, in most cases the objects contains rather mixed data and now it becomes like spaghetti:

const myObject = {
    a,
    b: 1,
    c,
    d: false
}

This is just a simple example, but in reality objects contains more complex data and using shorthands makes it only harder to read. Object is a collections of properties and values and therefore that’s how it should be written in order to make it easy to read and understand.

TypeScript

TypeScript has some advantages, but dark side needs to be known as well.

Strongly-typed

By specifying the type of objects your functions expect you can reduce the risk of unexpected results. That’s just only on compile time. It doesn’t apply on real, final code. TypeScript is transpiled to ES5 and if you look more closely at the results then you’ll realise that it does nothing in fact. So, you can write:

public myFunction(data: object) {
    // I expect "data" as a object type here
}

My IDE (in my case Visual Studio which I use for TypeScript) can only gives you a warning when you want to pass anything else than just an object to the myFunction. But in fact when you compile the code then you’ll see that there is nothing extra in the function myFunction when it gets compiled. You can pass any data you want and if it’s not an object then it will throw an exception when you try to access to an object object property.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Comments

You can leave a response, or trackback from your own site.

Before you add comment see for rules.

Leave a Reply

Your email address will not be published. Required fields are marked *

2w0x9m