Is ES6 Needlessly Obfuscating Code?

Planet Earth
1

There’s an excellent ES6 learning tool at http://es6katas.org/. Here’s the one for arrow functions:

http://tddbin.com/?491#?kata=es6/language/arrow-functions/basics

I notice a lot of syntax options.

  • You can return without curly braces if the results is a single expression
  • You can drop parens around the params if there’s only one param
  • You can drop parens around the function body in most cases but not if you’re returning an object

All these syntax variations are a needless obstacle to learning, because arrow functions in sample code can have many different syntax variations when you see them. And then, once you do know all the variations, there’s the mental context switch you have to apply to figure out what variation you happen to be looking at at the moment. One reason we code apps in Javascript is to avoid the context switch of working in one language on the client and a different one on the server. But now the Javascript standard is forcing context switching back onto us in their language spec.

Is ES6 a step forward or a step backward for Javascript? I look forward to hearing people’s thoughts.

6 Likes
2

I’m completely with you when it comes to learning materials. In my apps I use the airbnb eslint config which actually forces me to use all variations depending on the context.

I really value the conciseness, but for learning to code this can be an issue.

I was teaching Apple Swift in school and I had a hard time explaining the type inference and closure syntax.

It will only get worse with ES7’s decorators and the async/await/promise possibilities in asynchronous code.

3

To answer your question I think it is a step forward and js must get richer in terms of language features to keep up with that big apps we now develop in that language. On the other side, learning js will take longer. I started with coffeescript because of the relatively strict ways how to use loops, control flow, undefined et al. and then switched to plain js.

1 Like
4

I’m an avid language (both human and programming languages) learner. I love learning the similarities and differences between languages.

There are many types of improvements to a language. You can make grammar simpler, or make it more complex. You can add more words, or remove obscure ones.

Javascript’s changes from ES5 to ES6 are grammatical, and not for the better. From all the documentation I’ve read so far, they have added grammar more than they have added words (functions), meaning they have made the language more complex, instead of making it richer.

There is a whole library (two, actually) of functions (underscorejs and lodash) aimed and fixing the weakness of javascript that is the missing functions. There are probably things you can do with a single function in PHP or Python for years now, you still can’t do in Javascript.

Also, some things are in browser vendors’ hands. For example, IE to this day does not support Sets (array where elements can’t repeat).

But then again, it was written in 10 days.

1 Like
5

Glad I’m not the only one feeling this way. Sometimes I look at this stuff and think, maybe people are going a bit too far. I’ve always though ES5 hit the sweet spot for app development.

6

I thin ES6 is step forward but I also agree that sometimes code could look a little bit ofuscated if you are not used to. I think is a matter of time.
For me, i’ve been a professional JS developer only for 1,5 years and that’s why i don’t have the “old vices”. Therefore, I get the new syntax really quickly, because it was part of my learning process.
But i think this:

const f = x => y => z => x + y + z;
is better than this:

const f = function (x) {
    return function (y) {
        return function (z) {
             return x + y + z;
        }
    }
}

But you need to get used to see it.

Same with destructuring, rest/spread operator etc. It makes things shorter, and if you se a functional approach, it makes things easier. 1 line functions that read like math, natural

2 Likes
7

I think the arrow function in ES6 is one of the best features. However, I do agree that it can be very confusing to read. I kind of wish the parens for the params were required as making them optional can make it harder to read… and lets be honest, we end up reading written code more than writing it.

I think you just have to learn enough to understand it and then apply a set of rules for your team so everyone is using the same code style (making it just as easy to read others code as yours). I always find it refreshing to use languages who favor explicit over implicit… unfortunately JS is not one of those.

Array functions can make code easier to read when used properly…

numbers = [1, 2, 3, 4];

evenNumbers = numbers.filter((num) => num % 2 === 0);


// almost harder to read

evenNumbers = numbers.filter(function(num) {
  return num % 2 === 0;
});

De-structuring is kind of weird until you start using it… then it can be really useful to make you code easier to read. I didn’t fully appreciate this until using Elixir which heavily uses it (though they call it pattern matching). I use it a lot in React to reduce the verbose this.props.postId to postId which I think makes it easier to read.

render() {
  const {postId, user, url} = this.props;

  return <div>{user.name}, Your post ID is: {postId}</div>;
}

