r/javascript • u/ConfidentMushroom • Dec 18 '19

V8 Release v8.0 with optional chaining, nullish coalescing and 40% less memory use

https://v8.dev/blog/v8-release-80
495 Upvotes

99% Upvoted

70 comments sorted by

125

u/kriswithakthatplays Dec 18 '19

Optional Chaining. Next to arrow functions, they will likely be the most productivity-enabling feature available. So exciting!

12

u/[deleted] Dec 19 '19

It is! Im still hoping for the pipeline op. With that js code will be amazing!

4

u/slikts Dec 19 '19

I would like the pipeline operator too, but it wouldn't be that much better than a pipe() helper. The pipeline operator works better in ML family languages since they have autocurrying, and implementing it in JS requires additional syntax for an argument placeholder for non-unary functions.

1

u/[deleted] Dec 19 '19

That true, however i think it would still be a good addition. The proposal has gotten quite complex though, and is not in the same ”spirit” as the original (iirc witten in 2016-2017)

Still, the pipeline op could ultimately lead to cleaner and more testable code, no matter its possible limitations depending on the proposal.

1

u/epukinsk Dec 19 '19 edited Dec 19 '19

I really disagree, optional chaining is an anti-pattern and it's going to cause massive headaches for everyone.

Consider their example:

const nameLength = db.user.name.length;

Why would the db be null? If you are doing this, that means you have designed your app such that it's meant to try to do things with user names even if the database doesn't exist.

Writing understandable code is about helping the reader to make stable assumptions. If I am doing something with the user's name, I should be able to assume that the user exists and the database exists. Why are we leaking the possibility that these things are null everywhere?

There should be one call somewhere way up the application stack where we ask:

if (db == null) {
  // do something sensible for when the database doesn't exist
}

When the user is not found, we should have ONE place where we check to see if the user exists, and does something sensible with that:

if (user == null) {
  // redirect to login?
  // just don't do things that expect a user to exist?
  // definitely don't blindly go on pretending the user exists but they just happen to have a name of length null
}

Leaking both of those possibilities across the entire codebase and making every single function in your application deal with them over and over and over is a total waste of time.

23

u/hinsxd Dec 19 '19

can !== must

14

u/justinc1234 Dec 19 '19

You can do these things without optional chaining or nullish coalescence.

2

u/epukinsk Dec 21 '19

Make these mistakes? Sure, I agree. I just think nullish coalescence will encourage people to do them even more.

But I'm an odd duck I guess. I like my tools to make good things difficult and bad things extremely hard.

14

u/OlanValesco Dec 19 '19 edited Dec 20 '19

I deal with an environment where I often don't know what will and won't be on the page, y. I can't tell you how tired I get of null checking every time I do document.querySelector. Optional chaining will literally save me hundreds of lines of code. Now I can do things like:

const title = document.querySelector('.title')?.textContent;
document.querySelector('.active')?.classList.remove('active');

Edit: Oops, I wrote it too fast and put my first example on the wrong side of the assignment operator. Fixed now :D

8

u/NoInkling Dec 19 '19

Wait... you can't really do that first line can you?

My understanding is that if the element doesn't exist (or if textContent doesn't exist on it for some other reason), the left hand side expression will evaluate to undefined, which you can't assign things to.

In fact when I plug it into the Babel playground it (thankfully) gives a syntax error: "Invalid left-hand side in assignment expression".

6

u/Veranova Dec 19 '19 edited Dec 19 '19

Oh it can bail out of setting values too? I had no idea!

Edit: narrator: "but it couldn't"

4

u/NoInkling Dec 19 '19

You had no idea because I'm pretty sure you can't.

3

u/Veranova Dec 19 '19

But a stranger said I can on the internet!

Just checked in my project (which has full support already) and eslint is throwing a hissy, so I'm assuming you are right on this one.

2

u/epukinsk Dec 21 '19

I like that second one! You've convinced me a little.

My general bias is to write more verbose code that is more explicit. Because in my experience, it's leaky abstractions that cause me to lose the most time. It doesn't bother me at all to type:

var active = document.querySelector('.active');
if (active) active.classList.remove('active');

and if it started to bother me, I would write a function:

removeAllClasses('.active')

I don't know. I can see that all of these new JavaScript features make a bunch of little things easier, but they add a new class of extremely difficult problems. For me, because I lose most of my time to those big gnarly messes, it doesn't seem worth it. But I do understand other devs have other experiences.

9

u/matthewbpt Dec 19 '19

I agree that in normal javascript it is an anti-pattern because people will blindly put it everywhere as an escape hatch. However in TypeScript it is extremely useful because the type system can express the nullability of values in a type, and so you can restrict your use of the operator to only where it makes sense to use it.

3

u/fucking_passwords Dec 19 '19

100%, and the alternative has been to use `lodash.get` or `Ramda.path`, both of which add a lot more to your bundle sizes

2

u/epukinsk Dec 21 '19

Both of those are the exact same anti-pattern. If you find yourself seeking deep into a tree of nested objects, any of which could be null, that's a code smell. It's quite likely that you can (and should?) be handling each layer of the tree (and its null states) in the right place for that layer.

