0

Does using the ES6 shorthand syntax add a layer of abstraction, and thus slow down the interpreter?

If you look at:

const myFunction = (myPar) => {...);

vs.

const myFunction = myPar => ...;

You would think that the second example needs to be translated back to "regular" Javascript first before it can be interpreted. If this is the case would it be best to avoid it?

.

If I made any mistakes or this question is too trivial please correct me.

Barmar
  • 741,623
  • 53
  • 500
  • 612
Radllaufer
  • 187
  • 1
  • 2
  • 10
  • 1
    I suspect your first example was meant to be the original non-fat-arrow syntax? – Daniel Beck Dec 18 '20 at 19:33
  • The two things are the same. The only reason that `()` would be required on the arguments is if you have multiple. Edit: This is ignoring the difference of `{}` vs no `{}` – Taplar Dec 18 '20 at 19:34
  • Both are valid functions that do *potentially* different things. If both just return a value, I don't see how you expect the performance to be different. Also see [Which is faster](https://ericlippert.com/2012/12/17/performance-rant/) – VLAZ Dec 18 '20 at 19:34
  • 3
    In any case this is a classic example of premature optimization; if the demands of your application are so great that performance differences on this level are significant, you probably don't want to be working in javascript in the first place. – Daniel Beck Dec 18 '20 at 19:35
  • Keep in mind that the point needs to be made that this **is not shorthand**. A fat arrow method is not equavilent to a normal method. https://stackoverflow.com/questions/34361379/are-arrow-functions-and-functions-equivalent-exchangeable – Taplar Dec 18 '20 at 19:38
  • What's the difference between them? Are you asking about the parenthesis around the parameter or implicit return in the second function? And, both of them are arrow functions. There's no preset where only one of them is transpiled. – adiga Dec 18 '20 at 19:41
  • Unless you use something like Babel, there's no translation being done. The different notations are all implemented directly in the JavaScript compiler. – Barmar Dec 18 '20 at 19:57
  • Why do you think only the second example needs to be translated? They're both arrow functions, which were added in ES6. So either they both need to be translated (and they should translate to the same thing) or neither does. – Barmar Dec 18 '20 at 19:58
  • 1
    @Rounin It's not the same. `=> { x = 3 }` does not implicitly return the result of the statement. `=> x = 3` does – Taplar Dec 18 '20 at 20:07
  • Ohhhh. Yes. You're right, @Taplar. I'm so used to manually doing all my returns, I forgot all about implicit returns. – Rounin Dec 18 '20 at 20:09

2 Answers2

2

Does using the ES6 shorthand syntax add a layer of abstraction, and thus slow down the interpreter? You would think that it needs to be translated back to "regular" Javascript first before it can be interpreted.

No. First and foremost, ES6 is regular JavaScript and has been for more than 5 years.

But really, what is interpreted by a JavaScript engine is not source code as text, and there is no translation from one format to another. The interpreter parses the text into some intermediate representation and then executes that. All the different ways to define a function are parsed directly into the same intermediate representation (apart from flags for the minor semantic differences that the execution needs to follow).

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
1

First and foremost there is no such function definition syntax in ES6.

const myFunction = (myPar) => {...); // As there is No closing bracket at the end

And If you mean const myFunction = (myPar) => {...}; with the closing bracket.

Then your next function, which is

const myFunction = myPar => ...;

is similar to the first one. Just that it has an implicit return. So 2nd function has implicit return and the first function will require a return keyword to return any value Explicitly

And yes, there is no such additional abstraction in ES6 arrow function syntax :) So, no performance issues at all.

Imran Rafiq Rather
  • 7,677
  • 1
  • 16
  • 35