Kind of. When you do try to run bun in production you'll find out that it has significant differences to node -- like not handling uncaught exceptions: https://github.com/oven-sh/bun/issues/429

Then you'll use bun build and run node in production, only to find that sourcemaps don't actually work at all: https://github.com/oven-sh/bun/issues/7427

So you'll switch to esbuild + node in production :)

Definitely excited for the promise of bun, but it's not quite baked yet.

We’ll add the uncaught exceptions handler likely before Bun 1.2 and fix the issue with sourcemaps. Sourcemaps do work (with some rough edges) at runtime when running TS/JSX/JS files, but are in a worse state with “bun build” right now.

We’ve been so busy with adding Windows support that it’s been hard to prioritize much else

Every couple weeks I try again to run my app fully on bun. For now I just use it as a packager.

The big ones for me are continual prisma issues. Mainly due to poor decisions on their side it seems…

Vite crashing. Because I’m using remix.

And then the worst one I don’t see a way around: sentry profiling which requires v8.

I can’t wait for the day everything can be on bun. Everything else sucks and is so slow or requires really bad configuration to make it work.

Can’t believe node itself and TS are so terrible with module compatibility. Bun solves all of this and is 20000x faster when I can use it!

What prisma issues are you running into? For us we just installed node alongside bun in our docker container and then ran prisma with node… was there something else?

you're running your app using the node runtime still.

Half the reason I want to use bun is to not use node for the runtime so that it's faster and the docker image is also smaller.

Much appreciated and definitely rooting for bun! It’s still my goto choice for dev and can’t wait to switch production back to bun :)

Curious: does it run TS natively or does it just transpile for you? Because the former suggests exciting opportunity for better compiling or JITting if it can actually commit to holding on to the typing.

It does not do any type checking. You have to run tsc with noEmit separately. If you run `bun run foo.ts`, it just ignores all type annotations. It is transpiled to JS internally by removing the types (or it skips the types while parsing). While doing that, it keeps track of the original source locations. If you see some stack trace, you get the original location in the ts source.

Running tsc with noEmit is pretty much the standard in the frontend as well, as the TS is bundled by esbuild/rollup directly.

is there such a thing as running TS natively? Even tsc doesn't do that.

You can use tsx as loader with node if you want to directly run typescript.

node --import tsx ./file.ts

The problem is, if you have ESM and then a tool in your repo like jest, requires commonjs.

Now you have to compile stuff.

In my case I’ve had apps use certain ts config options, and then another library has a start script which is incompatible.

So you’re stuck needing a different TS config for both things. These annoyances are solved with bun

Does it support editing the source-files while in the debugger?

I've been hesitant to move to TypeScript because I'm unsure how well the debugger works in practice.

My current platform is Node.js + WebStorm IDE as a debugger. I can debug the JavaScript and I can modify it while stopping at a breakpoint or debugger-statement. It is a huge time-saver that I don't have to see something wrong with my code while in the debugger and then find the original source-file to modify and recompile and then restart.

Just curious, do Deno and Bun support edit-while-debug, out of the box? Or do I need to install some dependencies to make that work?

I'm not sure how difficult it would be for Nodejs to support .ts files natively. But if that's the main reason to use Bun, I'd be worried about its long term viability. Node could announce native .ts support at any time and then Bun might not look so good.

It's still faster. `bun test` is like a gajillion times faster than jest + all the voodoo to make it run TS.

>a gajillion

That seems like a made up unit of measurement. If you have real statistics, show those. If not, then this is just hearsay.

The benchmark is right on the main page of bun.sh, just ctrl+f for „bun test“

what if I don't like typescript ? and like duck-typing my way through. and adding annotations when necessary via jsdoc ?

not everyone likes typescript or finds it useful. e.g svelte dropping typescript ?

not to take away the amazing work people at bun have done.

many people have commented, bun is all the tools in a single dependency: a test runner with in-memory db included? Shell support for window? Single file executable packaging? with macros? Code scratchpad that auto-installs dependencies? Programmatic APIs for transpiling/loading jsx (not tsx)? ... so on.

ts-node has all of these features too?

Yes, but it's slower. Here are the times for running a script that just prints hello.

    $ time bun hello.ts 
    real  0m0.015s
    user  0m0.008s
    sys   0m0.008s

    $ time ts-node hello.ts 
    real  0m0.727s
    user  0m1.534s
    sys   0m0.077s

ts-node does type checking by default using `tsc`. Bun does not, so this isn't an equivalent comparison

Now try with SWC enabled.

> By far the greatest advantage is that it runs TS natively.

So why doesn't any major runtime run Java natively? Or C++ natively? Or Rust natively?

Why is this such a cool unlock that hasn't been done for any other language?

---

85% of this are people tired/bored of Node.js.

Python is among the most popular languages and it doesn't require a compile step.

TypeScript is entirely metadata, so it just doesn't make sense to need to compile it.

I don't understand your point. I don't even understand your argument.

The java runtime runs java.

And C++ and Rust are compiled and have no runtime.

JVM runs java bytecode.

Java bytecode is compiled from Java (javac), Scala (scalac), etc

Java is compiled, too. The Java runtime is the JVM which runs byte code.

the jvm bytecode has been designed to be bytecode from day 1.

JS is the TS's bytecode but it has been designed to be a language to be developed in, which causes impedance mismatches as tools and people get confused about the usage context.

Just, what?!