What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#271

Post by hombre_fatal » Tue, Jul 30, 2019, 5:13 PM UTC

la12 wrote: post #242

shiv86 wrote: post #237

Earlier quoted context omitted.

>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…

> The current scene is that most people don't know what the real difference between arrow and function notations

That's hard to believe unless you're working on the most amateur of teams.

There's a point where you have to expect people to understand the most basic concepts of the language/tools they're hired to use. This shouldn't require more than a simple 5min pull-aside of the junior developer.

Also, you can't change function(){}'s dynamic scope without breaking the web, which is a major downside for your suggested upside of developers not having to learn the distinction. function(){} was always confusing from day one. ()=>{} is a move back toward intuitiveness.

Re: What’s New in ES2019

#272

Post by dsego » Tue, Jul 30, 2019, 5:15 PM UTC

hombre_fatal wrote: post #248

dsego wrote: post #129

Earlier quoted context omitted.

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.

How do you cancel promises?

Re: What’s New in ES2019

#273

Post by Xavdidtheshadow » Tue, Jul 30, 2019, 5:15 PM UTC

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…

I really love the Ruby naming conventions around this: `!` indicates mutation.

  2.4.1 :001 > a = [4,3,5,1,2]
   => [4, 3, 5, 1, 2]
  2.4.1 :002 > a.sort
   => [1, 2, 3, 4, 5]
  2.4.1 :003 > a
   => [4, 3, 5, 1, 2]
  2.4.1 :004 > a.sort!
   => [1, 2, 3, 4, 5]
  2.4.1 :005 > a
   => [1, 2, 3, 4, 5]

Re: What’s New in ES2019

#274

Post by z3t4 » Tue, Jul 30, 2019, 5:16 PM UTC

mmartinson wrote: post #243

padolsey wrote: post #113

Earlier quoted context omitted.

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 progr…

JavaScript was very simple compared to most languages. Adding a bunch of extra syntax variants, different types of scoping rules, magic syntax has made the language overly complex. Thankfully you can still use the "good parts".

Re: What’s New in ES2019

#275

Post by Aperocky » Tue, Jul 30, 2019, 5:16 PM UTC

mmartinson wrote: post #254

Aperocky wrote: post #214

Earlier quoted context omitted.

As a purely backend engineer with a passionate hatred for NPM, I love writing ES6 and native javascript. All of the newer features (tbh, I don't know which are new but I guess 'const', 'arrow functions', 'default parameters', 'string interpolations', 'filter/map' are definitely a few of them and made javascript more like the back end language that I work with). I wrote at least a thousand line of native javascript fo…

What's your take on Node and backwards compatibility? Since you get to choose your runtime, is it valuable to stick with the same always-add, never remove approach as the browser? NPM taken out of the picture, I get writing one language everywhere would be nice. Do you just consider the bad parts to be the price to pay for not needing to keep track of the distinctions? I've recently been working in Electron, and I fi…

I feel like you're mentioning forward compatibility instead of backward compatibility. ES5 code should run fine in ES6 AFAIK, and that's the extend of backward compatibility that should ever be needed. I haven't touched node all that much, and I'm in the camp that while it's good to just write one language everywhere, javascript still exhibits many of the key features of a browser language, which makes running it locally 'unnatural'. Same with trying to get python to run in a browser, maybe we should just embrace that we need to learn more languages as that is generally the case for us software engineers.

Re: What’s New in ES2019

#276

Post by simias » Tue, Jul 30, 2019, 5:17 PM UTC

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.

>I sometimes wonder what's the point of new versions of C, too.

At this point I'm mostly fine with the feature set of C99 so I can live without the newer standards. Actually there's stuff in newer standards that I find questionable, but that's a different discussion.

C99 on the other hand was sorely needed, if only for standardizing some basic features that up until then were only available as vendor-specific extensions. Things like inline, stdint.h, bools, variadic macros, restrict, compound literals and more[1].

Writing code without these features is often severely limiting. Or rather, you probably won't be limited but you'll have to rely on vendor extensions and write non-portable code. Or maybe you'll use a thousand-line long configure script to make the code portable.

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

If you're making proprietary software that makes sense, if you're developing open source code you very much care about portability and compatibility. I care about the compiler I use, the compiler OpenSuse uses, whatever garbage Visual Studio uses, the compiler FreeBSD uses etc...

Besides I have basic code snippets I wrote over a decade ago that I still use today, regardless of the environment. That's valuable too.

[1] https://en.wikipedia.org/wiki/C99

Re: What’s New in ES2019

#277

Post by EGreg » Tue, Jul 30, 2019, 5:19 PM UTC

pcr910303 wrote: post #29

EGreg wrote: post #24

Earlier quoted context omitted.

What’s wrong with var a = ...; a = a.project(); a = debug(a); a = a.eject();

That can’t show the programmer’s intent whether it is mutation (e.g. a = a + someNum) verses defining a new variable with different types (but has a similar meaning so has a same name) (e.g. someKindOfData = [...someKindOfData]) Rust allows this, and it really clears codes up. I don’t have to make up different identifiers for same data but different representations. (e.g. I would do the above code in JS as... someKin…

What are you talking about, LOL

Re: What’s New in ES2019

#278

Post by sev » Tue, Jul 30, 2019, 5:20 PM UTC

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

Re: What’s New in ES2019

#279

Post by brlewis » Tue, Jul 30, 2019, 5:21 PM UTC

LukeBMM wrote: post #208

pault wrote: post #158

Earlier quoted context omitted.

> 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…

There are tools like create-react-app that configure complicated build pipelines for you, and there's parcel, a simple common-case build pipeline.

Re: What’s New in ES2019

#280

Post by mantap » Tue, Jul 30, 2019, 5:22 PM UTC

DonHopkins wrote: post #253

mantap wrote: post #247

Earlier quoted context omitted.

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.

And in the idealized fantasy world of Ayn Rand, any giant dinosaur enterprise corporation who insists on using antique outdated Jurrasic browsers deserves to be bitch-slapped by the invisible hand of the market into extinction for their outrageously dangerous security and privacy policies. To bad the real world doesn't work the same as it does in self-indulgent libertarian porn...

The real world works exactly like that. It's called System Requirements. If you want to use a piece of software, you look at the requirements and if you don't meet the requirements then you can't install it.

All websites have system requirements, no matter how non-libertarian they seek to be, for example most websites will not work on IE6.

It is not a fantasy to inform users that they don't meet the requirements, it is actually the courteous thing to do. If more websites were bold enough to inform users of their outdatedness then we would not be having this conversation.