What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#261

Post by dvlsg » Tue, Jul 30, 2019, 4:52 PM UTC

underwater wrote: post #77

afandian wrote: post #25

Earlier quoted context omitted.

Thanks. But can I then add and remove items from an immutable object to create new objects? Part of the immutable value proposition is being able to work with the objects. Based on [0] Freezing feels more like constant than immutable. And the 'frozenness' isn't communicated through the language - I could be passed a frozen or unfrozen object and I wouldn't know without inspecting it. And freeze isn't recursive agains…

Have you looked at Immer.js? It allows you to express modifications to immutable objects as a series of imperative operations. In my experience most "immutability" in JS is enforced by convention or, at best, static type systems. It's not ideal, but it works.

Lenses in ramda work well, too, if you don't mind being functional in your js code.

I suppose that still only fits in the "immutable by convention" category, though.

Re: What’s New in ES2019

#262

Post by Ravengenocide » Tue, Jul 30, 2019, 4:53 PM UTC

dmitriid wrote: post #183

rglover wrote: post #78

That array.flat() and array.flatMap() stuff is great to see. Always having to rely on lodash and friends to do that type of work. Exciting to see how JS is evolving.

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)`

According to MDN `arr.flatMap()` is indeed equivalent to `arr.map().flat()` (without the Infinity). [1] Testing in the Chrome Devtools it also seems to be the case:

  x = [[[1, 2]], [[2, 3]], [[3, 4]]]
  x.flatMap(x=>x)
  output: [[1,2], [2,3], [3,4]]
  x.map(x=>x).flat()
  output: [[1,2], [2,3], [3,4]]
  x.map(x=>x).flat(Infinity)
  output: [1, 2, 2, 3, 3, 4]

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... > It is identical to a map() followed by a flat() of depth 1, but flatMap() is often quite useful, as merging both into one method is slightly more efficient

Re: What’s New in ES2019

#263

Post by [deleted] » Tue, Jul 30, 2019, 4:55 PM UTC

stevenmays wrote: post #112

rglover wrote: post #78

That array.flat() and array.flatMap() stuff is great to see. Always having to rely on lodash and friends to do that type of work. Exciting to see how JS is evolving.

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

[deleted]

Re: What’s New in ES2019

#264

Post by WorldMaker » Tue, Jul 30, 2019, 4:56 PM UTC

syntheticcdo wrote: post #199

simias wrote: post #139

Earlier quoted context omitted.

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 s…

It's a bit different with compiled code though right? If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler, the executable will work for everyone on that platform once built. Whereas in JS-land, the support for upgrades is even more trailing because it's the end-users who need to upgrade, not just the individual/organization doing the packaging.

C to a lesser extent does have the same trailing problem with end users as well in libc / VCRUNTIME and other standard lib bundles.

On Windows VCRUNTIME installs are mostly painless, easily backgrounded, and people don't realize they sometimes have as many as 100s of different versions installed side-by-side because every game installed wants a slightly different version.

But on Linux, it's often as much as like three-fourths of the reason that code needs to be rebuilt so often for every possible different Linux distribution because most distributions lock to only a single libc and prefer every app dynamically link that specific libc. Apps get held back by distributions slow to adopt libc updates all the time in Linux, and app devs try to stick to common libc versions based on distribution popularity (user preference), which isn't dissimilar to the lagging browser problem.

(Then there are arguments about statically bundling libc / VCRUNTIME, etc.)

It's not as bad as JS land on average, but that doesn't mean that C is immune to the same problem. As soon as you are dealing with shared libraries / platforms / runtimes, you run into having to deal with what users are willing to install (and practically no platform is immune, depending on trade-offs one is willing to take).

Re: What’s New in ES2019

#265

Post by sdegutis » Tue, Jul 30, 2019, 5:01 PM UTC

untog wrote: post #155

qudat wrote: post #150

Earlier quoted context omitted.

> 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 you are building a modern web "app", not a one off set of web pages, then yes, it is the standard. It would be very weird to not see a compile (transpilation) step.

It's becoming less and less necessary. If you don't care about browsers with tiny usage you can ship ES6 as-is these days. All the main browsers support ES6 modules. And HTTP2 means having all those modules in different files doesn't have the huge performance impact it once did. About the only thing left (that isn't easily solvable) is stripping comments and minifying.

Versioning files is still a need too.

Re: What’s New in ES2019

#266

Post by [deleted] » Tue, Jul 30, 2019, 5:01 PM UTC

delinka wrote: post #80

ahmedfromtunis wrote: post #66

Can someone please point me to the rationale behind the new toString() function?

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.

[deleted]

Re: What’s New in ES2019

#267

Post by kbp » Tue, Jul 30, 2019, 5:03 PM UTC

speeder wrote: post #146

simias wrote: post #139

Earlier quoted context omitted.

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 s…

Sadly the "mostly" is because threads :( It is the part I was most excited about C99 and was very disappointed that it is so poorly supported.

Threads are C11, not C99.

Re: What’s New in ES2019

#268

Post by bryanlarsen » Tue, Jul 30, 2019, 5:03 PM UTC

mmartinson wrote: post #243

padolsey wrote: post #113

Earlier quoted context omitted.

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

I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good. JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm. For many progr…

Typescript removes some of the nastiest Javascript features. Of course that's not it's raison d'être and it includes a bunch of stuff you may not care for. However it is what is currently occupying the niche you're asking for. And it has all the advantages parent mentions.

Re: What’s New in ES2019

#269

Post by thothamon » Tue, Jul 30, 2019, 5:03 PM UTC

baddox wrote: post #234

pault wrote: post #158

Earlier quoted context omitted.

> It's popular to be sure but handwritten javascript is not that rare nowadays, is it? Long time front end developer here. In the last couple of years I can't recall seeing even a single project without a build pipeline (not that they don't exist, I just haven't encountered them at my day job, first or third party).

I don't understand what is so appealing about not having a build pipeline for JavaScript, other than the ability to very quickly test and learn things directly in the browser, which of course anyone can still do. For anything remotely important, you're almost certainly going to already want a build pipeline to do things like concatenating/minifying code, running tests, and deploying. Adding a transpilation step to ex…

I have no concerns about having a build pipeline per se. My concern is that it's still way too complex and difficult. I think it could be made to be much simpler for 90 percent of cases, while still maintaining optional complexity for the remaining 10 percent of cases that need it.

Re: What’s New in ES2019

#270

Post by WorldMaker » Tue, Jul 30, 2019, 5:12 PM UTC

snek wrote: post #137

icholy wrote: post #108

Earlier quoted context omitted.

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

It wasn't TS's idea, stage 3 exists purely for getting feedback from implementations about implementing and using the feature.

It was TS's 2.0+ idea to stick to Stage 3 like glue. Especially prior to 1.0, but even during 1.x, TS implemented proposals in stages earlier to 3 (or even not yet staged). One of the regrets you sometimes hear from TS devs is that they added decorators way too early (it's still not Stage 3 and increasingly likely if it ever hits Stage 3 it will look very different, and it may never hit Stage 3 because there is a bunch of opposition), even though that is behind an "experimental" flag, there's a huge amount of "Production" code written with decorators in Typescript. (Largely thanks to the Angular ecosystem that became hugely dependent on decorators.)