Hacker News Reader

Comment by rockwotj | Hacker News Reader

My favorite deno feature is coming to node directly. Awesome!

Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again after a few months.

View on HN

btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx.

https://github.com/privatenumber/tsx

I second this. The tsx library is zero config and always "just works" in my experience, which puts it miles ahead of ts-node, imo.

Seconded again. While tsx usually just works ts-node almost never just works. tsx is perhaps unfortunately named though so it may confuse people at first since it has nothing to do with jsx syntax.

Thank you for bringing this up, I almost ignored this project since I assumed it had something to do with TypeScript + JSX.

The JS ecosystem sure struggles with naming things.

The _programming_ ecosystem sure struggles with naming things.

Fair enough

I own the npm package node-ts, which has thousands of installs per week just because people confuse it with ts-node.

I didn't intend to typo-squat. Actually, my package is older than ts-node and was just a pun because it is an API for TeamSpeak written in TypeScript.

It's named as such to mirror `npx`

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.

Does swc-node work with code coverage calculation libraries? For a long time tsx didn’t (and it’s still pretty finicky) so that kept me from using it.

Not sure what features those need, but at least the stack traces are correct in swc-node, so maybe worth a try.

We have not seen this whatsoever. How big is your project? `tsx` is almost instantaneous in a server-side project of ours.

A hello world here takes 400ms on tsx and 250ms on swc-node for me.

Basically it boils down to swc being faster than esbuild, see their benchmarks:

https://swc.rs/docs/benchmarks

Tsx’s only reset-in-console mode is <Enter>, which makes it impossible to develop cli apps in watch mode.

You cannot run tsx from a non-project cwd if you’re using tsconfig/paths.

And personally I find its maintainers relatively unpleasant to message with. Leaves “you’re plebs” aftertaste most of the times.

Have you tried https://github.com/google/zx?

This seems very interesting approach to scripting. Does it basically provides with an alias to child_process.exec as $ and besides that I can write in the same way I'd do in Node?

> Node.js standard library requires additional hassle before using

I read the hassle as having to setup Node runtime in advance, but zx requires npm to install so I'm not sure.

correction: the only deno future that i want

Deno has so many other great features. Most web standard APIs are available in Deno, for example. It can do URL imports. It has a built in linter, formatter, and test framework. Built in documentation generator. A much better built in web server.

Node is copying many of these features to varying degrees of success. But Deno is evolving, too.

the url imports is one the things I don't want.

There are also the `npm:`, `node:` and `jsr:` specifiers now. So you don't have to use the URL imports if you don't feel them.

You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the module version into the URL so that the version can be stored separately, alongside the module name. Popular hosts with well-known URL structures could have their URLs automatically templated so you only have to specify the host and not the rest of the URL.

In other words, the tooling could be better, but the fundamentals of URL imports are sound, IMO.

I disagree. It should not default to "https://" (I think defaulting to local files would be better).

Furthermore, I think that it should be made so that the "hashed:" scheme that I had invented (in the Scorpion protocol/file-format specification document, although this scheme can be used independently of that) can also be usable.

And, popular hosts with well-known URL structures automatically templating also I would disagree, although it might do to allow any expressions in place of the string literals and then add functions for abbreviations of some of those URLs, if that would help (although I still think it is unnecessary).

yes, I would prefer to use a centralized registry indeed. However, that's not actually what i'm talking about here. Even just decoupling the import from the package is enough. You can already do this by by pointing a package in package.json to a remote tarball or git repo.

Node supports URL imports via the --experimental-network-imports command line option. There's also a built in test runner now.

... and obviously the only one you know.

Kidding aside: You should really take an hour and check out the manual and std lib (https://jsr.io/@std). I was surprised how far Deno has come. A lot of pretty useful stuff you would otherwise need tons of NPM modules for.

Reply on news.ycombinator.com