New Features in ES2019 • Hacker News Board

Re: New Features in ES2019

#41

Post by dmit » Sat, Dec 07, 2019, 1:56 PM UTC

wongarsu wrote: post #36

dmit wrote: post #25

Earlier quoted context omitted.

If by BigInt you mean an arbitrary-precision integer type, then AFAIK no major language uses it to represent dates. If you mean a 64-bit integer type (which, to be fair, is 11 bits larger than what JavaScript supports), then that's still not enough. As long as you want nanosecond-level granularity, and range beyond the current decade for your timestamps, you'll need more than 8 bytes to represent them in code.

I would argue dates with nanosecond granularity are of limited usefulness. In almost all use cases millisecond granularity is sufficient for dates, if you need nanosecond granularity chances are you also want a monotonic clock instead of real time that's subject to daylight savings, NTP correcting the clock etc.

I think it's mostly a usability tradeoff. If you can use the same data type for calendar appointments and high-precision performance logging, then you save your users the necessity of choosing between different types. Bonus points for being able to get away with a single nanosecond-based Duration type that has straightforward arithmetic with nanosecond-based timestamps.

And if you're deep enough to worry about the cost of those extra bits, you probably want to have your own date type anyway, tuned for your exact problem.

Re: New Features in ES2019

#42

Post by chrismorgan » Sat, Dec 07, 2019, 2:00 PM UTC

masklinn wrote: post #38

chrismorgan wrote: post #31

[This comment is wrong; see masklinn’s response for my misunderstanding.] > Now the function would rather insert an escape character before the character code so that the result is still readable and valid UTF-8/UTF-16 code: > JSON.stringify('\uD83D'); > // '"\\ud83d"' I’m inclined to consider this a misfeature, unbreaking something that I’m glad was broken and should have remained broken. Unpaired surrogates are (to…

You're misreading the article section, although the article is also partially wrong: the old behaviour was to output the lone surrogate in the JSON stream[0] (the "�" here is confusing: it is a display artefact of the specific font, not U+FFFD), the new behaviour is to replace the unpaired surrogate by the literal 6-character long escaped representation of the unpaired surrogate . That is, formerly U+D83D would pass…

Ah, you’re right; thanks for the correction.

The article does contain an error here, for the code point on the page is actually U+FFFD, not U+D83D (which of course is unrepresentable there). I trusted that (being a little surprised that it’d do the replacement, which is more what I’d expect of Python, but accepting it all the same) and didn’t pull out an old browser to confirm what actually happens, which is, as you say, an unpaired surrogate code point.

The article should probably say '"\ud83d"' instead of '"�"' (even though the number of backslashes still then requires thought), because yielding U+FFFD there would be a completely valid (and preferable, in my opinion) solution.

Re: New Features in ES2019

#43

Post by uncletaco » Sat, Dec 07, 2019, 2:09 PM UTC

chrismorgan wrote: post #42

masklinn wrote: post #38

Earlier quoted context omitted.

You're misreading the article section, although the article is also partially wrong: the old behaviour was to output the lone surrogate in the JSON stream[0] (the "�" here is confusing: it is a display artefact of the specific font, not U+FFFD), the new behaviour is to replace the unpaired surrogate by the literal 6-character long escaped representation of the unpaired surrogate . That is, formerly U+D83D would pass…

Ah, you’re right; thanks for the correction. The article does contain an error here, for the code point on the page is actually U+FFFD, not U+D83D (which of course is unrepresentable there). I trusted that (being a little surprised that it’d do the replacement, which is more what I’d expect of Python, but accepting it all the same) and didn’t pull out an old browser to confirm what actually happens, which is, as you…

I love when the reaction to being wrong is to explain how the thing is responsible for their error and so they waste a few sentences explaining how it could have avoided leading then astray.

Re: New Features in ES2019

#44

Post by qwtel » Sat, Dec 07, 2019, 2:11 PM UTC

fromEntries(), aside from the symmetry with entries() is a really neat feature.

For example `Object.fromEntries(new URLSearchParams(window.location.search))` will parse a query string into a nice JS object. This works because the iterator of the search params class returns tuples.

What is already available today is `new URLSearchParams(Object.entries(params))` for turning a "params" object into a query string.

Re: New Features in ES2019

#45

Post by masklinn » Sat, Dec 07, 2019, 2:11 PM UTC

chrismorgan wrote: post #42

masklinn wrote: post #38

Earlier quoted context omitted.

You're misreading the article section, although the article is also partially wrong: the old behaviour was to output the lone surrogate in the JSON stream[0] (the "�" here is confusing: it is a display artefact of the specific font, not U+FFFD), the new behaviour is to replace the unpaired surrogate by the literal 6-character long escaped representation of the unpaired surrogate . That is, formerly U+D83D would pass…

Ah, you’re right; thanks for the correction. The article does contain an error here, for the code point on the page is actually U+FFFD, not U+D83D (which of course is unrepresentable there). I trusted that (being a little surprised that it’d do the replacement, which is more what I’d expect of Python, but accepting it all the same) and didn’t pull out an old browser to confirm what actually happens, which is, as you…

> The article does contain an error here, for the code point on the page is actually U+FFFD, not U+D83D (which of course is unrepresentable there).

The MDN page also does that, that's a bit misleading but TFA commits way worse a sin: it actually states the unpaired codepoint is swapped for the replacement character:

> In earlier versions, these would be replaced with a special character:

which is just wrong.

> yielding U+FFFD there would be a completely valid (and preferable, in my opinion) solution.

I agree. The proposal does not explain whether U+FFFD was considered, I expect they picked the escaped version to limit or avoid data loss: if you get an U+FFFD you have no idea what it used to be.

Re: New Features in ES2019

#46

Post by capableweb » Sat, Dec 07, 2019, 2:17 PM UTC

tiborsaas wrote: post #33

IgorPartola wrote: post #16

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.

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.

Re: New Features in ES2019

#47

Post by homero » Sat, Dec 07, 2019, 2:22 PM UTC

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

Re: New Features in ES2019

#48

Post by willtim » Sat, Dec 07, 2019, 2:35 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.

Most would expect 10 to parse as an integer. To specify a string, most would be happy with putting quotes around it. So I don't think dynamic types fully explains the bizarre behaviour.

Re: New Features in ES2019

#49

Post by topicseed » Sat, Dec 07, 2019, 2:41 PM UTC

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.

Re: New Features in ES2019

#50

Post by pythux » Sat, Dec 07, 2019, 2:46 PM UTC

masklinn wrote: post #35

pythux wrote: post #32

Earlier quoted context omitted.

> New methods with simple behaviour don't really make the language more complex through. I think they do, in some ways. If you have multiple methods or functions which seem to do similar things, as a new-comer it can be incredibly confusing. I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were th…

> I remember when I started I never knew what the "best way" to iterate on things was... for loops? for in? for of? foreach? And it was not obvious which one to use or what were the differences. Possibly aside from the latter (assuming you mean Array#forEach), these are not different "methods with simple behaviour", they're different language constructs with largely overlapping behaviour & use cases.

Sorry if I expressed myself poorly but that is exactly the point I wanted to make. To maintain backward compatibility, new constructs with partial overlap with existing ones are introduced; and this overall increases the complexity of the language. Whereas breaking backward compatibility would allow to re-use existing constructs and change their semantics (I am not saying this would be a better path though).