Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node v8.1.2

nodejs.org

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Node v8.1.2

#41

Post by pier25 »

maxxxxx wrote: post #29
mstade wrote: post #21

Earlier quoted context omitted.

I understand the reasons why async/await is designed the way it is, but I still think it is backwards. Really if you wanted to truly make async programming approachable, you should make it transparent. What I mean by this is that instead of marking a function as async, and awaiting values, you'd mark lines as async, opting out of implicit awaits. I wrote up some thoughts on this here: https://github.com/utilise/emitt…

Agreed. Async is like a virus. Once you start somewhere pretty much everything else must be async too. In C# you can call async code from not async code and then call Task.Wait. Not sure if JS can do that. But it still beats promises or callback hell.....

> But it still beats promises or callback hell.....

And then() hell ...

Re: Node v8.1.2

#42

Post by WorldMaker »

maxxxxx wrote: post #39
WorldMaker wrote: post #35

Earlier quoted context omitted.

A better term than virus is that async is a monad. Welcome to programming with monads. ;) JS async produces Promises like C# produces Task, so you can call an async function and use the result as a Promise.

Can you wait for a promise synchronously? I am pretty new to JS so please forgive if this is a stupid question.

It's not something JS engines allow today. It's also not something that entirely makes sense from the perspective of a browser threading model or even the libuv-based NodeJS threading model.

Re: Node v8.1.2

#43

Post by ronjouch »

Osiris wrote: post #38
ronjouch wrote: post #16

Earlier quoted context omitted.

But in addition to that, how do you "update all and bump relevant package.json entries, dependencies _and_ devDependencies as appropriate " ? `npm update --save` or `npm update --save-dev` say explicitly "save updates to `dependencies` resp. `devDependencies`" , which causes duplication between dependencies and devDependencies. (Say you have a dep foo and a devDep bar and both are outdated: `npm update --save` will b…

I use npm-check-updates[1] which will update the package.json file with the latest versions of each dependency. [1] https://www.npmjs.com/package/npm-check-updates

Yeah that's the package I meant with "3rd-party packages providing such functionality", thanks for pointing it out :) ! Was wondering if there was a reason other than "because no one developed it" for such a feature not being in npm core.

Re: Node v8.1.2

#44

Post by maxxxxx »

WorldMaker wrote: post #42
maxxxxx wrote: post #39

Earlier quoted context omitted.

Can you wait for a promise synchronously? I am pretty new to JS so please forgive if this is a stupid question.

It's not something JS engines allow today. It's also not something that entirely makes sense from the perspective of a browser threading model or even the libuv-based NodeJS threading model.

I know. We have some wacky use cases where it would make sense. The real answer would probably be to say "Don't use Node for this" but that's a different discussion above my pay grade.

Re: Node v8.1.2

#45

Post by WorldMaker »

maxxxxx wrote: post #44
WorldMaker wrote: post #42

Earlier quoted context omitted.

It's not something JS engines allow today. It's also not something that entirely makes sense from the perspective of a browser threading model or even the libuv-based NodeJS threading model.

I know. We have some wacky use cases where it would make sense. The real answer would probably be to say "Don't use Node for this" but that's a different discussion above my pay grade.

The real answer is probably "those places you think need to synchronous don't need to be synchronous" and you need a refactor or a rearchitecture.

Re: Node v8.1.2

#46

Post by maxxxxx »

WorldMaker wrote: post #45
maxxxxx wrote: post #44

Earlier quoted context omitted.

I know. We have some wacky use cases where it would make sense. The real answer would probably be to say "Don't use Node for this" but that's a different discussion above my pay grade.

The real answer is probably "those places you think need to synchronous don't need to be synchronous" and you need a refactor or a rearchitecture.

Trust me. We are not totally stupid. We need synchronous actions under some circumstances.

Re: Node v8.1.2

#47

Post by aussieguy1234 »

Maarten88 wrote: post #9

I upgraded a universal React/typescript project from node 6.10 to 8.1 this week. Configured typescript compilation in webpack to target es2017 server-side and es5 client-side. It worked flawlessly. Debugging async functions (server-side) is a lot better now that there is no transpiler mangling my code beyond recognition.

I had the same results with 8.0.

Re: Node v8.1.2

#48

Post by davidgf »

pier25 wrote: post #40
davidgf wrote: post #13

Earlier quoted context omitted.

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

There is no difference, async/await is just another promise notation.

Although async/await is simply syntax sugar around promises, there's a huge difference indeed. With async/await your code keeps an imperative style, while with promises code end up with a functional look

Re: Node v8.1.2

#49

Post by davidgf »

cloverich wrote: post #34
davidgf wrote: post #13

Earlier quoted context omitted.

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

Sounds interesting -- do you have any resources handy that cover what you allude to (spec. comparing async calls to promises, and favoring the latter?) I use both in my ui code and they seem to have their niche for me. I prefer promise based calls when I want to separate out fetching data from the state-mutating callback, or when I may want to "cancel" something (ex: fetch a list of items for a list component, then u…

Unfortunately not, my opinion is simply based on my personal experience and on what I've been learning along the way. I find promises really handy for data processing pipelines (grab some data and perform some transformations over it to get it in the form you need), regardless of wether any of the steps is async or not. I still find async/await really useful and mix it with promises if I need it, but I prefer to keep my code as functional as I can. Besides, I don't really like how JavaScript handles exceptions and would rather staying away from try/catch if possible
Post reply on HN