// instead of

render() {
  const postId = this.props.postId;
  const user = this.props.user;
  const url = this.props.url;

  return <div>{user.name}, Your post ID is: {postId}</div>;
}

Is ES6 a step forward or a step backward for Javascript? I look forward to hearing people’s thoughts.

I do think ES6 classes are a step backward because JS does object oriented programming so so poorly compared to C#, Java, Ruby, etc… It’s really a joke. The new syntax just puts lipstick on a pig IMHO. However, JS seems to be able to do the ‘functional’ pretty well (except for mutation of data but hey… maybe that’ll be ES8 lol).

2 Likes
8

Like what ?

(filler space to make the forum happy)

9

I would argue the opposite. ES6 allows me to see exactly what’s happening in a file and how it relates to other files. You’re right, though; the syntax for arrow functions is not very opinionated, there are a handful of valid variations. The spread operator is a bit too opinionated, and I often find myself using in a way that should be possible, but isn’t. I believe classes in ES6 do a good job and canonicalizing object-oriented programming in Javascript. Before, there were a few different patterns, which all seemed super hacky. @vjau One thing in Python that would have been nice are list comprehensions, but it’s not a huge bummer that ES6 decided not to go with them.

10

I do not use Javascript on server-side; and I’m not a Javascript expert, but here are a few examples:

number_format(), array_walk_recursive(), array_diff() in PHP. I’m not saying these cannot be done, I’m saying these do not exist (as far as I can remember, of the top of my head).

I did not understand the part about filtering space. Do you mean to not use empty lines? If that’s it, I do not understand how that will make the forum happy.

11

You’re right that some things aren’t directly in Javascript, but their are some really powerful libraries out their. For number formatting you can use numbro, which is like moment for numbers. See the power on their website: http://numbrojs.com/format.html. I wish moment and numbro were parts of Javascript, because I use them for 90% of the projects I work on, but these libraries will do just fine for now.

About ES6, I really like the destructuring, arrow functions, default parameters and other things that reduce boilerplate. It takes some time getting use to, but now I wouldn’t want to miss them.

Classes is a different story though. Because they’re not the classes like in OO classes. It’s still prototype inheritance. Maybe we shouldn’t hide that and act like we’re all Java-ish now. The more I use them the more I understand why people do functional programming these days…

12

Agreed. There are some functionality you use pretty much every day, and most of them are not part of Javascript; and that is exactly the point of my original post: Javascript is developing more in terms of grammar than vocabulary (function richness). For someone who knows multiple languages (human or programming), that’s a pain point.

And that in turn makes some things much slower whether it be server-side or client-side. If Javascript added more functions to its binary, it would run faster, produce and process results faster, … Compiled code runs faster than interpreted code, and Javascript is an interpreted language.

Aside from the interpreted/compiled issue, Javascript right now is like a language that has a hundred grammar rules, and a hundred words, whereas it should be a hundred grammar rules, a hundred thousand words. More rules do not make a better language. More words (functions for programming languages) make a better language.

Did I rant too much? :slight_smile:

13

This is more complicated than that.

The features you are requesting are usually not part of the “language” but of the “standard library”.
Javascript has no real standard library, but the gazillions of library offering corrects that.

2 Likes
14

Precisely. It has no standard library, instead, it has gazillions of libraries written in Javascript.

Every function written in Javascript instead of C/C++ makes a language slower. Unless you f* up the C code, the C code will run faster. No denying that. It’s the same with PHP. Write a function that walks (JS equivalent is map) the elements in the array in PHP, and write the same function in C (and embed it in the PHP binary); the second one will run faster (again, unless you f* up the C code). Always.

As I said, it has a hundred rules, and a hundred functions; it should be 100 rules, 100k functions. (I hope we don’t have people smart enough to start discussing the 100k made-up number).

Every function that you have to emulate using Javascript instead of a simple native-function call means slower results.

Also, I didn’t know how to quote that too, but; yes, Javascript is an interpreted language. In the first link you mentioned, it says Just because it gets compiled on every run, it does not mean it is Interpreted. There is one problem with that sentence. It is the literal definition of interpreted. Every language implementation, including Javascript, that reads the source code or an intermediary code that is not a native executable is interpreted. Mind you, even languages that do not produce operating system level binaries are called interpreted languages.

