Live data from Hacker News

New Features in ES2019

javascript.christmas

81–90 of 123 posts

Re: New Features in ES2019

#81
post #20

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

I was going to ask a variant of that question: what is the status of BigInt and when might it clear TC39 approval? In most languages a Date object is just a BigInt with Unix time() making this somewhat obvious. BigInt will allow not only proper Date implementation but Currency and Real types, and many more things.

BigInt is in Stage 4 (https://github.com/tc39/proposal-bigint) which means that more than 2 implementations are shipping it unflagged. This is the last stage of any proposal in the TC39 process, which means it is de facto part of the standard.

Re: New Features in ES2019

#82

I love Javascript and TypeScript, but with all the technologies gravitating around JS, the setup for a project gets clunkier and clunkier. But overall, loving the direction JS is taking.

I hear this a lot, but everything can be handled with a single tool: Webpack. Even a TS project can compile with Webpack and all of its assets, minification and compression needs can be handled in the same file. While you’re at it you can set up a development server with source mapping. Just take an afternoon to learn Webpack and be done with complaining about setup overhead. I set up a multi-stage build for TS Proje…

And then another afternoon every week trying to figure out why Webpack is breaking this time. Many week I spend more time babysitting the environment tools than actually writing code.

Re: New Features in ES2019

#84
post #47

How are these used on a browser? Do you have to wait for browsers to update? It's something I don't understand

Different browsers will update at different times (or not at all). There are websites like caniuse and mdn that will show you what browsers are currently supporting. If you are working on an intranet site, you might know that everyone will be using X browser that is on version Y. Otherwise...

If people are sticking to an older browser, they will never have the functionality (this can somewhat be mitigated through transpiling using Babel, but this isn't foolproof).

It often takes years for a feature to be widely deployed enough that no tranpiling is required. There are still features from ES2015 that I think still require transpiling.

Re: New Features in ES2019

#85

Earlier quoted context omitted.

Weak types. When neither the function nor the parameters have hard types, you have to create heuristics. There could be a test for numbers there, but it would also be surprising because at the older days people expected "10" and 10 to behave the same.

It's not because of "weak types" since the types inside the array don't get their type information erased. It's because Array.sort takes a comparison function but the default function instead of being something like [1, 10, 2].sort((a,b) => a > b ? 1 : -1) // -> [1, 2, 10] is something like // [1, 10, 2].sort((a,b) => a.toString() > b.toString() ? 1 : -1) // -> [1, 10, 2] because someone thought that it was "best" to…

Both of your examples have invalid sort comparator functions.

A JavaScript sort comparator is required to not only return a positive or negative value, it must handle all three cases: greater than, less than, or equal. When the arguments compare equal, the comparator must return 0.

Returning only a positive or negative value is a very common error. (I don't mean to pick on you for this! I have seen the error so often that I hope this may be helpful for anyone writing a sort comparator.)

The invalid comparator will force the normally stable sort to be unstable, because sort() now has no way to know that two items should be considered equal and their existing order preserved.

Let's demonstrate with the "doggos" example that the article links to:

https://mathiasbynens.be/demo/sort-stability

The code starts with this array:

  const doggos = [
      { name: 'Choco',   rating: 12 },
      { name: 'Devlin',  rating: 13 },
      { name: 'Eagle',   rating: 13 },
      { name: 'Jenny',   rating: 13 },
      { name: 'Kona',    rating: 13 },
      { name: 'Leila',   rating: 13 },
      { name: 'Milly',   rating: 14 },
      { name: 'Molly',   rating: 12 },
      { name: 'Nova',    rating: 12 },
      { name: 'Oliver',  rating: 13 },
      { name: 'Patches', rating: 14 },
  ];
It uses this valid comparator:

  doggos.sort( ( a, b ) => b.rating - a.rating );
(Note that this implements a reverse sort as can be seen in the output on the test page.)

Subtraction provides the proper return values when two numbers are compared: any negative number, any positive number, or zero when the ratings are equal.

Another valid comparator (again using a reverse sort) would be:

  doggos.sort( ( a, b ) =>
      a.rating  b.rating ? -1 :
      0
  );
Either way you get the expected output in the current version of Chrome, which has a stable sort. Each group of doggos with the same rating appear in their original order:

  [
      { name: "Milly",   rating: 14 },
      { name: "Patches", rating: 14 },
      { name: "Devlin",  rating: 13 },
      { name: "Eagle",   rating: 13 },
      { name: "Jenny",   rating: 13 },
      { name: "Kona",    rating: 13 },
      { name: "Leila",   rating: 13 },
      { name: "Oliver",  rating: 13 },
      { name: "Choco",   rating: 12 },
      { name: "Molly",   rating: 12 },
      { name: "Nova",    rating: 12 }
  ]
So let's go back to the original doggos array and use a sort function that only returns 1 or -1 (once again using a reverse sort):

  doggos.sort( ( a, b ) =>
      a.rating 
With this function, the result is:

  [
      { "name": "Patches", "rating": 14 },
      { "name": "Milly",   "rating": 14 },
      { "name": "Oliver",  "rating": 13 },
      { "name": "Leila",   "rating": 13 },
      { "name": "Kona",    "rating": 13 },
      { "name": "Jenny",   "rating": 13 },
      { "name": "Eagle",   "rating": 13 },
      { "name": "Devlin",  "rating": 13 },
      { "name": "Nova",    "rating": 12 },
      { "name": "Molly",   "rating": 12 },
      { "name": "Choco",   "rating": 12 }
  ]
Now the sort has become unstable. Doggos with the same rating are no longer in their original order.

Bottom line, be sure to handle all three cases in your sort comparator if you want a stable sort.

Re: New Features in ES2019

#86

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

There's plenty of good reasons one doesn't exist. JSON is not JS-specific. It is a standard interchange format used by thousands of languages, many of which have very different date implementations. If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it…

Why have a JSON number?

Why not "just stick with" decimal strings?

Re: New Features in ES2019

#87
post #3

I don’t mean to hate on ECMAScript, but is anyone else slightly surprised these features weren’t in earlier? Like I wonder how many bugs were introduced because the developer didn’t realize Array.sort() was unstable.

> developer didn’t realize Array.sort() was unstable

You seem to think stable sort is much more important than most of the rest of the field.

By default, C sort isn't stable, C++ sort isn't stable, Ruby sort isn't stable, C# sort isn't stable, Perl sort isn't stable. Hell, not even GNU's sort utility is stable.

JavaScript has some unexpected idiosyncracies, but sort() stability isn't one of them.

Re: New Features in ES2019

#88

Earlier quoted context omitted.

It's not because of "weak types" since the types inside the array don't get their type information erased. It's because Array.sort takes a comparison function but the default function instead of being something like [1, 10, 2].sort((a,b) => a > b ? 1 : -1) // -> [1, 2, 10] is something like // [1, 10, 2].sort((a,b) => a.toString() > b.toString() ? 1 : -1) // -> [1, 10, 2] because someone thought that it was "best" to…

Both of your examples have invalid sort comparator functions. A JavaScript sort comparator is required to not only return a positive or negative value, it must handle all three cases: greater than, less than, or equal. When the arguments compare equal, the comparator must return 0. Returning only a positive or negative value is a very common error. (I don't mean to pick on you for this! I have seen the error so often…

That, incidentally, is why key functions (aka native support for decorate-sort-undecorate) is so convenient: rather than a fiddly and error prone comparator, the key function just returns a comparable (a value or composition of values).

A good alternative for statically typed languages is to have the comparison result be a proper sum type, and provide ways to generate and compose comparisons e.g. Haskell or Rust's Ordering (and Ord trait / typeclass).

Re: New Features in ES2019

#90

Earlier quoted context omitted.

Both of your examples have invalid sort comparator functions. A JavaScript sort comparator is required to not only return a positive or negative value, it must handle all three cases: greater than, less than, or equal. When the arguments compare equal, the comparator must return 0. Returning only a positive or negative value is a very common error. (I don't mean to pick on you for this! I have seen the error so often…

That, incidentally, is why key functions (aka native support for decorate-sort-undecorate) is so convenient: rather than a fiddly and error prone comparator, the key function just returns a comparable (a value or composition of values). A good alternative for statically typed languages is to have the comparison result be a proper sum type, and provide ways to generate and compose comparisons e.g. Haskell or Rust's Or…

Absolutely, using an integer instead of a static sum type hides the problem and actually makes it harder to solve correctly.
Post reply on HN