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

201–210 of 411 posts

Re: What’s New in ES2019

#201

Post by sdegutis »

snek wrote: post #164
pas wrote: post #109

Earlier quoted context omitted.

It seems that only `when` and `->`is the new syntax, no? The arrow seems something that could be replaced with `=>`, but anyway, neither seems to be very restrictive with regards to future syntax. (After all they are only defined in a `case` context, so the can be reused for whatever future purpose outside.) Plus it's a stage1 proposal, meaning it's far from serious. Could you link the type annotation proposal, I can…

There is no type annotation proposal.

TypeScript is becoming the de facto type annotations proposal.

Re: What’s New in ES2019

#202

Post by rictic »

saghm wrote: post #190
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…

> 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. Sure, but if C came out with a new standard every year, you'd essentially never be on the latest version. Isn't there at least a valid argument to slowing down a bit to give the implementations a chance to catch up instead of having a new ES 20XX every ye…

The implementations that are moving at all are keeping up fine. The biggest question for web developers is whether they support IE. If you do, you're stuck on ES5. If not, you can use most features from ES2015 and up. Once the next release of Edge is out, that will expand greatly.

Even if you support IE, you can still reap the benefits of modern JS if you're willing to do some differential serving. You can use the module/nomodule pattern to serve ES2017 without making changes to the server.

Re: What’s New in ES2019

#203

Post by TazeTSchnitzel »

pault wrote: post #166
ojosilva wrote: post #138

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() ) {…

In my opinion this is a terrible idea, since it's very easy (I do it all the time) to accidentally write `if (foo = bar)` instead of `if (foo == bar)`. If that were valid syntax it would be a huge footgun. I'd be onboard with it if it required a different syntax.

But JS already allows that.

Re: What’s New in ES2019

#204

Post by acdha »

mmartinson wrote: post #179
acdha wrote: post #141

Earlier quoted context omitted.

> If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Your “we” isn’t everyone else’s. Some places need to support very old browsers but even in places like that usually not every app does. Those people are pushing the state of the art forward since they do real work outside of the standards process and that provides useful feedback to both the standards committees and br…

Fair, JS is everywhere and serves many use cases. The implicit "we" in that statement is developers 2019 who are building client side applications that need to get a lot done, run in most installed browsers, and remain maintainable to a 5-8 year horizon. Not everyone for certain, but probably enough to generalize, at least on this forum.

Again, that really depends on what features you use and who your clients are. It's entirely possible that a team may not need IE11 support now or that they've moved in the direction of low-overhead for modern clients and a legacy mode (possibly transpiled) for the At some point this is a business decision like anything else and the security considerations in particular have helped get people onto evergreen browsers faster than used to seem possible.

Re: What’s New in ES2019

#205

Post by ohaideredevs »

dsego wrote: post #99
zitto wrote: post #91

It's very exciting to see how JavaScript is evolving!

Honest question, not playing. What is exactly exciting about it? 2020 is around the corner and the language created back in 1995 is only now getting features that have been standard in many other languages, either as part of the core language or the standard library for decades.

I can write things in Javascript 5x faster than I can write things in C#. I am finally convinced .NET Core is inferior to Node for that reason, unless I am writing something that needs to be super accurate/performant.

And it has brackets.

Re: What’s New in ES2019

#206

Post by fenomas »

ubertaco wrote: post #188
pault wrote: post #166

Earlier quoted context omitted.

In my opinion this is a terrible idea, since it's very easy (I do it all the time) to accidentally write `if (foo = bar)` instead of `if (foo == bar)`. If that were valid syntax it would be a huge footgun. I'd be onboard with it if it required a different syntax.

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 }

> if (foo = bar()) { // syntax error!

That's already an error in strict mode (which would presumably be on for anyone writing bleeding-edge JS).

Re: What’s New in ES2019

#207

Post by jolmg »

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.

> Also, a new feature I want to use needs only be supported by one C compiler: the one I'm using.

I've always had the impression that C programmers also care about standards compliance, and aren't typically willing to marry their project to a particular compiler.

At least, it's the language community where you see "language lawyers". I'm sure there are "language lawyers" in other language communities, but I've never seen discussions about what causes "undefined behavior" or what's "implementation dependent" or discuss interpretations of particular passages of the standard like I do with the C and C++ communities.

Re: What’s New in ES2019

#208

Post by LukeBMM »

pault wrote: post #158
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 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 agree in broad terms, but as a counterpoint, those build pipelines are being created and used primarily by folks who initially learned by handwriting javascript.

While less of a consideration for established teams, it dramatically raises the barrier to entry for those who are learning as well as those who currently have much simpler requirements. Those are the future members of that established team. Adding hurdles to the process of learning will, in the long run, result in a smaller, more homogeneous pool of experienced developers to draw upon. It's a self-perpetuating cycle - making folks learn by using complex build scripts will result in experienced developers who then create further complexity because they've self-selected to be those who happen to think in that mode.

That's not intended to suggest that progress is bad. Rather that it's a bit short-sighted of us, as an industry, not to consider the ramifications of enforcing a workflow that happens to be trivial from the limited perspective of long time front end developers.

{ Edit to try to make the last paragraph sound less accusatory. Sorry! That wasn't my intention. }

Re: What’s New in ES2019

#209

Post by alexlur »

snek wrote: post #120
alexlur wrote: post #35

That Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.

The Function.prototype.toString change has been in chrome for maybe a year now btw.

Oh wow. Looks like I’m wrong.

Re: What’s New in ES2019

#210

Post by davidjnelson »

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

Mutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i Proper immutable support (or a stronger concept of const) would also help with this.

Typescript readonly properties and types are amazing for this. ReadonlyMap, ReadonlyArray, Readonly.
Post reply on HN