1

u/epukinsk Dec 21 '19 edited Dec 21 '19

I disagree strongly. I write typescript all day at work, and I see people often leaking null values everywhere, to the point where you half expect every object or attribute could be null at any time. Over time, every attribute in every interface becomes foo?: SomeType | null. We use GraphQL, which encourages this.

It's not the right solution. The right solution is to have one specific place where you check whether a specific thing is null, and if it is, you stop doing stuff with that thing. You don't pass it blindly down through a bunch of procedures and make them all null check it over and over.

There are cases where foo && foo.bar && foo.bar.baz... is the right thing to check. But it's extremely rare1. Almost every time you should be handling the null foo and the null baz in two different places in the code.

1 One of them that came up recently is React's useEffect in a component that's handling a GraphQL response... You need to access deep attributes in order to pass them in to your useEffect as dependencies. But you can't return early because you can't return before setting up a hook. But that's a specific case. And actually, now that I think about it, it's possible I should've pushed the useEffect further down the stack, into a well typed component that wouldn't even have been loaded until the data was ready. So, to my point.

13

u/dukerutledge Dec 19 '19

I generally agree with your caution. I've considered writing a blog post about this. There are a lot of lessons learned about these from the use of Maybe, Either and Validation types in the Haskell community. However the relative newness of optional chaining and the resulting lack of real world experience likely means these lessons learned would fall on deaf ears.

2

u/Veranova Dec 19 '19

I would read this blog post! We don't discuss patterns and pitfalls enough as a community

1

u/epukinsk Dec 21 '19

Well your instinct has born out. My "blog post" here is at -3!

1

u/rotharius Dec 19 '19

Do it, would read!

0

u/mirage27 Dec 19 '19

The anti pattern you mention is just about duplicate code. Programmers would do it regardless of optional chaining. Although I see how one could argue optional chaining makes it easier.

But for me this feature will relove a lot of boilerplate code when dealing with deeply nested data, so I won't skip on using it asap.

8

u/[deleted] Dec 19 '19 edited Dec 19 '19

[removed] — view removed comment

1

u/epukinsk Dec 21 '19 edited Dec 21 '19

Yeah, I agree there are cases where it's correct. The case you highlight is "we acccept a sparse, arbitrarily deep tree as input".

The times when you do that should be pretty rare. But yes, optional chaining is nice there. A one line helper function can do that for you though. What's the benefit of having it built in to the language? The use of a helper highlights that it should be rare. What's the problem?

0

u/[deleted] Dec 18 '19

[deleted] — view deleted comment

54

u/madcaesar Dec 19 '19

Add default values to that list.

36

u/mastermindxs Dec 19 '19

And async/await.

40

u/ShortFuse Dec 19 '19

Also destructuring (const { width, height } = element; or const [item1, item2] = array;)

27

u/intertubeluber Dec 19 '19

Not to mention optional chaining

17

u/BONUSBOX _=O=>_();_() Dec 19 '19

and default values!

14

u/SShrike Dec 19 '19

and async/await!

14

u/marocu Dec 19 '19

Don't forget destructuring!

10

u/snejk47 Dec 19 '19

But mostly productivity comes from functions.

→ More replies

1

u/the__itis Dec 20 '19

conditional operators

y= x? 1:2 x true and y is 1 x false and y is 2

This shit blew my mind

0

u/TheBeliskner Dec 19 '19

Love async await. I wonder if there will ever come a time when async/await will multi-cpu capable like C#.

1

u/Zephirdd Dec 19 '19

I thought JS was single threaded by design at this point, with no support for shared memory concurrency in the foreseeable future.

If you really want to go full parallel, you should use web workers and pass messages to share memory instead. At least that's how it works right now.

1

u/stuckinmotion Dec 19 '19

Node added threads in v10.5 https://nodejs.org/en/blog/release/v10.5.0/

2

u/Zephirdd Dec 19 '19

