New Features in ES2019 • Hacker News Board

Re: New Features in ES2019

#51

Post by tiborsaas » Sat, Dec 07, 2019, 2:48 PM UTC

capableweb wrote: post #46

tiborsaas wrote: post #33

Earlier quoted context omitted.

You don't need to parse when getting data, the fetch API does that for you automatically. const res = await fetch(url); const data = await res.json(); For posting you do need JSON.stringify(data), but I never thought of it as painful, just a single line.

> fetch API does that for you automatically It does not do it automatically. Even in your example, you call `Response.json()` to do the parsing. If you change that to `Response.text()` it will be text instead. If you don't include the `.json()` call, nothing will be parsed from the body.

I know how it works :) Since it's part of the API getting a response object is pretty effortless, which is a better word than automatic, agree.

Re: New Features in ES2019

#52

Post by dominotw » Sat, Dec 07, 2019, 3:14 PM UTC

homero wrote: 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

need a compiler/transpiler that translates to browsers that don't understand these new features. and hope browsers catchup , which could be never.

So this is basically a fantasy what javascript could be no different than any other alt-js languages .

Re: New Features in ES2019

#53

Post by [deleted] » Sat, Dec 07, 2019, 3:23 PM UTC

tiborsaas wrote: post #51

capableweb wrote: post #46

Earlier quoted context omitted.

> fetch API does that for you automatically It does not do it automatically. Even in your example, you call `Response.json()` to do the parsing. If you change that to `Response.text()` it will be text instead. If you don't include the `.json()` call, nothing will be parsed from the body.

I know how it works :) Since it's part of the API getting a response object is pretty effortless, which is a better word than automatic, agree.

[deleted]

Re: New Features in ES2019

#54

Post by heisenhuegel » Sat, Dec 07, 2019, 3:25 PM UTC

Demanding a stable Array.sort is surprising. I find it questionable, as it implies a performance trade-off. Why not add a new stableSort function?

Trying to retroactively fixing bugs in code that did not follow the standard is not a good idea IMHO.

Re: New Features in ES2019

#55

Post by gatherhunterer » Sat, Dec 07, 2019, 3:37 PM UTC

topicseed wrote: post #49

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 Project References but that’s only necessary if you want to share code between the front and back ends. Aside from that you should only need a single build step.

Re: New Features in ES2019

#56

Post by gatherhunterer » Sat, Dec 07, 2019, 3:42 PM UTC

homero wrote: 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

Every individual feature has a support graph on MDN.

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

Re: New Features in ES2019

#57

Post by bernawil » Sat, Dec 07, 2019, 3:47 PM UTC

marcosdumay wrote: post #27

willtim wrote: post #24

Earlier quoted context omitted.

Wow, who came up with that idea? And people say Haskell is hard to learn...

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 cast stuff to string in case whatever you put in the container didn't implement comparison.

Re: New Features in ES2019

#58

Post by masklinn » Sat, Dec 07, 2019, 3:48 PM UTC

heisenhuegel wrote: post #54

Demanding a stable Array.sort is surprising. I find it questionable, as it implies a performance trade-off. Why not add a new stableSort function? Trying to retroactively fixing bugs in code that did not follow the standard is not a good idea IMHO.

The "stable Array.sort" proposal was actually made because all major browsers had switched to a stable sort implementation: https://github.com/tc39/ecma262/pull/1340

It was actually proposed by the v8 / chrome people (https://v8.dev/features/stable-sort) after they'd finally come around to implement one of the oldest v8 feature requests: https://bugs.chromium.org/p/v8/issues/detail?id=90

And stable does make for a better default than unstable: it offers stronger guarantees and more reliable behaviour. That's doubly important because by and large developers work to the implementation not the spec. And it's unlikely you'll ever change that.

The last one to switch was Chakra (Edge), and that one was weird as it used a stable sort up to 512 elements, and unstable above.

Funnily enough, Mozilla had originally switched to a stable sort because MSIE used a stable sort: https://bugzilla.mozilla.org/show_bug.cgi?id=224128

Re: New Features in ES2019

#59

Post by wging » Sat, Dec 07, 2019, 3:49 PM UTC

haecceity wrote: post #4

I wonder what kind of shenanigans you could do with Function.toString(). It'd be even better if they had Function.toAST().

Lots. I can't remember exactly what I've seen, but believe I have seen it used in interesting ways. Including (drum roll...) .toString().substring(some_magic_number, ...) to do something or other (wish I remembered what). I'll let you think about whether that's wise, but note that indexing into 'function /* a comment */ foo () {}' (the example from the article) will give different results from indexing into 'function foo () {}'.

Re: New Features in ES2019

#60

Post by wging » Sat, Dec 07, 2019, 3:52 PM UTC

matsemann wrote: post #39

nkozyra wrote: post #30

Earlier quoted context omitted.

How so? Were these eval()ed by Angular? I don't follow what it would use function strings for determining missing - presumably - polyfills that you couldn't do in better ways.

In angular 1, if you had a function on the form myApp.controller('MyCtrl', function($myCoolService) { //... }); Angular would see that you are looking for a parameter named myCoolService, see if it already has it, and then inject it when calling your controller. This of course broke in various ways with minification when the parameter names were mangled. So one had the opportunity to use "array syntax", requesting a…

Did it by any chance pull parameter names out by using a magic-number index into the function text? If so, that'd be broken by the 'function /* a comment */ foo () {}' change in the article (and might be what I remember having seen a long time ago). Glad I don't have to deal with that sort of thing. Does Angular 2 do it the same way?