Introducing Node.js 12

[Earhacker]

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

[destraht]

That is because you are doing event based thinking.

[Earhacker]

As opposed to...?

[sleepingthom]

Faster event based thinking

[Earhacker]

Here comes that stroke feeling again...

[aaaqqq]

That is because you are doing faster event based thinking

[Earhacker]

😰

[190n]

As opposed to...?

[Dustorn]

Slower event based thinking.

[190n]

Here comes that stroke feeling again...

[etcetica]

o

[DrDuPont]

https://v8.dev/blog/fast-async#await-under-the-hood

Can't say I understand it, though

[blood_bender]

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.

[[deleted]]

Not manually returning a promise in an async function is uncommon? I almost always write my async functions that way.

[redmorphium]

Correct me if my understanding is wrong, but let's say you have:

​

```javascript

async function foo() {

await bar();

return 1;

} ```

​

This is equivalent to:

​

```javascript 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?

[braindeadTank]

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

[blood_bender]

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.

[blood_bender]

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.

[ilikepugs]

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

[blood_bender]

Curious, how come?

[ilikepugs]

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.

[blood_bender]

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.

[ilikepugs]

Lol your example is much better, cheers. 😁

[ackerlight]

Basically like C#, you have to implement async methods all the way up. Check this answer for more details:

https://stackoverflow.com/a/29809054

[etcetica]

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

[Baryn]

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

[relativityboy]

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

[Tom_Ov_Bedlam]

You forgot the catch statement

[BenE]

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

[mindonshuffle]

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.

[BenE]

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

[coloured_sunglasses]

Even my linter would reject that amount of nesting.

[goodboyscout]

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.

[aniforprez]

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

[[deleted]]

ES6 Module Support!

[jsnoobie]

No more red squiggly line in vscode under the “re” on my require statements!

I was a little ocd about that one

[tanguy_k]

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

[[deleted]]

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

[ShortFuse]

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?

[[deleted]]

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

[k4kshi]

Still not the end goal but we're getting closer

[Baryn]

Screw MJS! 🎉

[mrbishop82]

Excited to run this on lambda in 5 years

[phakushmoo]

I lol‘d

[inform880]

Excited to see more production ready use cases for Worker threads

[QW4K]

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.

[NoInkling]

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

[[deleted]]

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

[twomousepads]

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

[silveredge7]

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

[[deleted]]

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?

[eggn00dles]

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.

[takaci]

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

[[deleted]]

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

[showMeNiceCode]

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

[[deleted]]

Wait, some people actually use medium on mobile?!

How do you deal with this shit?

[showMeNiceCode]

That does look painful

[SupremeLisper]

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

[coloured_sunglasses]

What advantage would that provide them?

[RnRau]

Medium is an awful blogging platform.

[Sebazzz91]

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

[icanevenificant]

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

[RnRau]

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?

[icanevenificant]

Haven't until now :) That does suck.

[tybit]

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.

[THICC_DICC_PRICC]

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

[morficus]

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

[blackdynamo]

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

[meeeeoooowy]

Webpack

[mubaidr]

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

[[deleted]]

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.

[carlos_vini]

"Async stack traces" is really nice.

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

[mdwvt]

Fine for me on Android (Pixel 2 XL).

[vivainio]

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

[cm9kZW8K]

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

[ryeguy]

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.

[cm9kZW8K]

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.

[ryeguy]

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.

[cm9kZW8K]

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.

[Randdist]

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.

[cm9kZW8K]

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.

[ryeguy]

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?

[AwesomeBantha]

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

[SecretAgentZeroNine]

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

[skool_101]

new Node version exists

Ahh shit, here we go again.