Introducing Node.js 12

98

u/Earhacker Apr 23 '19

I paused for a moment to consider how "Faster await" would work and I think I had a stroke.

51

u/destraht Apr 23 '19

That is because you are doing event based thinking.

19

u/Earhacker Apr 23 '19

As opposed to...?

116

u/sleepingthom Apr 23 '19

Faster event based thinking

29

u/Earhacker Apr 23 '19

Here comes that stroke feeling again...

19

u/aaaqqq Apr 23 '19

That is because you are doing faster event based thinking

11

u/Earhacker Apr 23 '19

😰

4

u/190n Apr 24 '19

As opposed to...?

5

u/Dustorn Apr 24 '19

Slower event based thinking.

2

u/190n Apr 24 '19

Here comes that stroke feeling again...

1

u/etcetica Apr 24 '19

o
15
u/DrDuPont Apr 23 '19

https://v8.dev/blog/fast-async#await-under-the-hood
Can't say I understand it, though
31
u/blood_bender Apr 23 '19

Basically async marks a function as required to return a Promise. So the earlier approach to the v8 implementation would take whatever value was returned from the function, wrap it in a promise, and return that instead.
Now it looks to see if what's being returned is a native Promise, and if it is, just returns that instead of wrapping it (it still needs to wrap a value if you're not returning a promise, but that's pretty uncommon).
Seems like a naive approach the first time around, it's a little unclear to me why they didn't do that up front, but oh well.
3
u/[deleted] Apr 24 '19

Not manually returning a promise in an async function is uncommon? I almost always write my async functions that way.
3
u/redmorphium Apr 24 '19
Correct me if my understanding is wrong, but let's say you have:
async function foo() {

  await bar();

  return 1;

}
This is equivalent to:
async function foo() {

  return bar().then(() => 1);

}
So unless if you're writing async functions that don't have any awaits in them, then async functions should always effectively return promises?
4

u/braindeadTank Apr 24 '19

Async function always return a promise, no ifs, buts or unlesses. If you don't await anything, it will just be resolved right away.

3

u/blood_bender Apr 24 '19

You're right. But the whole point was v8 was wrapping the response of foo() in a promise too, which is unnecessary when bar() most likely returns a promise directly, or whatever bar() calls does. Somewhere down the line something is probably returning a promise, meaning all the other responses wrapped in additional promises is unnecessary.
2
u/blood_bender Apr 24 '19
So, the one case where it doesn't is if you have a function marked async that doesn't have an await in it.
async function foo() {
  return 4;
}
That's just returning a value, so v8 would still need to wrap that in a promise.
But when you have an await, what are you awaiting? Either the function you're awaiting is directly returning a promise, or somewhere down the line some function is directly returning a promise, meaning as it walks back up the line of async functions all the times it wrapped it in another promise were unnecessary.
1

u/ilikepugs Apr 24 '19

And if you write a lot of interface-based code it's not uncommon.

1

u/blood_bender Apr 24 '19

Curious, how come?

4

u/ilikepugs Apr 24 '19

Let's say you design an interface for some data fetching util, but you ship different implementations to different clients/platforms, and the appropriate implementation is DI'd at runtime.
Well consider the method that actually performs the request. It'll be async. But in some cases (namely tests in this example) you might want to return some stubbed data for your test instead. So in your test implementation of the util that "async" method just returns your dummy JSON and you don't need to wrap it in a promise.
This is a fairly contrived example but yeah.

2

u/blood_bender Apr 24 '19

Oh that's fair. There have been times where I have an async function return a cached response instead of fetching a new one, so that's another use case that I've written. But really I'd guess 99% of async functions are actually awaiting or returning a Promise directly.

1

u/ilikepugs Apr 24 '19

Lol your example is much better, cheers. 😁
1

u/ackerlight Apr 24 '19

Basically like C#, you have to implement async methods all the way up. Check this answer for more details:
https://stackoverflow.com/a/29809054

