What’s New in ES2019 (opens in new tab)

That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it.

If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm sure that if you still have to write javascript code 10 years from now you'll be happy to be able to use the features of ES2019.

Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

>If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal.

For one, not everyone works on the client. I can write for Node and use everything v8 supports without ever touching Babel and Typescript.

>I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.

Good parts/best practices are orthogonal to native features and libs, which is what we're discussing here.

IMHO the current state of affairs is actually the best possible scenario.

- Experimental language proposals can be tested in the wild

- Real non-ivory-tower feedback is raised to TC39

- Everything feeds into the canonical ES spec (~no splintering)

- Us regular folk are able to harness new syntax immediately

- Users continue to have their old runtimes supported

As a purely backend engineer with a passionate hatred for NPM, I love writing ES6 and native javascript. All of the newer features (tbh, I don't know which are new but I guess 'const', 'arrow functions', 'default parameters', 'string interpolations', 'filter/map' are definitely a few of them and made javascript more like the back end language that I work with). I wrote at least a thousand line of native javascript for the monkey scripts and my personal websites and I consider the experience a good one. I applaud the advancement of the javascript language itself and I consider the package management the source of all evil for javascript.

From my perspective, it is less about what we can use in the browser without transpilation, but where the js ecosystem is heading. I personally only want to write JS that is in spec because in 5 years something like decorators might not be a thing. Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I think there's a lot of momentum with the spec and something to point to where can say "you should learn this syntax/feature because it's in the spec."

Different products/teams can move at different speeds if they target a specific market. For example, for internal apps teams can expect that browsers are up-to-date, or that even only a specific browser will ever run the app. Also, people who write JS for back-end (eg node.js) or an embedded engine can control the environment their code runs in, and can use more up-to-date features.

It’s similar to all the new tweaks and elements in HTML or DOM. If you’re working on Wikipedia, you will likely never get to use them. But if you work on a more niche app, they become quite useful. Over time, old browsers die out, and the amount of people who can use new features expands; early adopters do the testing for the late majority.

> we still need to target es5 4 years later,

This is a dramatic improvement over the 10 year lifespan of IE6 with es3. Once the need to target es5 drops, the next level gets even shorter - I don't think we'll get less than 2 years as a practical matter, but even at a 2 year delay, that's still regularly progress.

> a pretty arbitrary subset of the language

Best practices don't come from a mathematical model - programming is about communication and being compatible with user/business demands (which keep changing). Thus, best practices come about from a lot of experimentation and retrospective. That's ongoing. This doesn't mean it won't settle down. Heck, as it is, a lot of dynamic best practices influence the direction of non-dynamic languages - all of which arises from time and experimentation.

> If we still need to target es5 4 years later, and transpilation is standard practice, why bother?

Your “we” isn’t everyone else’s. Some places need to support very old browsers but even in places like that usually not every app does. Those people are pushing the state of the art forward since they do real work outside of the standards process and that provides useful feedback to both the standards committees and browser developers.

> Is the evolution of JS not directed in practice by the authors of Babel and Typescript?

In practice? I suppose in practice, JavaScript is driven by everyone in aggregate and what people consider to be "JavaScript" rather than "something that can be made to run in traditional JavaScript environments like browsers." I'm not sure if you mean that, or simply who directs actual changes to the traditional JavaScript environments (like browsers) themselves.

But yeah, if transpilation tools are reliable and continue to be well-maintained, you can say "why bother updated the 'official' language and implementation in browsers?" But I don't understand how this is a bad thing. You're getting the best of both worlds: browsers will implement new JavaScript features and optimizations, and some dev teams can also use build tools to use those new features, and other potential new features, and still make their work available to older browsers.

It doesn't seem like a problem to me, unless you're thinking about all the language development effort in the JavaScript community as a fixed pie such that "non-official" language development like Babel and TypeScript take away effort that otherwise would be allocated to official language development. And I certainly don't think that is the case.

We're in the age of "evergreen" browsers, where almost everyone is on a browser that auto updates. New features can be useable in maybe 2 years now, depending on your audience.

Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need?

I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's how we wrote it years ago and it still works", but anyone who actually cares about performance will think twice before using babel today to turn nice, clean, concise modern code into incredibly verbose and shimmed legacy code, and will certainly think twice before serving ES5 code to users on a modern browser.

You only need to target old es if you're deploying a website for a big company. Most people don't need IE6 compat. For example, people writing node apps can choose which version of node they deploy.

Not true at all; With Node.js I don't have to wait for a browser to update, and V8 is often up-to-date with the latest stuff. And as a full-time JS dev, I have not gotten the feeling that the transpiler authors get to determine what's in the language. Honestly if they add anything that isn't destined to be part of the spec, I wouldn't use it because then you're tied into that transpiler for good.

A few off the top of my head:

1. Node.js greatly benefits from these features. Transpiling is not as prevalent there

2. Some people do exclusively target "evergreen" browsers and don't care about IE support

3. Those that do differential bundling (different bundles per browsers) can see quite a performance boost by not transpiling on newer browsers

> If we still need to target es5 4 years later

This is only true if you're writing JavaScript for the client and you have to support IE11. For many companies, the usage for IE11 is so low now that it can be safely dropped, for instance my SaaS products all just target evergreen browsers.

One place this works, when your clients are able and willing to use the latest browsers to use your software.

The primary benefit is that I don't have to rely on hacks.

This is how I build the backend to my CMS and my clients are happy to keep their browsers updated. (nearly trivial to do these days).

This also means that as soon as I see a new JS/CSS feature that will eventually become mainstream, I can use it in my admin as soon as both major browsers (Firefox/Chrome) support it. And even sooner if it's not a critical feature. (eg, I can skip adding a feature like "lazy loading" because browsers will have it built in eventually, etc...)

On the public facing front end, that is a different story though. It's motivation to keep things simple.

If you target modern browsers only, and if you're building non-web facing apps, you should be able to... you can absolutely use this stuff today.

Right now, for example, the apps I'm working on require at least async/await support as a minimum test.

I hear you. I look forward to seeing the (support) death of IE11 in 2025 (!!!), which is likely all too close to my own retirement.

Also about the “subset” thing: the last 10 years or so I have been moving away from OOP, and more towards FP, so stuff like class support or Typescript have been a big yawn, anyway.

We had “C with classes” (I.e. C++ as it was known at the time) shoved down our throats in Uni back in the 80s, since garbage collection was impractical. That “wisdom” turned out to be short lived, and thus my migration towards FP (beyond the Lisp I had in an AI class back in the 80s)

Having these features in the standard gives browsers and transpilers a common, well-specified target to work towards.

If you only need to support a subset of browsers you can turn off compilation/polyfills for specific features, which sometimes leads to better performance and smaller bundles.

I think of it like TypeScript and Babel running ahead experimenting with new ideas, ES following along turning the good ideas into a spec, and browsers taking up the rear implementing the spec. It’s a pretty decent system.

There are certain sectors in which backwards compatibility is important, but most people developing can confidently use ES2015+ features directly in the client without polyfill.

JS doesn't compile so all the runtime engines (mainly browsers) need to adopt the new features as well. This takes time. These new features are part of the official ES2019 standard, and Babel makes it possible to use these new language features and transpile it to a language that all the browsers can use. What's not to love? This is actually a great (if not amazing) thing.

In my experience, you don't really have to target es5 anymore. Most browsers support new features all the way through es2018. My Babel / Webpack config is pretty minimal these days.

Because, everything has been moving to evergreen browsers for desktop. If only the mobile devices would do the same, you could have a future where you would not have to.

I like TypeScript's (stage-3) approach to feature adoption.

You don't necessarily need to target ES5.

What percentage of your users is on IE11? Are you making money from them? Can you serve only them a compiled bundle?

Almost all new features can be implemented is ES5 so instead of transpiling you can patch old engines. Eg. Array.prototype.flatmap

> If we still need to target es5 4 years later

You don't. Unless you care about IE11 (for most consumer products and mobile apps isn't necessary) you can use many of the features up through ES2016 or later without transpilation. My business uses JS classes, arrow and async functions, and new prototype methods without issue.

