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

351–360 of 411 posts

Re: What’s New in ES2019

#351

Post by tracker1 »

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

Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need? I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's ho…

There's a handful of unsupported features I play with... the null operators and pipelines in particular. But I do set my presets for pretty modern support as a baseline. I still use webpack as well.

Re: What’s New in ES2019

#352

Post by korm »

SahAssar wrote: post #302
baddox wrote: post #234

Earlier quoted context omitted.

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…

The appealing thing about not having a build pipeline is not having it. Not having another thing to maintain and update/upgrade/debug. I've gone through grunt, gulp, webpack and parcel. Somewhere along the way I realized that with es6 imports and css variables I don't really need it. I've talked with frontend devs who only worked on projects with build steps about this and they often seem perplexed and surprised by j…

Can you imagine a modern SoundCloud, Spotify, Facebook, Airbnb or Slack without a build pipeline? There's nothing appealing about that.

It's nice and simple for small projects but let's not act like putting a script tag in HTML is some divine wisdom that newbies don't understand.

Re: What’s New in ES2019

#353

Post by rndgermandude »

orta wrote: post #95
Dextro wrote: post #11

Earlier quoted context omitted.

Yes, this is a real problem and I've been bitten by it more times than I can count. Now I always keep this handy website ready: https://doesitmutate.xyz/

TypeScript does a pretty good job here if you're willing to add a bit of extra syntax: const a = [1,2,3] a.push(4) const b: readonly number[] = [1,2,3] b.push(4) // Property 'push' does not exist on type 'readonly number[]'.

Well, Object.freeze in plain JS can help too.

    > Object.freeze([1,2,3]).push(4)
    TypeError: can't define array index property past the end of an array with non-writable length (firefox)
    Uncaught TypeError: Cannot add property 3, object is not extensible (chrome)
Of course, it will only blow up at runtime. But better than not blowing up at all, creating heisenbugs and such.

I often find myself writing classes where the last step of a constructor is to Object.freeze (or at least Object.seal) itself.

Re: What’s New in ES2019

#354

Post by algorithm_dk »

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

Would the else branch trigger on a falsy value, or on an exception? It's a bit confusing, as it looks like it would handle exceptions on the else branch, even though we know we have to wrap await in try/catch for that.

Other than saving a few characters (the variable name), I don't see any benefit of this, while it makes code harder to read.

Too bad the `with` [0] keyword has been reserved for crap, it sounds nice (not for this, but maybe for something else).

>> and also requires you to start renaming variables (ie. row1, row2...) due them going over their intended scope

Variable shadowing [1] is a really bad practice that makes it hard for people to collaborate and keep the code sane. Bad habits are not a reason for language changes.

[0] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] - https://en.wikipedia.org/wiki/Variable_shadowing

Re: What’s New in ES2019

#355

Post by jlokier »

robocat wrote: post #44
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.

It also requires that comments get stored and waste memory: previously just enough of the AST needed to be stored to be able to regenerate the JavaScript. You can't throw away the comments because you can't predict where code might do someVarHoldingAFunc.toString() It seems like an unnecessary change - if the source needs to be accessed then get the source file.

ES doesn't store quite enough of the AST to recreate the function anyway. Most functions reference variables and functions defined in a lexical scope outside themselves. Getting the source with toString(), and passing that to eval(), doesn't reproduce the function, and sometimes it compiles ok but the function does the wrong thing.

Usually it doesn't matter, because these methods are used on functions that luckily only use well known names, mainly properties of window/global.

But it's a risk, and I've seen subtle bugs caused by the assumption that the function's .toString() can be run through text substitutions and eval to get back a variant of the original code.

Contrived example:

  let x = "wrong variable";

  function f() { let x = "I am x"; return function g() { return x; } } 
  f()()
  => 'I am x'
  
  eval(f().toString())
  g()
  => 'wrong variable'

Re: What’s New in ES2019

#356

Post by SahAssar »

korm wrote: post #352
SahAssar wrote: post #302

Earlier quoted context omitted.

The appealing thing about not having a build pipeline is not having it. Not having another thing to maintain and update/upgrade/debug. I've gone through grunt, gulp, webpack and parcel. Somewhere along the way I realized that with es6 imports and css variables I don't really need it. I've talked with frontend devs who only worked on projects with build steps about this and they often seem perplexed and surprised by j…

Can you imagine a modern SoundCloud, Spotify, Facebook, Airbnb or Slack without a build pipeline? There's nothing appealing about that. It's nice and simple for small projects but let's not act like putting a script tag in HTML is some divine wisdom that newbies don't understand.

Yes I can. All of those except for facebook (because facebook is a sprawling platform) seem reasonable to be able to build without a build system. And with using es6 modules it's not "putting a script tag in HTML", you have a proper module loading system without needing any builds or libs.

I'm not saying it's some sort of lost knowledge like Damascus steel, I'm just saying that many people these days are so caught up into the current dogma of JS that they never consider a simpler but still modern path.

Re: What’s New in ES2019

#357

Post by soulofmischief »

choward wrote: post #154
soulofmischief wrote: post #136

Earlier quoted context omitted.

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.

> is-even is literally just `(n % 2) === 1` Pretty sure that tells you if a number is odd. I guess maybe there is a reason these libraries exist.

That was just a typo, I meant the source for is-odd. I copy-pasted it. I use that exact syntax all the time in code, you don't need to be patronizing.

Re: What’s New in ES2019

#358

Post by z3t4 »

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…

Always try to limit the scope of variables. Use local scope. And also functions within functions. The nice part when limiting scope is that you never have to scroll or look elsewhere in order to understand what a piece of code does.

Re: What’s New in ES2019

#359

Post by ZenPsycho »

STRML wrote: post #196
soulofmischief wrote: post #140

Earlier quoted context omitted.

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

As in the MDN article: All major engines have also implemented corresponding trimLeft and trimRight functions - without any standard specification. So ES2019 implements trimStart() and trimEnd(), which are symmetrical to padStart() and padEnd(), but trimLeft() and trimRight() aliases are maintained as not to break working code.

That makes sense, "left" trimming rtl text could be confusing.

Re: What’s New in ES2019

#360

Post by jazzyjackson »

ojosilva wrote: post #182
shortercode wrote: post #168

Earlier quoted context omitted.

I know this doesn't match up entirely with what you want syntax wise, but the following works and I consider it quite elegant. { let row; if (row = await db.findOne()) { // } else { // } }

It's not the same. For instance, you could not use a `const` variable. Also having "phantom" scope blocks get very nasty to read once you have more involved logic, as the block itself has no implied meaning and the programmer has to walk a few lines into it to get what's going on.

You could always make it a labelled block statement !
Post reply on HN