0

u/etcetica Apr 24 '19

god I miss when javascript work wasn't built atop bastardizing plain fucking english

2

u/Baryn Apr 24 '19

If anything, it makes better use of keywords now, except in instances like the crappy private field syntax.
1

u/relativityboy Apr 24 '19

Was that a way of checking to see if it's fast enough?

1

u/Tom_Ov_Bedlam Apr 24 '19

You forgot the catch statement

-40

u/BenE Apr 23 '19

Yeah stick to callbacks people. This complex promise stuff is really unnecessary.

29

u/mindonshuffle Apr 23 '19

I very, very genuinely have no idea if this is sarcasm. There's so many purity tests and master races in webdev that I can't keep track anymore.

-22

u/BenE Apr 23 '19

No sarcasm. https://medium.com/@b.essiambre/continuation-passing-style-patterns-for-javascript-5528449d3070

17

u/coloured_sunglasses Apr 24 '19

Even my linter would reject that amount of nesting.

17

u/goodboyscout Apr 24 '19

I was recently burned when a promise library I was not even using, that came embedded in a dependency, was silently swallowing all uncaught exceptions in a service I built.
You gonna quick cooking because you messed up a recipe? Maybe write a test and this won’t happen. Unless you don’t believe in testing code either. I wrote a test once that showed a flaw in my logic so I stopped writing tests.

11

u/aniforprez Apr 24 '19

I can't believe how code can be that unreadable in so few lines of code

91

u/[deleted] Apr 23 '19

ES6 Module Support!

47

u/jsnoobie Apr 23 '19

No more red squiggly line in vscode under the “re” on my require statements!
I was a little ocd about that one

23

u/tanguy_k Apr 23 '19 edited Apr 23 '19

It's still behind a flag (--experimental-modules) + you need to add "type": "module" inside your package.json.
See https://medium.com/@nodejs/announcing-a-new-experimental-modules-1be8d2d6c2ff

17

u/[deleted] Apr 23 '19

Yes, but they expect to remove the need for the flag during the development of this version (before it goes LTS in October).

8

u/ShortFuse Apr 24 '19

Do I still need to use Michael Jackson Script file extension?
I've been using the esm package, but I would like to be able to remove the dependency?

3

u/[deleted] Apr 24 '19

You don't. If you add "type": "module" to your package.json, plain .js will work too.

7

u/k4kshi Apr 23 '19

Still not the end goal but we're getting closer

3

u/Baryn Apr 24 '19

Screw MJS! 🎉

33

u/mrbishop82 Apr 24 '19

Excited to run this on lambda in 5 years

6

u/phakushmoo Apr 24 '19

I lol‘d

22

u/inform880 Apr 23 '19

Excited to see more production ready use cases for Worker threads

21

u/QW4K Apr 23 '19

Can't wait to try async stack traces. It's so weird that we didn't have them for that long in async language like JS.

Last time I tried it (on experimental build) it didn't really work for me and in the end, I used bluebird debug mode I hope it's fixed by now.

15

u/NoInkling Apr 24 '19

List of some of the new ES features/APIs now available thanks to V8 7.4 (compared to 7.0 in Node 11):

Class fields (both public and private)
Object.fromEntries
String.prototype.matchAll
Some new Intl APIs

18

u/[deleted] Apr 24 '19

I'm still annoyed at how fugly the syntax for private class fields look

84

u/twomousepads Apr 23 '19

The Node.js foundation can't afford to put their blog anywhere other than Medium?

24

u/silveredge7 Apr 23 '19

Don't know why you were downvoted, what your'e saying is true.

-19

u/[deleted] Apr 23 '19

No it isn't. The Medium website is shite on mobile, it's true... but to say that they use it because they 'can't afford' any other option? Patently untrue. Do you see how these things are different?

10

u/eggn00dles Apr 23 '19