Are you proposing that we just never improve the language?

Pattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution.

I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when that's in place but going the opposite direction is difficult. What is a type if not a pattern?

Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

I adore pattern matching when done well, but I'm sorry -- that syntax seems terrible and confusing. The use of `{ }` seems arbitrary. In JS braces are already used for both scope-delimiting and object literal notation; now they're going to have a third job? There has to be a better way.

I understand it's based on destructuring; the syntax still just doesn't work for me.

Yeah very excited about optional chaning, which few days ago got accepted to stage 3 "candidate", so just one more stage (stage 4 "finished"), I guess and hope it will be ready for ES 2020

Z is an interesting approach.

https://dev.to/kayis/pattern-match-your-javascript-with-z-nf...

Optional chaining is stage 3, and major engines are actively implementing it.

These two and decorators (including function/assignment decorators) are the top 3 on my wishlist.

What's the point of pattern matching? Why not just a switch statement?

Waiting for Optional Chaining. It's in Stage 3 already.

Also see assignment expressions recently adopted in python 3.8: https://www.python.org/dev/peps/pep-0572/

I know this doesn't match up entirely with what you want syntax wise, but the following works and I consider it quite elegant.

  {
    let row;
    if (row = await db.findOne()) {
      //
    }
    else {
      //
    }
  }

