ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops.

It took a while to convince everyone involved to just be pragmatic, but it's nice now.

trpc and ts-rest are a different animal in my opinion. I'm happy to use either one but won't deal with them in production. For trpc that's mainly due to the lack of owning API URLs and being able to more clearly manage deprecating old URLs gracefully.

For ts-rest I just tend to prefer owning that setup myself, usually with zod and shared typings for API request/response pairs. It also does irk me every time I import what is clearly an RPC tool named "-rest"

"To discourage package authors from publishing packages written in TypeScript"

I tried to use it with private packages but that doesn't work either, apparently node doesn't even read the "private" field.

Last actually note-worthy improvement I heard of was properly supporting import/export (although do you still need to use the .mjs hack?), but I've been out of the loop here for sometime so would be nice to know what they've added since.

On the projects I am involved, they could even not exist, only node LTS releases matter, and the most recent projects are still node 20.

Writing a library in TypeScript (with typechecks in CI/CD as devDependencies) and just importing it directly from Node.js...

Because Node is controlled by and maintained via the OpenJS Foundation. Bun is a venture-backed startup. That would be fine, but multiple, direct requests from me to the founder (Jared) about what the business model is (what I personally need to say "yes" or "no") have gone without response every time.

That led me to the assumption that Bun may very well be technically superior (or at least on the track to being so), but I can't bet anything significant or long-term on it. I need to know that this isn't just an exit vehicle for the founder (masquerading as a desire to fix JS server runtimes). Silence to a simple (dare I say, obvious) question doesn't bode well.

Node has its share of flaws, but it's the de facto baseline against which things are tested and developed. I'm somewhat more comfortable working with The Main Thing.

The JavaScript ecosystem is nightmarish enough that many developers don't want to switch to the Next Cool Thing. I think many of us have had enough fatigue caused by new build tools, new bundlers, new runtimes, etc.

As of right now, Bun is not compelling enough for the potential headaches down the line.

