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?
> 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?
This is why I like just using coffeescript. Nicer syntax than ES6, with the same speed as optimized basic Javascript (because that’s what it compiles to).
i have followed many of discussion on esdiscuss and unfortunately they were not paying much attention to performance, all too often the argument was: we need to get semantics right, thinking about the performance is the job of browser makers:(
"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
* 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...
They probably have improved since then; I should redo the benchmarks one of these days.
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).
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.
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.
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.
I don't hate JS, but I do find it a bit taxing to write JavaScript that might have bugs due to unexpected behavior in the language. I'm in the process of rounding out my self-taught programming mojo with some intro to CS courses, and the professor started talking about syntactically correct code. He gave the example of something like `3 + "hi"` being syntactically incorrect, saying it wouldn't run (in Python). My first thought on seeing that example was "JavaScript will run that!", and I didn't mean that as a compliment.
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.
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.
It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole.
Lua is better optimized because it is smaller. It's been the right decision to keep Lua small given where it specializes. Given where JavaScript specializes it's been the right decision to not keep it small but to evolve it. JavaScript is big because it can be big; it has the resources to make it so.
> It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole.
I think this is fundamentally wrong. I think you're confusing the language itself with how the language has been implemented.
Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.
These days JS generally gets JIT compiled and a tremendous amount of work has gone into improving the popular compilers. Lots of tricks are involved. These tricks are quite clever (though sometimes inelegant) and result in significant speedups. But they have nothing to do with the language itself.
Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.
If so, you're basically agreeing with parent, in parent's disagreement with this from further upthread:
Of course the semantics of a language can impact how easy/hard it is to write a fast implementation for that language. And as far as I know, there isn't anything special about the ECMA specification that makes it any harder to speed up compared to other languages in the same space (dynamic languages, whose specifications were written with an interpreter approach in mind).
Still, in my mind, speeding up any sufficiently dynamic languages with eval and metaprogramming without straying at all from the language spec is like "fitting a square peg inside a round hole." And I think that has been done successfully with JS, at the cost of making it harder to reason about how the compiler is going to treat my code.
Most code isn't using eval. It's okay if that part is slow. But even the most basic operations in javascript have all sorts of weird hooks that slow down evaluation. Most of it is little to no benefit to the programmer while a huge pain to the implementation.
Dart is just as fast, but getting there was significantly less work. Dart's semantics are more straightforward and the language was create with performance in mind.
The amount of work that went into today's JS engines is just insane.
Grabbing a few of the popular dynamic languages from the TIOBE index: Perl, PHP, and Ruby are also generally slower than JS. FWIW, neither Scheme nor Lua appear in the top 20 of the index, and of the dynamic languages in the top 10 — JS, Python, Perl, and PHP — JS is the fastest. I think "most" is a fair description, even though dynamic languages that have faster implementations than JS do exist.
Absolutely - multiple halfassed re-implementations of the same thing found in most languages std lib is a huge reason why the language is bad (remember the left pad fiasco ?), but the semantics of the language make it fundamentally flawed without breaking backcompat. JS ecosystem is actually quite bad when it comes to functionality - but they do have 10 versions of same thing for stuff they do have and each of those works only in specific scenario it was written in but nobody bothers to extend it and writes their own instead when they need to solve something similar because reading other's people JS is a nightmare.
If anything the kind of breadth JS ecosystem has shows just how hard to maintain other people code is.
What a gross over-generalization. Yes there are crap libraries just like any popular language. There are also great libraries just like any popular language. If there are multiple for the same purpose, it is usually obvious which is the best one.
Since you brought up the left pad thing, yes there is a small minority within the JS community that takes the Unix philosophy of "only do one thing and do it well" to an absolute extreme. But that isn't indicative of the JS ecosystem as a whole.
>There are also great libraries just like any popular language.
Mind naming some ? I work on Angular 2, React and TS front end in my day job - those libraries are a joke compared to similar libraries in other languages. For example Angular 2 Dart is a huge productivity improvement - having done a prototype with ng2 Dart and implemented a full app in TS having a language with sane semantics, actual standard library and a build system built by someone who knows what they are trying to do vs someone who hacked something themselves and everyone kept piling on. React compared to something like Clojure + Reagent is a similar comparison although CLJS tooling is much less mature than Dart - just dealing with immutability in JS/TS is so tedious and full of boilerplate.
Just recently I had to find a library that will let me pattern match URLs and extract parameters (eg. 'foo/:a/:b(?foo=:c&bar=:d)' => {'a':..., 'b':..., 'c':..., 'd':...}) - and every option out there failed to work with anything beyond basics and the implementations were horrible - and this is JS core competency.
You are claiming that JS libraries are crap but then you like clones of Angular, React, etc but in a different language? You don't have to like JS, but it seems to me that you answered your own question: "Mind naming some great libraries?"
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.
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?