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

241–250 of 411 posts

Re: What’s New in ES2019

#241

Post by dntrkv »

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 aren't just new syntax, they keep the context in which they are declared.

It allows devs to do the following:

onClick={() => doSomething()}

Without having to worry about binding the function to the correct context.

Re: What’s New in ES2019

#242

Post by la12 »

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

>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

In that case, they should have deprecated the "function(){}" notation or at least made it such that arrow function doesn't overlap it.

The current scene is that most people don't know what the real difference between arrow and function notations and this leads to a lot more number of bugs than if they weren't this overlapping. Overall, my point is, this just leads to poor ergonomics and you'll have a larger number of avoidable bugs.

Re: What’s New in ES2019

#243

Post by mmartinson »

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

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 programming situations it'd be easy to just pick a different language, but obviously thus isn't the case for writing browser-based programs.

The best possible scenario for me would somehow involve deprecation and removal of the nasty parts of JS, and a path towards a smaller, simpler, more consistent language. Right now it feels like the cost of backwards forever compatibility is paid every day, in every project, and it's completely wasteful, given that transpile and polyfill is widely considered best practice.

Whether this could the job of TC39 or some other institution could go either way for certain.

Re: What’s New in ES2019

#244

Post by ptx »

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 function notation

Arrow functions bind this to the lexical scope, which is useful. (In a regular function the value of this depends on how it's called.)

> python which was resistant to the idea of 20 ways to do the same thing

This was in comparison to Perl which intentionally has an unusual excess of different ways to do things.

> "walrus" operator

Simplifies a very common pattern.

  m = re.match(r"my_key = (.*)", text)
  if m:
      print(m.group(1))

Re: What’s New in ES2019

#245

Post by ergothus »

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…

> we still need to target es5 4 years later,

This is a dramatic improvement over the 10 year lifespan of IE6 with es3. Once the need to target es5 drops, the next level gets even shorter - I don't think we'll get less than 2 years as a practical matter, but even at a 2 year delay, that's still regularly progress.

> a pretty arbitrary subset of the language

Best practices don't come from a mathematical model - programming is about communication and being compatible with user/business demands (which keep changing). Thus, best practices come about from a lot of experimentation and retrospective. That's ongoing. This doesn't mean it won't settle down. Heck, as it is, a lot of dynamic best practices influence the direction of non-dynamic languages - all of which arises from time and experimentation.

Re: What’s New in ES2019

#246

Post by hajile »

Gene_Parmesan wrote: post #181
halfmatthalfcat wrote: post #47

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining

I adore pattern matching when done well, but I'm sorry -- that syntax seems terrible and confusing. The use of `{ }` seems arbitrary. In JS braces are already used for both scope-delimiting and object literal notation; now they're going to have a third job? There has to be a better way. I understand it's based on destructuring; the syntax still just doesn't work for me.

Ocaml, StandardML, F#, Erlang, and Rust all use that syntax for pattern matching. What other syntax would you propose to test values in a JS object?

Re: What’s New in ES2019

#247

Post by mantap »

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.

You tell such users: "Your browser is too old, please update it" and direct them to the Chrome and Firefox websites.

With the exception of Safari, all major browsers support auto-updating, and anybody who intentionally uses an outdated version of Safari is a masochist with a deviant fetish for error messages.

Re: What’s New in ES2019

#248

Post by hombre_fatal »

dsego wrote: post #129
Accacin wrote: post #115

Earlier quoted context omitted.

Well, I'd think that was pretty obvious, right? It's exciting because if you spend the day writing JavaScript I don't give a hoot that another language has had that feature for decades because I don't get to use that other language. Are you implying that no other languages ever add features that other languages have? All languages except JS are feature complete? Come on..

Well now, having an option to use other languages to script web pages, that would be exciting.

The better JS gets, the more I want to use it. JS with Promises + async/await is now one of my favorite languages.

Re: What’s New in ES2019

#249

Post by spankalee »

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…

You don't necessarily need to target ES5.

What percentage of your users is on IE11? Are you making money from them? Can you serve only them a compiled bundle?

Re: What’s New in ES2019

#250

Post by baddox »

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…

> Is the evolution of JS not directed in practice by the authors of Babel and Typescript?

In practice? I suppose in practice, JavaScript is driven by everyone in aggregate and what people consider to be "JavaScript" rather than "something that can be made to run in traditional JavaScript environments like browsers." I'm not sure if you mean that, or simply who directs actual changes to the traditional JavaScript environments (like browsers) themselves.

But yeah, if transpilation tools are reliable and continue to be well-maintained, you can say "why bother updated the 'official' language and implementation in browsers?" But I don't understand how this is a bad thing. You're getting the best of both worlds: browsers will implement new JavaScript features and optimizations, and some dev teams can also use build tools to use those new features, and other potential new features, and still make their work available to older browsers.

It doesn't seem like a problem to me, unless you're thinking about all the language development effort in the JavaScript community as a fixed pie such that "non-official" language development like Babel and TypeScript take away effort that otherwise would be allocated to official language development. And I certainly don't think that is the case.

Post reply on HN