Would the else branch trigger on a falsy value, or on an exception? It's a bit confusing, as it looks like it would handle exceptions on the else branch, even though we know we have to wrap await in try/catch for that.

Other than saving a few characters (the variable name), I don't see any benefit of this, while it makes code harder to read.

Too bad the `with` [0] keyword has been reserved for crap, it sounds nice (not for this, but maybe for something else).

>> and also requires you to start renaming variables (ie. row1, row2...) due them going over their intended scope

Variable shadowing [1] is a really bad practice that makes it hard for people to collaborate and keep the code sane. Bad habits are not a reason for language changes.

[0] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] - https://en.wikipedia.org/wiki/Variable_shadowing

You can also declare variables in conditional statements in C/C++ like https://godbolt.org/z/h0BR8K

  int foo(int);
  int bar(int x) {
    if (int y = foo(x)) return 0;
    return x;
  }

Nice. I like use of the let/var/const keyword to disambiguate from the accidental `if (x = y)` when intending to use `==`.

This has been discussed a few times on IRC, but no one has made a proposal yet afaik.

FWIW Swift lets you do this, and it's great. Guard statements even better.

You can also do this in Ruby, though the scope is different.

In my opinion this is a terrible idea, since it's very easy (I do it all the time) to accidentally write `if (foo = bar)` instead of `if (foo == bar)`. If that were valid syntax it would be a huge footgun. I'd be onboard with it if it required a different syntax.

Mutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i<arr.length; i++) arr[i] = b" loop will obviously mutate modified elements while a "for(let e of arr) e = b" won't; the trend is towards less mutability in new features.

Proper immutable support (or a stronger concept of const) would also help with this.

Yes, this is a real problem and I've been bitten by it more times than I can count. Now I always keep this handy website ready: https://doesitmutate.xyz/

At the same time, all this copying leads to an immense amount of garbage, which can really slow apps down with GC pauses. I really wished JavaScript had support for true immutable structures (a la Immutable.js) since these things do add up.

In my side project, which is a high performance web app, I was able to get an extra ~20fps by virtually removing all garbage created each frame. And there's a lot of ways to accidentally create garbage.