there is absolutely zero reason for node to have their company announcements on a third party site. if medium goes down, so does the node blog? there's a better option, it costs more, and node isn't willing to spend that. as an end-user whether they can 'afford' it or not is semantics.

7

u/takaci Apr 23 '19

Also medium is pushing the paid content really aggressively recently. It's not a nice user experience

5

u/[deleted] Apr 23 '19

Also why can’t they use their own product to make it. Seems like a good opportunity

3

u/showMeNiceCode Apr 23 '19

What mobile do you use? It works just fine for me.

9

u/[deleted] Apr 24 '19

Wait, some people actually use medium on mobile?!
How do you deal with this shit?

5

u/showMeNiceCode Apr 24 '19

That does look painful

1

u/SupremeLisper Apr 24 '19

Well, I never had it that worse. Without ublock-origin it's painful browsing the web on mobile let alone desktop.

4

u/coloured_sunglasses Apr 24 '19

What advantage would that provide them?

9

u/RnRau Apr 24 '19

Medium is an awful blogging platform.

4

u/Sebazzz91 Apr 24 '19

That answers the question what advantage it would provide to us, the users.

1

u/icanevenificant Apr 24 '19 edited Apr 24 '19

Why is it awful? Haven't seen that sentiment before so I'm genuinely curious.

3

u/RnRau Apr 24 '19

Have you tried navigating comments and responses? Tried copying some information from the comments without causing a page refresh and navigating away from the article?

2

u/icanevenificant Apr 24 '19

Haven't until now :) That does suck.

1

u/tybit Apr 28 '19

It would mean their readers aren’t bugged to pay medium money.
I have no interest in paying money to medium because a lot of the blog posts I’ve read have unfortunately been hosted on medium and they now feel I owe them something.

1

u/THICC_DICC_PRICC Apr 24 '19

Eh Jeff Bezos talked about his dick pic drama there I guess money isn’t really the issue there.

12

u/morficus Apr 24 '19

Now if only AWS Lambda could offer a newer version of Node.js, that would be great

6

u/blackdynamo Apr 24 '19

Can't you create your own layer and runtime now?

1

u/meeeeoooowy Apr 24 '19

Webpack

2

u/mubaidr Apr 23 '19

So what's the difference in use cases between workers and child processes or forks?

2

u/[deleted] Apr 24 '19

So glad they listened and made the .mjs extension optional instead of mandatory for ES module support! Just adding "type": "module" to your package.json is enough now to opt in.

3

u/carlos_vini Apr 23 '19 edited Apr 23 '19

"Async stack traces" is really nice.

~~https://v8.dev/blog/v8-release-73~~ ~~is broken (ERR_CERT_COMMON_NAME_INVALID) to me.~~

1

u/mdwvt Apr 23 '19

Fine for me on Android (Pixel 2 XL).

-13

u/vivainio Apr 23 '19

While Node.js already performs well with the single-threaded event loop, there are some use-cases where additional threads can be leveraged for better results.

...and to think other runtimes have wasted decades supporting multiple threads

11

u/cm9kZW8K Apr 23 '19

...and to think other runtimes have wasted decades supporting multiple threads
The lack of threading is one of the great features of JS, and a big part of why it won out over other languages.

14

u/ryeguy Apr 23 '19 edited Apr 23 '19

and a big part of why it won out over other languages.
I don't think this is true. When people say that JS's concurrency model is superior to threads, they mean that having everything be async by default is superior to having to use threads to do that.

4

u/cm9kZW8K Apr 23 '19

Having the whole ecosystem being non-blocking is just superior - it means there are no landmines hiding away. When using C++ to do async code, especially when you have a selection of 3rds party code, you are often timebombed by some path that ends up calling a blocking syscall. JS is largely free of that.
Threads also dont have very many valid use-cases. Especially when you can just as easily fork a separate process on a modern linux, there just arent many times where a thread is the right choice to do something. Other than making up for the weaknesses of local hard-drive IO, async style programming has largely displaced threaded programming because its significantly more efficient and less buggy.
it turns out that there are nearly no modern uses for threading that arent better solved with other techniques.

