5 ms·
We could drastically simplify the building and deployment process of our services. By far the greatest advantage is that it runs TS natively. Dropping the compi
by nikeee 3y ago
We could drastically simplify the building and deployment process of our services. By far the greatest advantage is that it runs TS natively. Dropping the compilation stage simplifies everything. From docker imaging to writing DB migrations to getting proper stack traces.
You don't need source maps. You don't have to map printed stack traces to the source. Debugging just works. You don't need to configure directories because src/ is different than dist/ for DB migrations. You don't have to build a `tsc --watch & node --watch` pipeline to get hot reloading. You don't need cross-env. No more issues with cjs/esm interop. Maybe you don't even need a multi-stage Dockerfile.
That's for bun. Deno might have a similar story. We did not opt-in to the Bun-specific APIs, so we can migrate back if Bun fails. Maybe we could even migrate to something like ts-node. Shouldn't be that hard in that case.
IMHO the API of Bun, as well as the package manager, sometimes tries to be _too_ convenient or is too permissive.
- Waterluvian 3y agoCurious: 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.
- deleted 3y ago[deleted]
- nikeee 3y agoIt 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.
- deleted 3y ago[deleted]
- nsonha 3y agois there such a thing as running TS natively? Even tsc doesn't do that.
- ibash 3y agoKind 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 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 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.
- Jarred 3y agoWe’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
- zackify 3y agoEvery 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!
- paulddraper 3y ago> 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.
- smt88 3y agoPython 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.
- 7bit 3y agoI 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.
- hibbelig 3y agoJava is compiled, too. The Java runtime is the JVM which runs byte code.
- paulddraper 3y agoJVM runs java bytecode. Java bytecode is compiled from Java (javac), Scala (scalac), etc
- baq 3y agothe 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.
- solumunus 3y agoJust, what?!
- searchableguy 3y agoYou can use tsx as loader with node if you want to directly run typescript. node --import tsx ./file.ts
- galaxyLogic 3y agoDoes 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?
- zackify 3y agoThe 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
- leptons 3y agoI'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.
- erhaetherth 3y agoIt's still faster. `bun test` is like a gajillion times faster than jest + all the voodoo to make it run TS.
- __alexs 3y agots-node has all of these features too?
- xdennis 3y agoYes, 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
- tubthumper8 3y agots-node does type checking by default using `tsc`. Bun does not, so this isn't an equivalent comparison
- __alexs 3y agoNow try with SWC enabled.
- dzonga 3y agowhat 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.
- nsonha 3y agomany 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.