Node.js 13.0 | Hacker News Reader

Node.js 13.0

github.com

115 pointsvhiairrassary47 comments

To save you the clicks: Node 13 doesn't support top-level await.

Node includes V8 7.8, released Sep 27. https://v8.dev/blog/v8-release-78

Top-level await merged into V8 on Sep 24, but didn't make it in time for the 7.8 release. https://chromium.googlesource.com/v8/v8.git/+/0ceee9ad28c21b...

TLA is only in modules. Once node supports modules, it will also have TLA.

We're also pushing out a version with 7.9 fairly soonish.

Speaking of which, is anyone using deno (https://deno.land/) for anything real yet?

When I think secure I think

  import { serve } from "https://deno.land/std@v0.19.0/http/server.ts";

It would be better to integrate something into Node.js instead of inflating a new economy balloon!

What do you think is happening when you `npm install` or `yarn add` a package?

`npm`/`yarn` have hash checks when using the lockfile (side note: you should be using `npm ci` in your deployments so it doesn't install newer versions). Maybe there could be a lockfile system for webpack that would verify a file like the one they suggest doesn't change between installs and systems.

Doesnt deno also have a lockfile?

That's why I don't want to use it personally, it's all in the imports. Making things a pita when you want to just upgrade something.

Yeah, we need a new JS ecosystem, let's rebuild all our stuff using deno instead node, because it was a quiet year and we have all recovered from the JS fatigue.

Node has to be painful enough for people to make the switch. I don't think we've hit that point yet.

I can't think of any node.js painpoints. Can you list some examples? I've been coding in it at a high level for the past 5 years.

Same! What pain points?

I got downvoted to hell and back for saying node.js is easier to develop in/be efficient in/be productive in than Haskell. Can you believe that?

Nothing real, but I am watching closely. I write everything in TypeScript anyway and it is annoying figuring out what adapters to use to get testing libraries working and VSCode debugging, and debugging tests, etc.

If they implement Go-style concurrency that would kick this project up to the next level.

> If they implement Go-style concurrency that would kick this project up to the next level.

I don't think that would work given the fact that it still runs V8's event loop.

I've been using node with typescript and it's amazing.

VERY productive. The key thing is you can do a large refactoring without breaking anything.

The biggest challenge I have right now is actually the tooling. Intellij tends to break sometimes.

I'm using lerna for a monorepo with sub-modules and it's buggy with regular npm.

For example 'npm audit' doesn't work.

I might have to migrate to yarn...

I migrated to yarn workspaces and it made things very simple. It definitely handles dependencies better.

Out of curiosity, why do you use IntelliJ instead of VSCode for a TypeScript codebase? VSCode was practically purpose-built for TypeScript.

IntelliJ is just a very well written IDE. Searching for methods still feels better in IntelliJ. Or the refactoring possibilities like - move an interface/function/class into a separate file and IntelliJ will fix all imports to the reference for you. Under the hood they nowaday also use the language services (like typescript), but there are so many features on top.

VSCode is great at the things you just mentioned. I agree IntelliJ is excellent for Java, but even multi-ecosystem tools tend to be biased towards certain use cases.

Language-servers make the choice of IDE moot. My vim setup is just as capable with typscript as vscode.

They don't completely. They help a ton, but certain IDEs are designed holistically with certain use-cases in mind and have very specific features that lend themselves to those use-cases on top of the basic error/autocomplete language support.

For example, the Rust extension in VSCode gives me an inline button next to any function that's annotated as a test, which I can click to run that test. That's really useful and really specific to Rust. Whereas other IDEs (or other IDE extensions) might just do a bare-bones language server hookup to show errors and that's it.

> For example, the Rust extension in VSCode gives me an inline button next to any function that's annotated as a test, which I can click to run that test

Not an ideal example. The rust-vim plugin supports the same feature (though, naturally via keys instead of mouse).

https://github.com/rust-lang/rust.vim

VSCode isn't there yet for Python refactoring - I still find myself needing to find and replace to get everything when I rename a symbol or move a package (breaking imports). I should never have to do that.

Pycharm refactors Python flawlessly.

I would love to be exclusively in VSCode because of its configurability & overall snappiness but it's just not there for Python

My point exactly. VSCode was purpose-built with TypeScript in mind, IntelliJ was purpose-built with Java in mind (it's right in the name), Pycharm was purpose-built with Python in mind. It's great when an editor supports several languages, but it's probably going to support one or two of them better than the rest, so you want to pick yours based on what you spend most of your time in.

I also use IntelliJ instead of VSCode for Typescript and my reason is ecosystem. I write PHP, Java, TS/JS/Node, some python, and I might need to look at some C code from time to time. I also use DataGrip as my DB browser so I am heavily invested (knowledge, not $$$) in the JetBrains ecosystem. My hotkeys and muscle memory work everywhere and I love switching between languages but keeping all my UI/UX the exact same.

I've tried the "build an IDE from plugins on top of a lightweight editor" before and I just don't think you can beat the interoperability of IDEA. I can trust the first-party plugins 100% and use them without worry. That wasn't my experience using other editors. That's no shade towards people who use and like VSCode, more power to you! Really! It's just not for me and I feel very at home in any language using IDEA Ultimate.

I just switched jobs and the new job doesn't pay for developers IDE's (yet) like my last job did. I didn't for a second consider using anything but IDEA. In fact I missed the "Individual"/"Organizations" distinction and even considering the "For Organizations" pricing ($499 1st year, $399 2nd year, $299 3rd year+) it still didn't phase me. I really feel like I get that much value out of these tools. That said I was happy to pay FAR less as an individual.

Jetbrain's intended javascript/typescript IDE is WebStorm, but I wouldn't blame you for not using it since it's a $60/year commercial product [but free for students and open source projects].

All of WebStorm's features are integrated into IntelliJ Ultimate, which is what I'd assume that the GP is using.

  console:
  The output console.timeEnd()
  and console.timeLog() 
  will now automatically select a suitable time unit instead of always using milliseconds (Xavier Stouder) #29251

Am I the only one that finds this unacceptable? Instead of a consistent result of a number, let's return string.. That now I have to parse..

Agreed. That's a ridiculous change.

A well defined function should have a single purpose, and a reliable and repeatable output.

It's a function on `console`. It's meant to be human-readable, not machine-readable.

Console logging can be useful for eg being fed into Splunk from an ECS instance.

I don't do node.js so perhaps there are other ways of doing that specifically. (Works great in .net core)

It doesn't output back into your code though; it goes directly to stdout, so its main priority is readability for debugging. If you need log-quality output for parsing by another program there are plenty of libraries for getting time in whatever format you wish.

I think it’s ok, it’s just a debug statement that I think outputs to stderr. You should never be parsing it.

Shouldn't it be better to have a second function that spits out a formatted version? Or a parameter for a format. Or a parameter to switch between pretty and raw numbers?

no—this is something that likely shouldn't ever even be committed into a codebase. It's just something you throw in while testing to check why the performance of something is acting up.

The default is really important for something like this. Much more important than consistency.

I looked at the code (but didnt try it) and I think this only affects console output, not any return value that you would parse.

I believe it rever really returned anything. It just wrote them on stdout.

It's not an API incompatibility.

It is a shift in the behavior of a side-effect though. Anyone who set up metric math based on log values here would be in for a surprise when they try to look at their reports.

This is definitely one of the gray areas when deciding whether or not to consider it a breaking change.

I agree it’s grey-area, but I’d lean towards calling it a breaking change, as it’s not too hard to imagine setups that would rely on a particular stdout format (e.g. some kind of log-parsing to generate an HTML report from an e2e test orchestration suite). But this is a major update, so breaking is fine anyway.

You should not parse the stdout produced from console functions. It is for producing human-readable information. If you want machine-consumable data, you should use something like benchmark.js.

How far we have strayed from the days where Unix tools were meant to be used as a stdlib, called through stdin and out. It makes me a little sad.

Classic HN comment on this topic: https://news.ycombinator.com/item?id=6530180

Not that far. Node has process.stdout/process.stdin/process.stderr. It's just that the console API is for debugging.

That's true of stderr output. You should be able to parse stdout though - otherwise how are you meant to use piping etc

The timezone fix is pretty nice. It's one of those issues that seeps into the institutional knowledge of a project and people tell you to "just fix it in your code". I suspect stackoverflow questions on node runtime timezone changes will plummet :)

You can also now tell Node.js to use the experimental REPL (https://github.com/nodejs/repl) by default using the NODE_REPL_EXTERNAL_MODULE env variable!

Still no ES module support that doesn’t require special flags or weird file extensions? Come on

Reply on news.ycombinator.com