Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s New in ES2019

blog.tildeloop.com

Post reply on HN
Print view View original

281–290 of 411 posts

Re: What’s New in ES2019

#281

Post by munificent »

ken wrote: post #167
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…

> That's not unique to JS. Some compilers took over a decade to implement C99 features. I sometimes wonder what's the point of new versions of C, too. Also, a new feature I want to use needs only be supported by one C compiler: the one I'm using. With JS, I need all of them to support it.

I don't think I ever write C code that I intent to only be compiled using one compiler. One of the primary reasons I use C is to write cross-platform code, so I care about GCC, Clang, and VS, at least.

Re: What’s New in ES2019

#282

Post by munificent »

dotancohen wrote: post #255
ubertaco wrote: post #188

Earlier quoted context omitted.

I'm down if you require a let/var/const in front of it: if (foo = bar()) { // syntax error! } if (let foo = bar()) { // works fine } if (const foo = bar()) { // also works fine } if (var foo = bar()) { // also also works fine }

And what if foo had already been defined in the scope?

The new one shadows it.

Re: What’s New in ES2019

#283

Post by hajile »

addicted wrote: post #117
heavenlyblue wrote: post #21

Earlier quoted context omitted.

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();

Without getting into the merits of allowing redefines in a loosely typed language, the simple reason why JS can't support this is hoisting. Any var/let statement of the form var a = 1; is interpreted as 2 statements. (1) The declaration of the variable which is hoisted to the beginning of the variable scope, and the (2) setting of the value, which is done at the location the var statement is at. Having multiple let s…

That's not quite accurate. It's actually the reverse.

Think of the closure as an object. It contains variables like `this`, `arguments`, a pointer to the parent closure, all your variables, etc.

The interpreter needs to create this closure object BEFORE it runs the function. Before the function can run, it has to be parsed. It looks for any parameters, `var` statements, and function statements. These are all added to the list of properties in the object with a value of `undefined`. If you have `var foo` twice, it only creates one property with that name.

Now when it runs, it just ignores any `var` statements and instead, it looks up the value in the object. If it's not there, then it looks in the parent closure and throws an error if it reaches the top closure and doesn't find a property with that name. Since all the variables were assigned `undefined` beforehand, a lookup always returns the correct value.

`let` wrecks this simple strategy. When you're creating the closure, you have to specify if a variable belongs in the `var` group or in the `let` group. If it is in the `let` group, it isn't given a default value of `undefined`. Because of the TDZ (temporal dead zone), it is instead give a pseudo "really undefined" placeholder value.

When your function runs and comes across a variable in the let group, it must do a couple checks.

Case 1: we have a `let` statement. Re-assign all the given variables to their assigned value or to `undefined` if no value is given.

Case 2: we have an assignment statement. Check if we are "really undefined" or if we have an actual value. If "really undefined", then we must throw an error that we used before assignment. Otherwise, assign the variable the given value;

Case 3: We are accessing a variable. Check if we are "really undefined" and throw if we are. Otherwise, return the value.

To my knowledge, there's no technical reason for implementing the rule of only one declaration aside from forcing some idea of purity. The biggest general downside of `let` IMO is that you must do extra checks and branches every time you access a variable else have the JIT generate another code path (both of which are less efficient).

Re: What’s New in ES2019

#284

Post by james-mcelwain »

ohaideredevs wrote: post #187
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.

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.

Imagine we have a list of some values and map a function that returns a list of some other type. In other words, for every value in the list, we replace it with the results of calling our function, which returns a list. We have introduced nesting and now are operating on a "list of lists of values" rather than a list of values.

However, generally you don't want to operate on a list of lists and are trying to process each value one by one -- the nesting doesn't add anything. In this case, we use flatMap, which "flattens" or concatenates the interior lists so we can operate on them like it's just a big stream of values.

This is also the case for another type like `Optional`, which represents either a value `T` or the absence of a value. An optional can be "mapped" so that a function is applied only if there is a value `T` present. flatMap works the same way here, where if you want to call another method that also produces an `Optional`, flatMap will "unwrap" the optional since you never really want to work with the type `Optional>`.

Re: What’s New in ES2019

#285

Post by kbp »

Xavdidtheshadow wrote: post #273
afandian wrote: post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

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]

A method named "method!" means that it's a somehow "unsafe" version of the method "method". A lot of the time it means "destructive version," but if there's no non-destructive version, the destructive one won't have a ! (eg, Array#shift), and sometimes ! means something else (eg, Kernel#exit! is like Kernel#exit, but doesn't run any at_exit code).

Re: What’s New in ES2019

#286

Post by bzbarsky »

intea wrote: post #65

Why are empty elements in an array allowed? oO [1,2,,3]

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.

Re: What’s New in ES2019

#287

Post by mmckelvy »

mmartinson wrote: post #101

Honest question, not meant to be inflammatory. 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. I like the idea of idiomatic…

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.

Re: What’s New in ES2019

#288

Post by unilynx »

la12 wrote: post #220

At this point, I'm convinced that Javascript is basically a jobs creation program. We go on adding fancy new syntax for little or no gain. 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. Similarly, python which was resistant to the idea of 20 ways to do the same thing, also…

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.

Re: What’s New in ES2019

#289

Post by EB66 »

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…

> Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability

They may be simple concepts, but there's definitely still an added cost with transpilation and minification steps.

If you work with Babel long enough you'll encounter scenarios where the transpiling didn't quite work as expected and breaks in-browser.

When you're debugging minified code in-browser using source maps, it's not all that uncommon to get different line numbers and stack traces than you get when loading up the original unminified source. I can recall a number of occasions where I had to deploy unminified source for in-browser debugging because the source maps were obfuscating the real error.

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Re: What’s New in ES2019

#290

Post by DonHopkins »

mantap wrote: post #280
DonHopkins wrote: post #253

Earlier quoted context omitted.

And in the idealized fantasy world of Ayn Rand, any giant dinosaur enterprise corporation who insists on using antique outdated Jurrasic browsers deserves to be bitch-slapped by the invisible hand of the market into extinction for their outrageously dangerous security and privacy policies. To bad the real world doesn't work the same as it does in self-indulgent libertarian porn...

The real world works exactly like that. It's called System Requirements . If you want to use a piece of software, you look at the requirements and if you don't meet the requirements then you can't install it. All websites have system requirements, no matter how non-libertarian they seek to be, for example most websites will not work on IE6. It is not a fantasy to inform users that they don't meet the requirements, it…

I mean the real world is not like Atlas Shrugged, which is archetypical self-indulgent libertarian fantasy porn. The invisible hand isn't God setting things right and making life fair, it's rich assholes (who worship Ayn Rand and think they're God) rigging the system to cheat for themselves.

NSFW link:

https://www.cbsnews.com/news/ayn-rand-vs-the-invisible-hand-...

Post reply on HN