9 ms·
I feel like such a downer when I ask this about Bun and Deno, but: why should I use them instead of Node? I don’t mean to take away from the obviously impressi
by afavour 3y ago
I feel like such a downer when I ask this about Bun and Deno, but: why should I use them instead of Node?
I don’t mean to take away from the obviously impressive engineering effort here. But VC funding always gives me pause because I don’t know how long the product is going to be around. I was actually more interested in Deno when it promised a reboot of the JS ecosystem but both Bun and Deno seem to have discovered that Node interoperability is a requirement so they’re all in the same (kinda crappy) ecosystem. I’m just not sure what the selling point is that makes it worth the risk.
- solumunus 3y agoI don't know how you're using Node and not thinking "I wish there was a better option than this". I can't wait to jump ship but Bun/Deno aren't quite there yet, for my needs.
- eddd-ddde 3y agoCurious what you are missing to make the jump.
- vbezhenar 3y agoNode is safe choice, IMO. I tried deno and I think it's cool, but I'm staying on node for the time being. Things that deno makes easier are not that hard with node and stability matters for me. For example I had to spend few hours rewriting my tiny service with changed deno API. Don't have any experience with bun, though.
- mmastrac 3y agoIf there are any specific places where Deno didn't support a node API, please file a bug -- we definitely shoot for as close to node.js as possible, and if you have to modify your code that's most often on us. (I'm a deno core dev)
- vbezhenar 3y agoNo, I wrote my service some time ago (basically GitHub Webhook which does some crypto to validate payload and invokes kubectl) using Deno API and few months ago I took some time to update dependencies but found out that with new standard library version some APIs are either deprecated or removed, I don't really remember, but I felt the need to rewrite it. Don't take it as a criticism, I totally understand that you need to iterate on API and nobody promised me that it'd be stable till the end of time, but still work is work.
- mmastrac 3y agoAck, I ran into a similar issue when writing a github webhook. It might be related to JWT handling if it's the same issue. If you recall that exact issue, definitely feel free to file an issue.
- vmfunction 3y agoHow do we report that. Some issues has come up with aws on esm.sh https://esm.sh/@aws-sdk/client-secrets-manager@3.540.0 https://esm.sh/@aws-sdk/client-secrets-manager@3.540.0 It is just not working.
- mmastrac 3y agohttps://github.com/denoland/deno/issues https://github.com/denoland/deno/issues is the ideal place -- we try to triage all incoming issues, the more specific the repro the easier it is to address but we will take a look at everything that comes in.
- brlewis 3y agoSee my answer "what's cool about deno" https://gitlab.com/brlewis/brlewis-aoc/-/blob/main/README.md?ref_type=heads https://gitlab.com/brlewis/brlewis-aoc/-/blob/main/README.md...
- waynenilsen 3y agoBun has been great as a package manager, test suite runner and typescript interpreter. We use node in prod
- charrondev 3y agoI can give a bit of perspective here. I'm currently porting our the Vanilla Forums frontend (~500k lines of typescript) from using Node, Yarn (we used it back before npm supported lockfiles) and Webpack, to build with bun and Vite. There are a few notable differences: - The out of the box typescript interoperability is actually very nice, and much faster than using `ts-node` as we were before. - Installations (although rare) are a fair bit faster. - With bun I don't have to do the frankly crazy song and dance that node now requires for ES modules. - Using bun is allowing us to drop `jest` and related packages as a dependency entirely and it executes our test suite a lot faster than jest did. For my personal projects I now reach for bun rather than node because - It has Typescript support out of the box. - It has a nice test runner out of the box. - It has much runtime compatibility with browsers (`fetch` is a good example). - The built-in web server is sufficient for small projects and avoids the need to pull in various dependencies.
- fastball 3y agoFYI if you want to make a list on HN you're gonna need to add an extra line break everywhere.
- afavour 3y agoESM interop is inarguable. But these days Node has a test runner and compatibility with browsers (it implements fetch)… I guess I feel like Node is likely to catch up with most of this stuff over the lifetime of any long running project.
- fastball 3y agoSure, but node also has a huge amount of baggage and as others have pointed out is much slower.
- charrondev 3y agoOne of things that makes me more bullish on bun rather than Deno is that bun is intentionally aiming for compatibility with node and the npm ecosystem while Deno doesn't seem to be.
- 3y ago
- throwitaway1123 3y agoThe most compelling argument for Deno is the permission system in my opinion. Node added a permission system recently, but it's much more coarse grained than Deno's. Being able to limit a script to listening on a specific hostname and port, or only allowing it to read a specific environment variable is pretty cool, and makes me less paranoid about trusting third party dependencies. Both Bun and Deno are also more performant than Node in many cases, and add a bunch of little quality of life improvements.
- int_19h 3y agoThe real question is how much you can trust this. Those kinds of permission systems have been tried before - e.g. .NET used to have something called "Code Access Security". It was retired largely because the very notion of VM-enforced sandbox was deemed inadequate from experience. IIRC SecurityManager in Java was something similar, also deprecated for similar reasons. I'm afraid that Deno will just be a repeat of that.
- throwitaway1123 3y agoI definitely wouldn't make the Deno sandbox my only line of defense — I'm a strong proponent of defense in depth. Now having said that, there's definitely a precedent for trusting V8's sandboxing capabilities. Cloudflare is running untrusted user code across their entire network and relying on V8 isolates as a sandboxing mechanism for Cloudflare Workers. I'm not sure I would go that far, but I do think we should be taking advantage of the strides browser developers have been making from a security perspective. When I re-watched Ryan Dahl's original conference talk where he introduced Deno, the sandboxing aspect was the part that resonated the most with me. But again, it's always best to have multiple layers of security. You should sandbox your applications and audit your dependencies, those mitigation techniques aren't mutually exclusive.
- int_19h 3y ago.NET sandbox was used for ClickOnce and Silverlight for many years. Java's was used for applets even longer. It worked until it didn't. The people who designed those things ultimately threw in the towel and said that if you want that kind of security, use containers or VMs.
- Solvency 3y agoThe real question is why would I use Bun over Vite? Even the ThreeJS developers determined Vite is the best.
- hiccuphippo 3y agoIt also helps avoid a node/v8 monoculture, just like with web browsers. I'm sure the ecosystem as a whole will get better because of it, even if you decide not to use it.
- mrd3v0 3y agoAvoiding a monoculture by introducing a VC-backed alternative is just asking for another monoculture.
- Osmose 3y agoThe speed increases are nothing to sneeze at; I've moved a few Vite projects over to Bun and even without specific optimizations it's still noticeably faster. A specific use case where Bun beat the pants out of Node for me was making a standalone executable. Node has a very VERY in-development API for this that requires a lot of work and doesn't support much, and all the other options (pkg, NEXE, ncc, nodejs-static) are out-of-date, unmaintained, support a single OS, etc. `bun build --compile` worked out-of-the-box for me, with the caveat of not supporting native node libraries at the time—this 1.1 release fixes that issue.
- llimllib 3y agoI've hit significant failures every time I've tried to use `bun build --compile`; the most recent code I was trying to compile hit this one[1]. I documented how to build a binary from a JS app with node, deno, and bun here [2]. Node SEA is a bad DX, but not that complex once you figure it out. 1: https://github.com/oven-sh/bun/issues/6832 https://github.com/oven-sh/bun/issues/6832 2: https://github.com/llimllib/node-esbuild-executable https://github.com/llimllib/node-esbuild-executable
- Jarred 3y agoI’m pretty sure issue #6842 was fixed in Bun v1.0.32 or so and we forgot to mark the issue as fixed Will check once I get to my computer Edit: was not fixed. We made other changes to fs.readSync to improve Node compatibility, but missed this. It will get fixed though
- throwitaway1123 3y agoBun's standalone executables are great, but as far as I'm aware unlike Deno and Node there's no cross compilation support, and Node supports more CPU/OS combinations than either Deno or Bun. Node supports less common platforms like Windows ARM for example (which will become more important once the new Snapdragon X Elite laptops start rearing their heads [1]). [1] https://www.youtube.com/watch?v=uWH2rHYNj3c https://www.youtube.com/watch?v=uWH2rHYNj3c
- 3y ago
- nikeee 3y agoWe 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]
- yolm 3y agoI used both Deno and Bun. Bun is really nicely compatible with node. Speed of course is excellent, but the main reason I use Bun and recommend it: You replace node, npm, tsx, jest, nodemon and esbuild with one single integrated tool that's faster than all of the others.
- bducycy 3y agoNicely compatible, until it's not. We banned all these forks at work. The dev onboarding overhead is not worth the benefits. Having all 1700 repos using the same build tooling is more important than slight increases in build performance.
- triyambakam 3y agoBanned? Is that why you had to post this on a green text account? Because that sounds immature. If you really have so many repos it sounds annoying that there isn't room for team level experimentation.
- dimgl 3y agoDevil's advocate: Deno and Bun are not yet fully backwards compatible with Node. I myself have run into a _ton_ of pain trying to introduce Bun for my team. This can become a big time sink on bigger teams. That time could be saved by just not allowing it until a full team initiative is agreed on.
- KronisLV 3y ago> If you really have so many repos it sounds annoying that there isn't room for team level experimentation. For what it's worth, I'll say that I can understand such top down governance: you'd have an easier time around moving across projects that you work on within the org, there'd be less risk of a low bus factor, BOM and documentation/onboarding might become easier. Same as how there are Java or .NET shops out there, that might also focus on a particular runtime (e.g. JDK vendor) or tooling (an IDE, or a particular CI solution, even if it's Jenkins). On the other hand, if the whole org would use MySQL but you'd have a use case for which PostgreSQL might be a better fit, or vice versa, it'd kind of suck to be in that particular situation. It's probably the same story for Node/Deno/Bun, React/Vue/Angular or anything else out there. No reason why that mandated option couldn't eventually be Bun, though, for better or worse.
- angra_mainyu 3y agoBun's equivalent of "npm i" is extremely fast, at least an order of magnitude faster on all 3 of my machines. Since I run "npm i" many times per day, that in itself is a big timesaver, not just for local dev but also in CI pipelines.
- arcanemachiner 3y agoHave you tried pnpm? https://pnpm.io/ https://pnpm.io/
- rlt 3y agoHow does it compare to pnpm
- bufferoverflow 3y agopnpm is 3x slower or even more https://miro.medium.com/v2/resize:fit:832/1*noWyIXw-yeNZq5Db2r8tOQ.png https://miro.medium.com/v2/resize:fit:832/1*noWyIXw-yeNZq5Db... https://kinsta.com/wp-content/uploads/2023/12/bun-benchmark.png https://kinsta.com/wp-content/uploads/2023/12/bun-benchmark.... And for running scripts, it's not even close https://miro.medium.com/v2/resize:fit:1400/1*oyPEXsFfZsTg4mOBSIJL_A.png https://miro.medium.com/v2/resize:fit:1400/1*oyPEXsFfZsTg4mO...
- briantakita 3y agoI found Bun to be faster. Monorepo support is a bit kludgy though. Once you know of the workarounds, it's ok. See my comment on https://github.com/oven-sh/bun/issues/5413#issuecomment-1956078162 https://github.com/oven-sh/bun/issues/5413#issuecomment-1956... AFAIK, Pnpm monorepos do not follow standard npm. Bun does follow standard npm monorepos. Pnpm's feature to override dependency versions is nice for legacy projects with many 3rd party dependencies. Not sure if Bun has the same feature. I mostly use it on greenfield projects with dependencies that I control.
- CuriouslyC 3y agoI can't speak for deno, but bun is drop in compatible for most things and the test runner speed alone is enough to make it worth using.
- crabmusket 3y agoI really like Deno for small scripts and small side projects - it's just fast to get started with. And it allows me to use web standards, like URL imports to grab packages from CDNs instead of having a config file. There's just less to think about, like oh what was Node's crypto thing? Node is making strides in web compatibility, and building in things like a test runner. And I don't have much interest in migrating company projects away from Node. But Deno feels really fresh and light when I just need to run some JS.
- dcre 3y agoI haven’t used them yet for full sized apps, but they are both fantastic for scripting and small CLIs. Between the ease of running scripts, nice standard libraries, npm ecosystem, and excellent type system, I now feel TypeScript is a better scripting language than Python or Ruby.
- triyambakam 3y agoI used to think so too, but that was because I had never really used Python. I still think Ruby is a mess, but it's so amazing how easy it is to manipulate data in Python, and so much faster. I recently wrote a Node/Bun/Deno app that parses a 5k line text file into JSON. The JavaScript on any runtime takes 30-45 seconds. The Python implementation is sub 1 second. I would not have been able to finish the tool so quickly if I were stuck relying on JS. I still love Typescript but I'm not as blind about it now.
- Jarred 3y agoWhat does the code do? 30-45 seconds to parse a 5k line text file into JSON sounds like something is going very wrong
- dcre 3y agoThat runtime doesn't make any sense. This script creates a 1,000,000 line CSV string and then parses it into JSON in 700ms with Bun, and this is doing both things the slow way, creating the string with a giant array map and join, and parsing with a giant split('\n') on newline and map. https://gist.github.com/david-crespo/8fea68cb38ea89edceb161d6b479bccd https://gist.github.com/david-crespo/8fea68cb38ea89edceb161d...
- postepowanieadm 3y agoCute logo. And UX is pretty great: integrated fetch, simplified fs api, integrated test runner (I miss good old TAP style assertions though), ESM/CJS modules just work, some async sugar. I think if they offer me a paid *worker solution, with sqlite, that's something I'm willing to pay for.
- WuxiFingerHold 3y agoI have ask myself the same question a couple of weeks ago and decided to use Node for some side stuff. Simply because of Node being the most mature, boring choice. Still, I like the DX improvements of both Bun and Deno a lot. We'll see how it all plays out in some years.