For example, Swift, C++, C, Pascal, Assembly, are compiled languages. There produce OS-native binaries that does not contain the source code. On the other hand, Python, Ruby, Java are all interpreted languages, because they produce a bytecode that is somewhere between machine code and the source code.

The second link you provided mentions also that the specification does not say interpreted or compiled. Well, of course. If it did, it would be an implementation, not a specification.

So, you can of course move this argument to differentiate between the specification (the grammar rules of the language) and the binaries that process code written in that language; but that would pretty much be a non-practical discussion, because specification is abstract, and is meaningless until you write software that turns that specification into practice. No language specification can specify (shouldn’t anyway) if a language is interpreted or compiled. Because interpretation and/or compilation are binary operations, and have nothing to do with the abstract syntax tree (basically, the specification) of that language.

When the output of a language processor is something that can be run without that processor and the source code, the output is said to be compiled, and the binary that produced that output is called a compiler. Producing an independent binary is the definition of compilation.

An compiler is a binary that goes over all the included code, and does certain checks before running the code. Let’s say you put . where you should have put ; somewhere in a file that gets included under certain conditions. Will the binary that runs Javascript code notice that before starting the final run operation, or will it not? Here’s your answer: It will not, not until it actually needs to interpret that file. That is one of the other properties of an interpreted language.

Alas, if you want to believe Javascript is not an interpreted language, you are free to do so.

In the end, yes, ES6 is needlessly obfuscating code, creating more grammar instead of creating more functions. More grammar makes a language richer, but most of the time, not as much as a word/function.

1 Like
15

Since the “interpreter” (JIT compiler) is “compiling” your js code to machine code, why would the “native” functions that have been compiled by the C++ compiler be faster than those that have been “interpreted” by the JIT compiler ?

What is the cause of the difference of performance between Java and Javascript ? Is it because Javascript is “interpreted” or because Java works with static typed variables ? If the second explanation is the right one, why would C++ code working on dynamic type variables (like in your php example) be faster than compiled JS code working on the same dynamic type variables ?

16

Flowchart: “Deciding if and how to define an ES6 arrow function”

https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/fig1.png

803×1040 35.3 KB

7 Likes
17

Not only is JavaScript sintax convoluted, the ecosystem is as well. There are so many new tools and libraries that accomplish nothing but wasting time. The irony is that these tools are built to save time. But how many hours do you spend browsing npm? And in the end is it worth it?

4 Likes
18

A compiled for loop will work with registers (as much as possible), a compiled integer addition will perform the operation using registers and ADD machine code (as much as possible). Most of the time, that is the base reason for the speed difference.

Whichever is faster, and whatever the reason, I do not understand why we are discussing this. Interpreted languages are pretty much always slower. This is a generalization that is true most of the time. This is known.

Even compiled languages amongst themselves, and interpreted languages amongst themselves, differ in terms of speed and/or memory usage. If you have worked with both PHP and Python for a long time, you will know that PHP is generally faster. If you have worked with C++, you will know that it takes a long time to compile a C++ program, but it runs way faster than PHP code that does the exact same thing.

Why are we even spending time whose (interpreted languages vs compiled languages) is bigger?

If you are expecting me to cover every possible case for every possible programming language, thanks but no thanks. We could discuss this for months, analyze 50 languages’ output on various situations with multiple algorithms, and not have definitive results on who (interpreted languages vs compiled languages) beats the other.

We have strayed meaninglessly away from the main discussion. I will not spend any more time on interpreted vs compiled. You are free to believe whatever you want. Just please stop trying to fix me.

19

And how do you do that with dynamic typed variables ?

Yeah, and v8 javascript is faster than anything else “interpreted”. Which bring us back to the main point of our discussion, which was to say that native php functions were much faster that js libraries, which has yet to be proven.

Ok, professor.

1 Like
20

I think it’s worth mentioning that a lot of (all?) the new syntax forms in ES6 have antecedents in other languages, i.e. Linq lambdas in C# which have the same rules for omitting brackets as in ES6. So I think it would have made less sense if they’d purposefully gone against existing conventions from other C-based languages.

After all, if you don’t want to omit brackets, you don’t have to. Just because the language is unopinionated doesn’t mean you or your team have to be.

1 Like