Live data from Hacker News

Node v8.1.2

nodejs.org

21–30 of 49 posts

Re: Node v8.1.2

#21
post #4
post #2

Node 8 is the planned LTS release for later this year. Notably, it brings async/await syntax to vanilla JS. This new feature complements callbacks and largely replaces how Promises are currently consumed (opting for sequential-like execution with try/catch blocks instead of Promise chains). The closest analogue would be Tasks in C#. EDIT: removing reference to node-v8 to prevent confusion.

Aync/await is the best thing since sliced bread. It has made my life so much easier.

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/emitterify/issues/1#issuecomment-...

The way it is now, I defensively await things all over the place. What's worse, it propagates. If any of your function's dependencies are async, your function will also have to be async (or be ok with continuing operation after it's returned) and it turtles all the way down.

It is nicer than having to deal with promises directly though, there is that.

Re: Node v8.1.2

#22

Now's as good a time as any to ask: What tools do you folks use to monitor your node dependencies and make sure you are keeping everything up to date?

https://www.npmjs.com/package/npm-check-updates is a small command line utility that will report which dependencies are out of date, and can also upgrade your package.json from the CLI while maintaining your existing semantic versioning policies and ranges across an upgrade (instead of just bumping for every minor update).

Mostly I just really like the compact output, and the short "ncu" command which I run every day to check what's available :)

Re: Node v8.1.2

#23

Earlier quoted context omitted.

Promises are and always were retarded. They did nothing to alleviate callback hell which was most of the point of their existence. I have no idea why they implemented them instead of async/await in the first place. Now we have to deal with mixing both for years. Another fine example of JavaScript trying to be hip and ignoring the lessons learned from countless other languages over the years. I see this constantly wit…

You do realize that implementing promises is a prerequisite for async/await, right?

Is it really a requirement? I would think callbacks and a preprocessor are sufficient.

Re: Node v8.1.2

#24

Now's as good a time as any to ask: What tools do you folks use to monitor your node dependencies and make sure you are keeping everything up to date?

Definitely something to the addage "if it ain't broke don't fix it". Some of our less critical modules are set to latest others are updated with care. Our modules are not under source control so are refreshed on deployment. We use Snyk to monitor for vulnerabilities, works pretty well.

Re: Node v8.1.2

#25
post #2

Node 8 is the planned LTS release for later this year. Notably, it brings async/await syntax to vanilla JS. This new feature complements callbacks and largely replaces how Promises are currently consumed (opting for sequential-like execution with try/catch blocks instead of Promise chains). The closest analogue would be Tasks in C#. EDIT: removing reference to node-v8 to prevent confusion.

Promises are and always were retarded. They did nothing to alleviate callback hell which was most of the point of their existence. I have no idea why they implemented them instead of async/await in the first place. Now we have to deal with mixing both for years. Another fine example of JavaScript trying to be hip and ignoring the lessons learned from countless other languages over the years. I see this constantly wit…

How would you propose that async/await work without Promises? Even C#'s async/await uses the same concept: https://msdn.microsoft.com/en-us/library/system.threading.ta...

Pending the implementation of new language syntax, raw Promises were a practical solution for what they set out to accomplish. If you don't think they improved callback hell at all, I expect that you probably weren't using them correctly (an easy mistake to make without looking at the documentation and/or reading the wrong tutorials / blog posts).

cf.

    getAsyncValue1(a =>
        getAsyncValue2(a, b =>
            getAsyncValue3(b, c =>
                doSomething(c)
            )
        )
    );
and

    getAsyncValue1().then(a =>
        getAsyncValue2(a)
    ).then(b =>
        getAsyncValue3(b)
    ).then(c =>
        doSomething(c)
    );
Sure, async/await flattens that to zero nested callbacks, which is great, but with that off the table I'd rather deal with code flattened to one level deep (or a few, in some edge cases) than arbitrarily many. And that's just the "callback hell" improvement; don't forget what a nightmare error handling with callbacks can be — you have to handle both synchronous exceptions and error value callback parameters, you have to deal with the possibility of the asynchronous function unexpectedly calling your callback more than once, etc.

Re: Node v8.1.2

#26
post #23

Earlier quoted context omitted.

You do realize that implementing promises is a prerequisite for async/await, right?

Is it really a requirement? I would think callbacks and a preprocessor are sufficient.

Yes, it's a requirement. If you're using a preprocessor you're not supporting async, you're factoring it out.

Otherwise the argument collapses to: we don't need any of these features, we just need NAND.

Re: Node v8.1.2

#27

Earlier quoted context omitted.

Would you mind sharing your tsconfig(s)? And also do you use sourcemaps on the server?

This is my tsconfig.server.json: { "files": [], "compilerOptions": { "baseUrl": ".", "moduleResolution": "node", "target": "es2017", "jsx": "react", "experimentalDecorators": true, "sourceMap": true, "skipDefaultLibCheck": true, "lib": [ "es2017", "dom" ], "allowJs": false, "paths": { "*": [ "./ClientApp/types/*", "*" ] } }, "exclude": [ "bin", "obj", "node_modules" ] } edit: remove unneeded entries

Looking at "paths", shouldn't those @types (history, redux & react) be picked up automatically, at least as of TypeScript 2.0?

Also:

  "*": [ "./ClientApp/types/*", "*" ]
I like that. I may have to add it to my app and get rid of our typings.d.ts (currently included through "files") once and for all.

Re: Node v8.1.2

#28
post #2

Node 8 is the planned LTS release for later this year. Notably, it brings async/await syntax to vanilla JS. This new feature complements callbacks and largely replaces how Promises are currently consumed (opting for sequential-like execution with try/catch blocks instead of Promise chains). The closest analogue would be Tasks in C#. EDIT: removing reference to node-v8 to prevent confusion.

It's just Node 8. They stopped prefixing with "v" this version in order to avoid confusion with the V8 javascript engine.

If the goal was to avoid confusion, it was an incredibly dumb decision. I'll continue referring its standard version number: Node v8.

Re: Node v8.1.2

#29
post #21
post #4

Earlier quoted context omitted.

Aync/await is the best thing since sliced bread. It has made my life so much easier.

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

Re: Node v8.1.2

#30

Now's as good a time as any to ask: What tools do you folks use to monitor your node dependencies and make sure you are keeping everything up to date?

Definitely something to the addage "if it ain't broke don't fix it". Some of our less critical modules are set to latest others are updated with care. Our modules are not under source control so are refreshed on deployment. We use Snyk to monitor for vulnerabilities, works pretty well.

Are you at least checking in your npm-shrinkwrap.json? (If not you've got pain waiting to happen, that you won't find out about until deploy time)!
Post reply on HN