8

u/ryeguy Apr 23 '19

But lack of threads has nothing to do with async. Node could still have async-everything and threads. That's the point I was trying to make - it's not the lack of threads that's nice, it's the nonblocking nature of everything.
Threads are still very relevant when it comes to working on cpu bound tasks in a way that needs access to shared data. Again, this isn't related to async or not. I'm not saying Java-style thread-based concurrency is better than node's. I'm saying there's a world were we could have both, and it would give us more flexibility.

1

u/cm9kZW8K Apr 24 '19

Threads are still very relevant when it comes to working on cpu bound tasks in a way that needs access to shared data.
Right; if you need access to a large heap, cannot factor the data structure into shards, cannot defer to the OS via disk/disk cache, cannot isolate the access from the processing, and have minimal need for write mutexing, and for some strange reason cannot mount the data as SHM ; then maybe there is a case where direct access to heap RAM to perform cpu bound operations is the best option.
IME its very rare and the vast majority of times isolation of the critical sections which actually needed the heap and surface them over an api, or else splitting the problem into equal sized tasks over separate processes are better options.
Node could still have async-everything and threads.
I think the two are tied hand in hand; having access to thousand of libraries and vendor code where you automatically know there will be no threading and no blocking is exactly why you can count on async everything.
If threading was an option, over time people would elect to use it (for the wrong reasons) and it would start to proliferate through the ecosystem.
For what JS is, its better, systemically, that threads are not part of the language, imo.
Do you have an example problem in mind where it is the best solution?
Most problems in the space eclipse the space available in RAM anyway, so you end up back with multiple process. Its just a real strange corner case to need them, that I just havent found it. Even before working in JS, i had a flat no threading criteria for the team unless they could justify why it was the best case. and over 10 year, the only cases where workarounds for OS calls which blocked.

1

u/Randdist Apr 24 '19

Threads are absolutely needed when you need to load and then parse large binary files. Loading can be done in parallel using the native calls but the parsing would block the main thread for a long time, or severely reduce responsiveness even if you split the parsing in multiple smaller batches.
Threads are vital for certain sets of responsive applications.

1

u/cm9kZW8K Apr 24 '19

Threads are absolutely needed when you need to load and then parse large binary files.
Other that avoiding the kernel flaw around O_NONBLOCK on local drives, there is no need to thread read syscalls. Node conveniently has built in threads for those, so reading in the bytes works async out of the box.
split the parsing in multiple smaller batches.
If the parser yields often enough, it doesnt have to impact responsiveness at a. For example: replacing tight loops with Promise.each ensure granularity. if your file parse involves heavy CPU transformation of data beyond just reading into RAM, then you can pipeline that in via a separate process.
Threads are vital for certain sets of responsive applications.
Threads were vital to work around flawed OS's which cannot fork() well. If you are finding them vital today, I think there is a problem with the structure of your code.
I regularly deal with this issue, both with fork()s for heavy cpu transforms and async code for simple heap building, and I would consider a threaded approach to be a bug.

0

u/[deleted] Apr 24 '19

[deleted]

1

u/ryeguy Apr 24 '19 edited Apr 24 '19

Yes, I'm aware. What's your point? Are you going to argue that js is popular because it doesn't have or need synchronization primitives? That doesn't hold, how do you explain Go's success?

-1

u/AwesomeBantha Apr 24 '19

Actually massive PogChamp, this will make a project I'm working on with a backend and a frontend in the same repo much cleaner...

-1

u/SecretAgentZeroNine Apr 24 '19

Now I just need a book that covers Node. J's 12 :-/

-10

u/skool_101 Apr 24 '19

new Node version exists

Ahh shit, here we go again.

You are about to leave Redlib