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

131–140 of 411 posts

Re: What’s New in ES2019

#131

Post by masklinn »

soulofmischief wrote: post #125
masklinn wrote: post #84

Earlier quoted context omitted.

Rather than how complete it is, the real improvements of the proposal are: 1. it all but requires that ES-defined functions stringify to their source code. Pre-ES2019 that's implementation-defined 2. it standardises the placeholder for the case where toString can't or won't create ECMAScript code (e.g. host functions), this could otherwise be an issue as with implementation-defined placeholders subsequent updates to…

Ok that makes sense... I was really confused because that's already more or less toString()'s behavior on modern browsers, though the whitespace discrepancy is important to define.

That's in part because it was fed back through browsers during the specification process.

Re: What’s New in ES2019

#132

Post by snek »

swalsh wrote: post #56

Some half decent stuff in here, but I heavily disagree with changing the output of toString. That might cause problems if someone is expecting one output, but the new version creates something new. I don't see a reason why they couldn't have just added a new function functionCode() or something similar. It would give people the functionality they want, without destroying backwards compatibility.

It's already been deployed in the wild for about a year.

Re: What’s New in ES2019

#133

Post by schwartzworld »

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…

There are certain sectors in which backwards compatibility is important, but most people developing can confidently use ES2015+ features directly in the client without polyfill.

Re: What’s New in ES2019

#134

Post by erik_seaberg »

specialist wrote: post #106
jwilliams wrote: post #39

Earlier quoted context omitted.

I see what you're saying - for me, my experience with Java checked exceptions put me off the idea. In Java it led to lots of exception wrapping and leaky abstractions. Not sure what the answer is - although my golang experience was better.

My current best guess is Java's checked exception silliness comes from the enterprise framework culture. Too much abstraction, architecture, cleverness, turgidity. I joke that Spring is an Exception obfuscation framework. I've always really liked checked exceptions in my own designs. Though I'm not crazy about the syntax.

Java blew it on generic exceptions.

  stream.map(f).collect(...)
should be able to throw anything f can throw, but instead f has to wrap everything, which makes people give up and stop declaring checked exceptions.

Re: What’s New in ES2019

#135

Post by svieira »

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

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

Gating on stage-3 really helps. (I have done the same on projects I work on and it helps) There are times when you need to consider the complexity of the specification and the amount of contention around it (decorators / SIMD for example).

IMO, anything below that is effectively a custom macro anyway (for which you may want to consider sweet.js or babel.macro to make it clear that this may change and help you find places you use the feature). Real-world feedback may change anything from syntax to behavior (`flatMap -> flat`, `Object.observe -> Proxy`, `EventEmitter -> Observable -> Emitter?`, and the it-feels-like-dozens-of-options pipeline syntax)

Re: What’s New in ES2019

#136

Post by soulofmischief »

tomduncalf wrote: post #119
Dirlewanger wrote: post #107

Can we get some additions that replace the garbage one-liner `is-even`/`is-odd` npm libraries that are a scourge?

You mean something like x % 2 === 1? I'm a JS fan but had to admit I chuckled at the implementation of is-even: https://github.com/jonschlinkert/is-even/blob/master/index.j...

That's hilarious.

What's not hilarious is that, after removing the essentially useless error-checking, is-even is literally just `(n % 2) === 1`. On one hand, JS desperately needs a standard library, on the other hand, JS devs can be so infuriatingly lazy and obtuse.

Re: What’s New in ES2019

#137

Post by snek »

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

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.

Re: What’s New in ES2019

#138

Post by ojosilva »

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() ) {
         // row available here
    }

    // row does not exist here
The current alternative is to declare the variable outside the `if()` block, but I believe that is inelegant and harder to read, and also requires you to start renaming variables (ie. row1, row2...) due them going over their intended scope.

As previous art, Golang's:

      if x:=foo(); x>50 {
        // x is here
      }
      else {
        // x is here too
      }
      
      // x is not scoped here
And Perl's

      if( ( my $x = foo() ) > 50 ) {
           print $x
      }

Re: What’s New in ES2019

#139

Post by simias »

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…

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 sure that if you still have to write javascript code 10 years from now you'll be happy to be able to use the features of ES2019.

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?

Re: What’s New in ES2019

#140

Post by soulofmischief »

alexlur wrote: post #33
ZenPsycho wrote: post #30

seems like a real missed opportunity to add string.leftPad()

String#padStart already exists: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

But we still have trimLeft() and trimRight() and in true JS tradition we need some more redundancy for symmetry's sake.
Post reply on HN