Prime example is the Iterator protocol, which creates a new object with two keys for every step of the iteration. Changing one for loop from for...of back to old-style made GC pauses happen about half as much. But you can't iterate over a Map or Set without the Iterator protocol, so now all my data structures are hand-built, or simply Arrays.

I would like to see new language features be designed with a GC cost model that isn't "GC is free!" But I doubt that JavaScript is designed for me and my sensibilities....

You could always look at ClojureScript. I know I am.

  Array.flat() => flatten
  Array.flatMap() => mapcat
  String.trimLeft() => triml, trimr 

Symbols are great but they’re much more useful when you can write them as (optionally namespaced) literals, which are much faster to work with:

  (= :my-key :your-key) ;; false
  (= :my-key :my-key) ;; true

Object.entries() and Object.fromEntries() are both covered by (into). You can use (map) and other collection-oriented functions directly with a hashmap, it will be converted to a vector of [k v] pairs for you. (into {} your-vector) will turn it back into a new hashmap.

And...all of these things were already in clojurescript when it was launched back in 2013! Plus efficient immutability by default, it’ll run on IE6, and the syntax is now way more uniform than JS. I’m itching to use it professionally.

I really like the lisp convention of using !'s to indicate mutation. Like set-car! .

In javascript you kind of have to reason backwards and declare your variables as immutable (const). Though there are still some bugaboos; object fields can still be overwritten even if the object was declared with const.

JS already has immutable objects with `Object.freeze()`.

Personally I just use TypeScript which can enforce not mutating at compile time (for the most part).

In other words you’re concerned that some Array methods mutate the array (push, pop) and some don’t (map, concat)?

If so then yeah, that can be annoying and/or confusing.

If this is a major concern for you, you might want to use something like immutableJS[0]. More often than not I’ve found it unnecessary except in very contained parts of a large app, but in case it’s helpful I wanted to point it out.

[0] - https://github.com/immutable-js/immutable-js

I really love the Ruby naming conventions around this: `!` indicates mutation.

  2.4.1 :001 > a = [4,3,5,1,2]
   => [4, 3, 5, 1, 2]
  2.4.1 :002 > a.sort
   => [1, 2, 3, 4, 5]
  2.4.1 :003 > a
   => [4, 3, 5, 1, 2]
  2.4.1 :004 > a.sort!
   => [1, 2, 3, 4, 5]
  2.4.1 :005 > a
   => [1, 2, 3, 4, 5]

Always try to limit the scope of variables. Use local scope. And also functions within functions. The nice part when limiting scope is that you never have to scroll or look elsewhere in order to understand what a piece of code does.

I still don't understand why neither JSs var or let allow you to redefine the variable with the same name.

I makes chaining things while debugging so much harder:

  let a = a.project();
  let a = debug(a);
  let a = a.eject();

vs

  let a1 = a.project();
  let a1d = debug(a1);
  let a2 = a1d.eject();

I dig it too, but you could previously flatten an array with concat, and the spread operator. [].concat(...array)

Lodash wasn't necessary.

I wonder if there are enough use-cases for .flat to not default to Infinity.

It's also confusing that `arr.flatMap()` is not equivalent to `arr.map().flat()`, but to `arr.map.flat(Infinity)`

flatMap is always so unituitive (not a word) for me for some reason. I messed with it a bunch in C#'s LINQ and RxJS and I already forgot the purpose. Not sure what it is that makes it so unnatural for me.

it should be faster than lodash too, i should hope

Really though, don't know why this isn't the most mentioned feature in this thread, processing objects in JS has always been annoying.

What would some common/helpful use cases be?

Let me preface this with acknowledging that you're entirely correct that you don't really need flatMap. The following is just some background that might explain why it was included.

If you're familiar with C#'s linq and it's reliance on SelectMany it's somewhat easier to see the significance.

In C#'s linq you might write something like:

    from host in sources
    from value in fetch_data_from(host)
    select create_record(value, host)