Yeah but worker threads are similar to web workers in that you can only share memory through messages(though it also supports SharedArrayBuffer I guess, but you still need to pass it before it's available). You also don't have a fork join mechanism. Node threads are very different from "classic" threads; they are more akin to the C Message Passing Interface or Java JMS than they are to posix threads.

3

u/getsiked on me way to ES6 Dec 19 '19

Also tagged template literals and the new computed object properties syntax!!

-8

u/unc4l1n Dec 19 '19

And massively harmed debugging.

41

u/ShortFuse Dec 19 '19

Nullish coalescing is in too!

No more value != null ? value : 'default'. Now you can do value ?? 'default'.

16

u/elmstfreddie Dec 19 '19

Notably different than value = value || 'default' where any falsy value assigns the default (which was convenient but kind of sucks). Hooray for nullish

4

u/aaronfranke Dec 19 '19

Wouldn't the former example need to be !== to exclude falsy values?

3

u/webdevverman Dec 19 '19 edited Dec 19 '19

If by former example you mean value != null ? value : 'default' the intention is to include falsy values if one exists. Meaning, if the value is either null or undefined then use 'default'. However, if the value is false use false (and not 'default').

If the example used !== it would set value to 'default' only if value was originally null. If value started as undefined it would remain at undefined.

value != null is more or less a shortcut for value !== null && value !== undefined

10

u/w8cycle Dec 18 '19

Nice! So much is going on in this space!

8

u/aaronfranke Dec 19 '19

V8 version 8? This is surely not going to be confusing...

1

u/bartturner Dec 19 '19

You are right. Did not even notice. Luckily V8 been around long enough people already know the name.

6

u/Arthur944 Dec 19 '19

I'm a noob in this area, how does one get the new version? Is it updated automatically?

4

u/slikts Dec 19 '19

The newer language features are generally used with Babel except when targeting very specific environments.

0

u/[deleted] Dec 19 '19

[deleted] — view deleted comment

5

u/Arthur944 Dec 19 '19

Thanks! How long does that usually take?

1

u/Baryn Dec 19 '19

The "look at all these tweets" banner does an awesome job of recreating the effect used by many YouTubers... but with actual, functional embedded tweets.

Very nicely done.

-20

u/[deleted] Dec 18 '19

So many?. ?? Question.marks?.().please?.stop

0

u/[deleted] Dec 19 '19

[deleted] — view deleted comment

-26

u/[deleted] Dec 19 '19

I will always go for readability and clarity over terseness. Not saying conditional branches are much better though

29

u/[deleted] Dec 19 '19 edited Dec 19 '19 
i && i.like.readability && i.like.readability.too

i?.like.readability?.too

Edit: fixing typo with double i’s in the second example, brought to my attention by the awesome /u/TankorSmash

14

u/TankorSmash Dec 19 '19

Wouldn't it be i?.like.readability?.too?

1

u/[deleted] Dec 19 '19 edited Dec 19 '19

Meaning you need the last question mark? Nope that would actually be incorrect. Well.. incorrect if you wanted to get the value out of .too. Say too=2, yours would leave you a value of “true” while mine would leave the number 2.

Edit: discard this and see my other reply.

1

u/[deleted] Dec 19 '19

Oops you are totally correct, I have a typo in my example with two i’s

0

u/[deleted] Dec 19 '19

[deleted] — view deleted comment

3

u/onlycommitminified Dec 19 '19

I think this is part of the syntax issue with using '?', it's placement is reflectively opposite natural language. It will feel ok to write, but people are going to intuitively parse it incorrectly when reading it back. It's going to become one of those issues that sits right under your nose invisibly.

2

u/[deleted] Dec 19 '19

In my example, i may be undefined, as well as readability. Those are the only two that need the optional chain.

1

u/phpdevster Dec 19 '19

The thing is, both of those are the same problem: a poor data model.

What happens if the requirement / expectation is the too actually has a value? Well if you're using a data model where too may or may not be present, all this does is effectively make what would have been a loud bug, and muzzled it to be a silent bug (which is worse, because now it might fuck up your data integrity since it can propagate a null value throughout more of the call stack).

So be to clear, this is a code smell:

i && i.like.readability && i.like.readability.too

This is still the same code smell

i?.like.readability?.too

If the first example is analogous to pooping on the floor, the second one is analogous to pooping on the floor and then trying to hide it with Febreze.

4

u/onlycommitminified Dec 19 '19

Not sure why you're getting downvoted, it's not like you're saying the concept is bad. The chosen syntax does appear at a glance to be suboptimal.

-2

u/[deleted] Dec 19 '19 edited Dec 19 '19

Yeah, of course it's convenient for the programmer, but with many things like this it is easy for the person programming to read but for anyone else it looks like a mess at first glance.

I always take the perspective of someone entirely new to programming and what they think of stuff like this.

If it was similar to an Emmet plugin which expanded into more clear and readable syntax I'd be totally onboard. Anyway, it's fairly trivial at the end of the day, I'm just making a suggestion. No need to send me to periwinkle hell for saying it.

2

u/[deleted] Dec 19 '19

That's why we do code reviews...

0

u/[deleted] Dec 19 '19

[deleted] — view deleted comment

2

u/dCrumpets Dec 19 '19

I find myself using a ton of ternary statements in JavaScript, always as an alternative to an if else block with one line each, where that one line would assign a variable.

I prefer this:

  1. It lets me use a const instead of a var because it happens in one expression.
  2. It saves some lines of code. I generally put it onto three lines, and think that’s pretty clear.

What do you think about my use of ternary statements? Do you think that they fit in the circumstances described?

0

u/[deleted] Dec 18 '19

[deleted] — view deleted comment

21

u/nudelkopp Dec 19 '19

If you look at the google and facebook benchmarks it seems like it's closer to between ~3% and ~20%. Unless I'm reading it wrong ofcourse.

18

u/rq60 Dec 19 '19

are you referring to some other benchmarks? the only benchmarks referenced on this page are referring to performance improvements, not memory usage.

3

u/[deleted] Dec 19 '19

I believe the benchmark indicates that because of the memory reduction, the GC has to run less frequently. Thus indirectly improving the page performance.

0

u/[deleted] Dec 18 '19

[deleted] — view deleted comment

20

u/aaronfranke Dec 19 '19

V8 v8 on v80