
High-Speed ES2015 - tilt
https://docs.google.com/presentation/d/1wiiZeRQp8-sXDB9xXBUAGbaQaWJC84M5RNxRyQuTmhk/edit#slide=id.p
======
arximboldi
I am very surprised with the stuff shown in this talk. One would think that by
using a more explicit syntax, the compiler/interpreter has more context to
optimize and do things _faster_.

Looking at the destructuring example, it seems like part of the problem is
that the new constructs are actually more general, since their semantics are
defined in terms of iterators in order to support user defined types... I
guess, on the other hand, this still allows for better overall system
performance (e.g. one can now pass lazy-evaluated transformations instead of
producting new arrays all the time when writing functional-style code.). An
alternative would be to have sepparate syntax [a, b, c...] for arrays and (a,
b, c...) for iterator based destructuring. There is the risk then that then
everyone starts using the former syntax for the sake of premature optimization
and we end up with over-restrictive API's that then disable the opportunities
for lazy-evaluation and so on described before.

Definitely and interesting case. It would be nice to be able to read some of
the discussion of the standardization process and see how these performance
trade-offs where considered. Anyone has some pointers?

~~~
magicalist
> _It would be nice to be able to read some of the discussion of the
> standardization process and see how these performance trade-offs where
> considered. Anyone has some pointers?_

There's the mailing list at [https://esdiscuss.org/](https://esdiscuss.org/)

More recently there's been more discussion around specific proposals in github
repos under the tc39 org: [https://github.com/tc39](https://github.com/tc39)

And Rick Waldron takes TC39 meeting notes in this repo:
[https://github.com/rwaldron/tc39-notes](https://github.com/rwaldron/tc39-notes)

------
sjrd
"We want you to help us! [...] Ideas for real ES2015 performance test suite."

* Take a language that compiles to JS, with the option to target either ES5.1 features or ES2015 features. For example, Scala.js.

* Take a macro-benchmark suite, or an application with measurable performance metrics, written in that language. For example, [https://github.com/sjrd/scalajs-benchmarks](https://github.com/sjrd/scalajs-benchmarks)

* Run the benchmarks when targeting ES5.1 (default in Scala.js) versus ES2015 (with `scalaJSOutputMode := OutputMode.ECMAScript6`)

* Enjoy the slowdown :-p

I did that 1.5 years ago when I was developing Strong Mode support for
Scala.js (now defunct). Results were awful at the time:
[https://groups.google.com/d/msg/strengthen-
js/Bfa_HPhVbiY/yM...](https://groups.google.com/d/msg/strengthen-
js/Bfa_HPhVbiY/yM40rvnoP9kJ) They probably have improved since then; I should
redo the benchmarks one of these days.

~~~
aluxian
Why is Scala.js "now defunct"? Any source?

~~~
raquo
sjrd is the author of Scala.js, he meant that strong mode support is now
defunct, not Scala.js. Scala.js is doing great!

------
shakna
As much as these speed improvements to Node are awesome, and the team have
been doing a great job...

How is only a 1.2x speed regression acceptable? For... Syntactic sugar? [0]

[0]
[https://docs.google.com/presentation/d/1wiiZeRQp8-sXDB9xXBUA...](https://docs.google.com/presentation/d/1wiiZeRQp8-sXDB9xXBUAGbaQaWJC84M5RNxRyQuTmhk/preview#slide=id.g1b84aeb97c_0_2)

~~~
espadrine
It is explained on the previous slide. It _looks like_ syntactic sugar, but it
is actually a much more complex feature that involves iterators (which
potentially requires several function calls if it is a user-defined iterator).

And even with optimizations that detect when it is a well-known fundamental
iterator (like an Array), you still have to pay for the detection (after all,
you might have an eval that calls this function with a non-Array, and Array
can be monkey-patched).

~~~
rubber_duck
JS semantics are garbage both for writing code and for optimizations - and all
new ES standards just keep piling on top instead of fixing it for fear of
breaking backcompat. WASM with GC can't come soon enough.

~~~
Touche
And yet JS is faster than most other dynamic languages. Pretty good garbage if
you ask me.

~~~
tfar
That is not a sign of the quality of the language though. It is more a sign of
how much money went into making a poor quality language perform well. Compare
the speed of JS JIT VMs to Lua JIT VMs considering the investment respectively
for example.

~~~
lisivka
M$ and Google tried to undermine JS with their own languages (VisualBasic and
Dart) but failed. Why such rich companies cannot make a better language?

~~~
ergothus
It's not about language quality, it's about barriers to entry. You not only
have to be "better" than JS (which I guess means some combination of
performant and pleasing to code), but you have to do so to such a degree that
it's worth losing access to/reimplementing the existing libraries, not to
mention getting multiple browsers to implement AND getting everyone to install
the newer versions of said browsers (not as bad as it was, but still an
issue).

I currently do JS for a living, and I don't hate it, but most of the reasons
to DO javascript coding have nothing to do with quality of language and
instead have to do with how unlikely a viable competitor is to come about
anytime soon.

~~~
lisivka
Of course, I know that. But companies are rich. They both have their own
_major_ browsers. They can just pay to Mozilla and Apple (two remaining major
browsers) to support their language(s). Libraries are not a problem for .Net,
Go, Swift, Rust.

So why M$ and Google cannot beat poor javascript?

~~~
Dylan16807
What's money going to do? Unless you're suggesting they bribe millions of
developers to switch.

Some things can't be solved by throwing money at them.

~~~
lisivka
All four companies have success with their own programming languages, which is
not an easy task to do. Some of them are also succeed with their own OSes too,
which is even harder. They CAN replace JS if they push a language strong
enough. They cannot do that because replacement languages are worse than JS.

------
synthecypher
Any videos of this presentation would love to see them.

------
i336_
Tangential: the number of anonymous viewers (hovering around 50) is an amusing
juxtaposition with the small "Proprietary" in the bottom-right corner of all
the slides.