(Maybe there won't be any, but I've spent weeks dealing with incompatibilities caused by a single TS minor update (which should've been breaking). Days chasing after dependency problems, after missing docs, etc.)

localAddress on TCP connections ignored, last time I tried it its no-op

Incompatibility with Node module APIs (https://github.com/spamscanner/spamscanner wouldn't work)

EventEmitter race problems (partially worked around with https://www.npmjs.com/package/eventemitter2)

Svelte vites dev server sometimes forever freeze until I wiped node_modules and reinstalled it.

I'm waiting patiently for bun to catch up because I would love to switch but I don't think its ready for production use in larger projects yet. Even when things work, a lot of the bun-specific functionality sounds nice at first but feels like an afterthought in practice, and the documentation is far from the quality of node.js

Really, in the Node ecosystem you eventually learn not to put all your eggs in one basket. Different things excel in different aspects. Here is my preferred setup for now:

Bun.js: As a Node runtime, and for TS execution and test running. I tried lots: TSX, TS-Node, Node itself

NPM For executing tooling scripts

PNPM For installing dependencies. It's simply better than the rest (npm, yarn, bun) for several reasons

Biome.js For linting (superior to every other tool I tried)

I dislike being on the bleeding edge for things. NodeJS is the most supported in the JS ecosystem. I find it much better to just be on the "default" option for things. You know, choose boring technology.

Why would you switch from runtime A to runtime B? I mean, you presented no reason at all, let alone a compelling one, to pick either one. So what leads you to believe it is a reasonable idea to waste time switching runtimes?

The best way to do this atm. is using (and configuring) yarn for zero-installs.

This keeps dependencies inside the codebase so that: * Issues can be easily traced to the code that actually ran - development and deployment are the same. * Deployment doesn't depend on package repositories. * Deployment is secure from many kinds of attacks. * It is possible to transparently patch packages. * Development is only internet dependent when adding a new package. * and the best ease-of-use - no reinstall when changing branches.

Simple example: you know how at the command line you can type "npm run", and then type a character or two, hit tab, and the appropriate script from your `package.json` will autocomplete? And if you keep going (eg. "npm run knex") you can do the same thing to autocomplete arguments?

Bun still hasn't figured out how to do that (https://github.com/oven-sh/bun/issues/6037), even though they can all but copy NPM's (already written) completions. I really liked using bun when I played around with it (and it ran my codebase perfectly, without issue) ... but if they can't handle something as simple as Bash completions, they're clearly not ready for the big leagues.

You can run a typechecker (such as tsc) that check various properties of your code statically, relying on the type information. It is then erased.

The same applies, say, to Python: type annotations are ignored at runtime. Somehow similarly, Java's type information is also partly erased in the bytecode; in particular, all the information about parametrized types. (This is to say nothing about actual machine code.)

That's a bit misleading. Node being able to run TS code does not "improve safety", because that's not where the type checking happens. You can do type checking in your editor, or various other points in your toolchain.

Node being able to run TS code reduces the friction in writing TS code, which indirectly helps with type safety.

To check types at runtime (if that can even be done in a useful way?) it would have to be built into v8, and I suppose that would be a whole rewrite.

I suspect this would only handle the most rudimentary and basic typescript files. Once you start using the type system more extensively I suspect this will blow-up in your face.

It's kinda a shame. What a missed opportunity to do it properly (rather than relying on third party plugins etc)

Edit: if you are just using typescript for type checking at build time (i.e. the most basic rudimentary typescript files) the sure fine this may help you. But typescript also generates JavaScript code for missing features e.g. proper class access modifiers, generics, interfaces, type aliases, enums, decorators etc etc. typescript generates JS code to handle all that, so you're going to have a bad time if node just replaces it with the space character at run time.

As a note, Node has a built in --watch now, too

Fastify, NestJS (bleh), Koa, Hono are the modern replacements for express, none of them have caught on as a standard though. My personal favorite for small projects is Polka (https://github.com/lukeed/polka), when I'm not using Go instead.

And do mean everything: I run an entire Postrgraphile server through Next (and you can easily do the sme with Supabase or a similar tool)!

ES5 standard (released in 2009) didn't have modules.

TypeScript is for compile time checking of a language that was not designed to have them. Runtime types have very different requirements! It has to be in the language from the early design phase, otherwise it will just be a hack with many conditions, restrictions and holes.

TS Types are only partially a description of the underlying types in the code, a very big part instead is that it provides guard rails that prevent you from using a lot of perfectly fine and valid JS code that would however be incompatible with type guarantees. You pay the price of using only a part of the large space of JS code possibilities for guarantees. If you were to put that into the runtime you would end up with two different versions of the language. If you still want to support the full JS you would end with two runtimes in one (or one that has so many branches and conditions that maintaining that runtime is a real beast).

typescript is pretty ambiguous about a lot of the things that would need explicit definition for runtime safety, and anyways we already have tools for that - it’s called zod.

and comprehensive checks would incur a significant runtime penalty, unless they were restricted to external interfaces, which is what you’re really concerned about. we already have tools for that - protobuf, swagger, etc.

anything else is sharing a runtime with you. so either it’s in your ide, and you just don’t write shitty code; or you’re trapped in some kind of demonic javascript prisoner’s dilemma, and you are mutable.

so typescript is basically ‘good enough’ for developers.

thinking forward anyway, and assuming you’re really willing to share a runtime with a stranger…

node doesn’t really operate in that kind of context, but maybe browser code does. i could imagine a framework based on web components, workers, and maybe iframes, taking advantage of message boundaries to enhance analysis and conceal code generation. it’s not that much better than typescript.

but if you want efficient runtime checks, and you want to leverage static analysis and strong module boundaries to scope the type-checking codegen, and you probably need additional syntax, you might as well target wasm.