What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#401

Post by partomniscient » Thu, Aug 01, 2019, 10:46 AM UTC

Crinus wrote: post #216

syntheticcdo wrote: post #199

Earlier quoted context omitted.

It's a bit different with compiled code though right? If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler, the executable will work for everyone on that platform once built. Whereas in JS-land, the support for upgrades is even more trailing because it's the end-users who need to upgrade, not just the individual/organization doing the packaging.

> If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.

Where C11 > C99.

Talk about naming problems / sorting problems. They've adopted Microsofts versioning system where Windows 8 is newer than both Windows 98 and Windows 2000.

Does anyone remember the Y2K problem. Anyone?????

They worked out naming things properly (where computers are involved) was a big problem in the 1960's. But we still only allocated 3 bytes for the version of C or something...?

Re: What’s New in ES2019

#402

Post by h1d » Thu, Aug 01, 2019, 2:11 PM UTC

iraldir wrote: post #18

kuon wrote: post #6

The part about parameter less catch reveals a lot about the philosophy of the language. For me, silencing error like this is a bad practice. You may still produce a sane error in the catch, but the design goes toward silencing things. I really love languages that force you to handle errors up to the top level.

It does, though I wouldn't go to the same conclusion. It gives more freedom to the developer. They are lot of cases where errors are in fact, expected. Parsing a user inputted JSON. Making a request to check internet connection availability. Any promise that is going to be consumed by an async - await pattern. In those cases (and many more), you may want to try something just simply to see if it works. It's completel…

Why would you ever want to ignore the error parameter?

I really hate when a system tells me "Unknown error occured" or "Either this or that happened" because the software doesn't care to be specific with the errors.

You should at least log the error message, not ignore it.

Re: What’s New in ES2019

#403

Post by soulofmischief » Thu, Aug 01, 2019, 2:42 PM UTC

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.

You're right, I was just being tongue-in-cheek.

Re: What’s New in ES2019

#404

Post by kdmccormick » Thu, Aug 01, 2019, 2:51 PM UTC

wbercx wrote: post #399

kdmccormick wrote: post #366

Earlier quoted context omitted.

> Only helps with const. Can you elaborate?

If the `x` in the example was a const, it would throw an error because the code attempts to assign the value of `y` to `x`. You cannot assign a new value to a const.

What I'm saying is that you wouldn't accidentally type `let x = y` when you meant to type `x == y`

Re: What’s New in ES2019

#405

Post by eropple » Thu, Aug 01, 2019, 7:02 PM UTC

orange8 wrote: post #396

eropple wrote: post #386

Earlier quoted context omitted.

"I didn't have to write a test to know that I am passing a data structure correctly across every module of my application" is not a "taste" thing and comparing TypeScript to nominative typing isn't a reasonable and fair tactic. We have legacy JavaScript dependencies and most of them worry me. I don't stay up at night worrying about the domain and range of TypeScript ones even if their testing is weak. There's a reaso…

If you write JavaScript with a c# frame of mind, of-course you'll find it akward and hard to test. TypeScript is basically JavaScript written in a c# frame of mind, and there is nothing wrong with that. If it helps some people be more productive, then more power to them. but don't fool yourself that TypeScript is the best way to do JavaScript. If you're finding writing maintainable apps in plain JavaScript hard then…

I don't have a good way to describe this post as anything but not-even-wrong. "Hint, it's a functional language"--types are orthogonal to whatever functional-versus-OO dichotomy you've invented in your head. Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither--so, definitionally, you can't achieve them in JavaScript. And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive". Should one need to go outside those gradual type strictures, `any` is right there.

I knew JavaScript cold well before I was using TypeScript and I've shipped both mobile and web applications using JavaScript, as well as writing a solid amount of high-performance backend systems. And I ended up writing an eye-gouging number of tests that go away with TypeScript. It is literally, not figuratively, a way to dismiss entire classes of bugs. I may not understand JavaScript, but I'm not the one making factually inaccurate assertions about stuff up in here and that makes me really wonder how solid your conclusions can possibly be.

But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.

Re: What’s New in ES2019

#406

Post by Accacin » Thu, Aug 01, 2019, 8:46 PM UTC

sev wrote: post #278

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…

