Live data from Hacker News

What’s New in ES2019

blog.tildeloop.com

231–240 of 411 posts

Re: What’s New in ES2019

#231

Earlier quoted context omitted.

If your C code is upgraded from C n to to use C n+1 features, then it breaks compilers that do not support c n+1. This is not a problem for end-users, because most people do not compile the code themselves, but use pre-built binaries. So, it is a problem for the package maintainer to deal with, the package maintainer upgrades their compiler and the new binaries just work for the end user, because once compiled it doe…

> If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all. I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.

If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them.

The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse.

All the original commenter meant is that the people making the software can't ever guarantee what version of JS the end user's browser can handle.

Re: What’s New in ES2019

#232

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…

We're in the age of "evergreen" browsers, where almost everyone is on a browser that auto updates. New features can be useable in maybe 2 years now, depending on your audience.

[laughs in enterprise web app]

Re: What’s New in ES2019

#233
arr.flat(Infinity) seems like a strange decision for flattening the entire array - wouldn't the most common number of levels to flatten an array be all levels, in which case I'd expect arr.flat() to flatten the whole array but in this case it's just 1 level.

Re: What’s New in ES2019

#234
post #158
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 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 extend support to older browsers comes with almost no cost to time or maintainability, assuming you're using well-supported things like Babel and its official plugins.

Re: What’s New in ES2019

#235

Object.fromEntries will be super useful, surprised it’s taken this long to become a native feature.

Really though, don't know why this isn't the most mentioned feature in this thread, processing objects in JS has always been annoying.

Re: What’s New in ES2019

#236
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 function made `this` much more intuitive while maintaining backwards compatibility. That's definitely bringing something to the table.

Re: What’s New in ES2019

#237
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…

>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.

Incorrect - The main advantage is fat arrow syntax can keep lexical scope of this current context. Hence you dontneed to implement that=this antipattern

Re: What’s New in ES2019

#238

A year back I dropped a proposal idea at the EcmaScript discussion list, I hope it get's picked up sometime. My idea is that `let`, `var` and `const` return the value(s) being assigned. Basically I miss being able to declare variables in the assertion part of `if` blocks that are scoped only during the `if()` block existence (including `else` blocks). Something along these lines: if( let row = await db.findOne() ) {…

You can also declare variables in conditional statements in C/C++ like https://godbolt.org/z/h0BR8K

  int foo(int);
  int bar(int x) {
    if (int y = foo(x)) return 0;
    return x;
  }

Re: What’s New in ES2019

#239

Earlier quoted context omitted.

> If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all. I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.

If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them. The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse. All the original comme…

> If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them.

Right, but if the developer transpiles their source code and distributes it then the JS end-user is in the same situation as the C binary user. Distributing ES6 code without transpiling it is akin to distributing C source code without compiling: the end-user would need to have an up to date compiler/runtime to execute the code.

Re: What’s New in ES2019

#240
post #139

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…

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 popular to be sure but handwritten javascript is not that rare nowadays, is it?

Even if you’re only targeting evergreen browsers, the popular build tools also perform minification and dependency resolution/linking. There’s so much a tool like webpack can do for you that I imagine it will remain hugely popular even as the need for transpilation wanes.

Post reply on HN