with flatmap (and some abuse of notation) you can more easily implement this as:

    sources.flatmap( host => fetch_data_from(host)
           .flatmap( value => create_record(value, host))

If you dig even further you'll find that what makes this powerful is that the flatMap, together with the function x => [x], turns arrays into a Monad. The separate functions map and flat also work, but this adds more conditions. Haskell folks tend to prefer flatMap because most of the conditions for a Monad can be encoded in its type signature (except [x].flatMap(x => x) == x, but that one is easy enough to check).

You could optimise either, I don't think that's the point. It's just a convenience that more clearly expresses the intent of the code where it's used. Imagine an example where the callback to map is quite long; seeing the flatMap identifier alerts you to the fact that the callback returns arrays, even before you start reading.

You'll find equivalents in all the JS utility libraries and most functional programming language standard libraries (and languages like Ruby with functional-ish subsets), so there's a lot of evidence that people who write code in that style like to have such a function available.

They could have also implemented flat in terms of flatMap: flatMap(x => x)

I personally feel flatMap is a much more used method than flat, so if you want to remove one, I would remove flat.

It is very common for people to implement flatmap themselves or get it from a library of higher-order functions. So now people can use flatMap without doing those two things.

And more importantly what is essentially verbatim in your question:

Why is flatMap = map().flat() and not flat().map()

Infinity was originally the default (which feels intuitive), but here's the argument for changing it [0]:

"I think Array#flatten should be shallow by default because it makes sense to do less work by default, it aligns with existing APIs like the DOM Node#cloneNode which is shallow by default, and it would align with the existing ES3 pattern of using Array#concat for a shallow flatten. Shallow by default would also align with flatMap too."

[0] https://github.com/tc39/proposal-flatMap/issues/9

If your array is contained in itself, flat(Infinity) gives a stack overflow. My guess is they wanted the default behavior to be safer/saner.

It's already been deployed in the wild for about a year.

Rather than how complete it is, the real improvements of the proposal are:

1. it all but requires that ES-defined functions stringify to their source code. Pre-ES2019 that's implementation-defined

2. it standardises the placeholder for the case where toString can't or won't create ECMAScript code (e.g. host functions), this could otherwise be an issue as with implementation-defined placeholders subsequent updates to the standard might make the placeholder unexpectedly syntactically valid, by having the placeholder standard future proposals can easily avoid making it valid

3. the stringification should be cross-platform as the algorithm is standardised

If you are interested in all the gory details, take a look at the TC-39 proposal (especially the Goals section) and associated GitHub issues:

https://tc39.es/Function-prototype-toString-revision/

https://github.com/tc39/Function-prototype-toString-revision...

I don't know the answer to your question, but I would like to add to it to gain some clarity for myself: why not give the caller the option to have comments eliminated? An optional parameter `includeComments` bool with default `false` would provide backward compatibility while allowing those who need the comments to request them.

Very good!

Personally, I am not a fan of languages growing. I think C is awesome, because everyone can understand the code, and doesn’t have to be a language lawyer like with C++. Concepts, Lambdas, crazy Template preprocessing, and more. The team can just work, pick up any module and read it without magic.

In C++ I am not even sure if a copy constructor would run vs an overloaded = operator without looking it up.

Clojure too didn't change a lot. In these years of 'disruption' it feels odd. But it may just be that we forgot stability and maturity.

Technically most of this is not even language changes but simple changes to the standard apis. E.g. flatMap is something I've missed and worked around by implementing it myself a few times. Not a big deal and nice that they added it. In any case, I use typescript by default now and have converted most of the code I care about at this point. I think most of this improves typescript as well so; overall a good thing.

They need to ensure that any combination of characters will produce some result.

Quite useful in situations such as:

> (str.match(regexWithGroup) || [, null])[1]

I.e. if the regex matches, then give me the first group (1st index) otherwise give me null.

Because you can create that array anyway, like so:

  var arr = [];
  arr[0] = 1;
  arr[1] = 2;
  arr[3] = 3;

so there's not really much downside to also allowing a literal syntax for the same thing.

It does, though I wouldn't go to the same conclusion. It gives more freedom to the developer. They are lot of cases where errors are in fact, expected. Parsing a user inputted JSON. Making a request to check internet connection availability. Any promise that is going to be consumed by an async - await pattern. In those cases (and many more), you may want to try something just simply to see if it works. It's completely different say to being on the backend, trying to write to a database which may or may not fail.

In those cases, forcing the extra parameter in the catch, even though you are not using it, is slightly annoying. I mean it's literally 3 characters, but in this age of linters encouraging to not specify arguments you don't use, it just feels unnatural.

I see what you're saying - for me, my experience with Java checked exceptions put me off the idea.

In Java it led to lots of exception wrapping and leaky abstractions.

Not sure what the answer is - although my golang experience was better.

What's a good example of this sort of language?

Honest question, not playing. What is exactly exciting about it? 2020 is around the corner and the language created back in 1995 is only now getting features that have been standard in many other languages, either as part of the core language or the standard library for decades.

Yep, waiting for private methods (Stage 3) and private-fields.

I think it's been changed after you posted this comment. It now shows that 15^2 is 225.

The Function.prototype.toString change has been in chrome for maybe a year now btw.

TC39 have been fairly conservative about not breaking real world code. Array.prorotype.flat was named flat and not flatten because of compatibility issues with old versions of MooTools.

It also requires that comments get stored and waste memory: previously just enough of the AST needed to be stored to be able to regenerate the JavaScript. You can't throw away the comments because you can't predict where code might do someVarHoldingAFunc.toString()

It seems like an unnecessary change - if the source needs to be accessed then get the source file.

Fixed the typo, thanks for the heads up!

Seems perfectly logical to me: an array of length 5 with four populated elements and one empty one (3). Though I did double-check my understanding that the length property would report 5 rather than 4 (it does).

What looks out of place to you in that example?

Would it make more sense to you with a very slightly less arbitrary example, perhaps arr = ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4']; instead of simple mapping ints to ints?

Because array contents are mutable [even if the array variable itself is declared const] that third index may be populated at a later point in the code.

Doesn't the fact that flatten by default only flattens one level mean you can still create nested output by emitted nested outputs?

Seems like a real missed opportunity to look at the Python stdlib and add a bunch of missing functionality to JS so that people don't have to import a metric ton of third party libraries (or worse, write it themselves) to add something you get for free in most other scripting languages.

Even the trim operations they added fall short of the target. In Python (and tcl, by the way) you can specify which characters to trim.

So close, yet, so far.

String#padStart already exists: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You mean https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ?

>The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times.

Incorrect - The main advantage is fat arrow syntax can keep lexical scope of this current context. Hence you dontneed to implement that=this antipattern

> arrow function notation

Arrow functions bind this to the lexical scope, which is useful. (In a regular function the value of this depends on how it's called.)

> python which was resistant to the idea of 20 ways to do the same thing

This was in comparison to Perl which intentionally has an unusual excess of different ways to do things.

> "walrus" operator

Simplifies a very common pattern.

  m = re.match(r"my_key = (.*)", text)
  if m:
      print(m.group(1))

Arrow functions aren't just new syntax, they keep the context in which they are declared.

It allows devs to do the following:

onClick={() => doSomething()}

Without having to worry about binding the function to the correct context.

Arrow function made `this` much more intuitive while maintaining backwards compatibility. That's definitely bringing something to the table.

arrow functions are not just a function() alternative, but they solve the whole 'var self = this'/'.bind(this)' boilerplate.

It's one of the best JS improvements of the last 10 years.

You mean something like x % 2 === 1?

I'm a JS fan but had to admit I chuckled at the implementation of is-even: https://github.com/jonschlinkert/is-even/blob/master/index.j...