If this is a major concern for you, you might want to use something like immutableJS[0]. More often than not I’ve found it unnecessary except in very contained parts of a large app, but in case it’s helpful I wanted to point it out. [0] - https://github.com/immutable-js/immutable-js

Another one that I personally prefer is Immer.js[0]

[0] - https://github.com/immerjs/immer

Re: What’s New in ES2019

#407

Post by orange8 » Thu, Aug 01, 2019, 11:30 PM UTC

eropple wrote: post #405

orange8 wrote: post #396

Earlier quoted context omitted.

If you write JavaScript with a c# frame of mind, of-course you'll find it akward and hard to test. TypeScript is basically JavaScript written in a c# frame of mind, and there is nothing wrong with that. If it helps some people be more productive, then more power to them. but don't fool yourself that TypeScript is the best way to do JavaScript. If you're finding writing maintainable apps in plain JavaScript hard then…

I don't have a good way to describe this post as anything but not-even-wrong. "Hint, it's a functional language"-- types are orthogonal to whatever functional-versus-OO dichotomy you've invented in your head. Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither--so, definitionally , you can't achieve them in JavaScript. And given that TypeScript…

Your problem is the emotional denial that there is an engineering trade-off TypeScript makes by adding strict typing to JS. That trade-off is less flexibility and expression, and the gain is more fool-proof code, thats more familiar and comfortable to those more familiar with languages based on classes and strong typing.

> Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither

Whoa! That's a lot of words to basically say "JavaScript does not have static or inferential/derivable types". Kind of like the way type annotations create all that syntax noise. And I was talking about achieving the BENEFITS of "gradual and structural typing". It is done for the the benefits, not for its own sake. Do you even know the benefits? In proper JS, the same is easily achieved by duck-typing, and run-time checking whenever necessary.

> And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive"

I touched on the a bit when talking on trade-offs. A superset does not mean super like superman. it means an added layer of abstraction. You are moving further away from the metal, and leaving some decisions to the TypeScript compiler. That means giving away power, and flexibility to the compiler. A good engineer understands, and is not in denial about the trade-offs they are making.

> But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.

What really happens is that people outgrow their tribal instincts once they realize that this are all just tools that come and go, it is the underlying ideas that matter. JS absorbed all the best ideas from jQuery, and jQuery went. It has integrated all the best ideas from CoffeScript (js with a python frame of mind), and coffee-script is no longer the rage it was a few years back. Same is happening with TS, which is why my money is still on JS. The fact is, js will outlive ts.

Re: What’s New in ES2019

#408

Post by AgentME » Fri, Aug 02, 2019, 1:44 AM UTC

fenomas wrote: post #206

ubertaco wrote: post #188

Earlier quoted context omitted.

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

It's only an error in strict mode if there's no variable in scope named foo.

Re: What’s New in ES2019

#409

Post by TheRealPomax » Fri, Aug 02, 2019, 2:09 PM UTC

tracker1 wrote: post #351

TheRealPomax wrote: post #345

Earlier quoted context omitted.

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.

Webpack is just a bundler, it doesn't turn modern code into overly verbose legacy code on its own. Babel's the real troublemaker because by default it's still acting like it's the original 6to5 package. Using it to turn draft features into working ES2018 is sensible, using it to convert all the way down to ES5 for anything that isn't IE11 (which is basically the only legacy browser left at this point), not so much.

Re: What’s New in ES2019

#410

Post by tracker1 » Fri, Aug 02, 2019, 9:53 PM UTC

TheRealPomax wrote: post #409

tracker1 wrote: post #351

Earlier quoted context omitted.

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.

Webpack is just a bundler, it doesn't turn modern code into overly verbose legacy code on its own. Babel's the real troublemaker because by default it's still acting like it's the original 6to5 package. Using it to turn draft features into working ES2018 is sensible, using it to convert all the way down to ES5 for anything that isn't IE11 (which is basically the only legacy browser left at this point), not so much.

Agreed. That's why my baseline is at least async support. Every modern browser has supported it for about 2 years now, and regenerator+asynch was the single biggest part of legacy transforms. I did have a second config for legacy, but at my current job was able to drop support, and just show unsupported browsers a message page now.