
Node.js 13.0 - vhiairrassary
https://github.com/nodejs/node/releases/tag/v13.0.0
======
dfabulich
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](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...](https://chromium.googlesource.com/v8/v8.git/+/0ceee9ad28c21bc4971fb237cf87eb742fc787b8%5E%21/)

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

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

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

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

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

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

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

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

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

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

~~~
fjp
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

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

------
simplyinfinity

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

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

~~~
nothrabannosir
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](https://news.ycombinator.com/item?id=6530180)

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

------
jonluca
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 :)

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

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

