7 ms·
Deno 2.4
- duesabati 1y agoI really love where Deno is going, it really is what Node should've been. My only concern is that they lose patience to their hype-driven competition and start doing hype-driven stuff themselves.
- forty 1y agoI thought that Deno was the hype-driven competition of nodejs ;)
- deafpolygon 1y agoI keep hearing good things about Deno. It might just convince me to try js after all!
- bugtodiffer 1y agoDont
- hn_throw2025 1y agoThese days it might be good to go straight to TS.
- rizky05 1y ago[dead]
- WorldMaker 1y agoWhich is what the Deno defaults guide towards as well.
- voat 1y agoPeople underestimate the node compatibility that Deno offers. I think the compat env variable will do a lot of adoption. Maybe a denon command or something could enable it automatically? Idk.
- CuriouslyC 1y agoHonestly, I was bullish on Deno back in the day, but I don't see why I'd use it over Bun now.
- jitl 1y agoLess segfault, improved security / capability model
- spiffytech 1y agoAs a Bun user I don't really get segfaults anymore.
- fleetfox 1y agohttps://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20label%3Acrash https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
- surajrmal 1y agoI've written C for years. The only time it is safe from crashes is when the code doesn't churn and has consistent timing between threads. bun has constant feature churn and new hardware it runs on all the time providing novel timings. It is very unlikely going to be crash free any time soon.
- drewbitt 1y agoJust got one today! But yes it is better.
- tmikaeld 1y agoThe security model is very underestimated imo, it will be very evident when more bun projects reach production and not experimental.
- beef_rendang 1y agoIf the drive is towards greater performance by leveraging native code, at what point do we just bypass the JavaScript runtime abstraction and build directly with a language like Rust? The ecosystem seems to have hit a critical mass for web development. You now have incredibly mature and production-ready frameworks like Actix and Axum, along with innovative ones like Warp and Tide, providing everything you'd expect from routing and middleware to templating and native JSON handling. There are crates for everything, like for databases, there's powerful options like sqlx for fully async compile-time checked queries or Diesel for a feature-rich ORM, so it feels like all the pieces are there.
- sylware 1y ago[flagged]
- tojaprice 1y agoIt is V8.
- bargainbin 1y agoDeno is a JS runtime (written in Rust) on the V8 engine. What’s horrible about V8?
- sylware 1y agoV8 is c++, mechanically an abomination.
- frou_dh 1y agoHobby-horse trolling detected.
- eranation 1y agoI believe the reason Deno is not more widely used in production environments is the lack of a standardized vulnerability database (other than using 100% npm compatibility which will take many popular deno packages out of scope). The issue is that there is no real centralized package manager (by design) which makes it challenging. Was there any development in that direction?
- TheDong 1y ago> I believe the reason Deno is not more widely used in production environments is the lack of a standardized vulnerability database If this were a real blocker, then C/C++ wouldn't be used in production either, since both just lean on the language-agnostic CVE/GHSA/etc databases for any relevant vulnerabilities there... and C also heavily encourages just vendoring in entire files from the internet with no way to track down versions. Anyway, doesn't "deno.lock" exist, and anyone who cares can opt-in to that, and use the versions in there to check vulnerability databases?
- simantel 1y agoWouldn't this also be a problem for Go, which just imports from URLs (mostly GitHub) as well?
- deleted 1y ago[deleted]
- jitl 1y agoThe go imports use a Google-owned proxy for resolution which has a vulnerability facility. All golang package installs use the Google-owned proxy unless you set GOPROXY=direct when running go commands. https://arc.net/l/quote/arrozgok https://arc.net/l/quote/arrozgok
- bflesch 1y agoBig fan of deno, congrats on shipping. From a security standpoint it really icks me when projects prominently ask their users to do the `curl mywebsite.com/foo.sh | sh` thing. I know risk acceptance is different for many people, but if you download a file before executing it, at least you or your antivirus can check what it actually does. As supply chain attacks are a significant security risks for a node/deno stack application, the `curl | sh` is a red flag that signals to me that the author of the website prefers convenience over security. With a curl request directly executed, this can happen: - the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code - MITM attack gives you a different file than others receive Node/deno applications using the npm ecosystem put a lot of blind trust into npm servers, which are hosted by microsoft, and therefore easily MITM'able by government agencies. When looking at official docs for deno at https://docs.deno.com/runtime/getting_started/installation/ https://docs.deno.com/runtime/getting_started/installation/ the second option behind `curl | sh` they're offering is the much more secure `npm install -g deno`. Here at least some file integrity checks and basic malware scanning are done by npm when downloading and installing the package. Even though deno has excellent programmers working on the main project, the deno.land website might not always be as secure as the main codebase. Just my two cents, I know it's a slippery slope in terms of security risk but I cannot say that `curl | sh` is good practice.
- bugtodiffer 1y agousing deno isn't good security practice, their sandbox is implemented like stuff from the 90s
- bflesch 1y agoIs node "sandbox" different? Does it even have a sandbox?
- throwitaway1123 1y agoNode does have a permissions system, but it's opt in. Many runtimes/interpreters either have no sandbox at all, or they're opt in, which is why Deno's sandbox is an upgrade, even if it's not as hardened as iptables or Linux namespaces.
- blinkingled 1y agoCrazy that Deno is still not workable on FreeBSD because of the Rust V8 bindings not being ported.
- Mond_ 1y agoHow big is the intersection of modern Javascript developers and FreeBSD users?
- blinkingled 1y agoNot as big as Linux but I know a few FreeBSD shops that run NodeJS apps so it's not entirely crazy to think that there are more and they would want to try Deno. Besides making your OSS software compilable on *BSD/Linux/Mac/Win has historically been a good thing to do anyways.
- whizzter 1y agoFor a lowlevel runtime (ie V8 itself) I can accept certain lag since there might be some low-level differences in how signals,etc behave. However for more generic code Linux'isms often signals a certain "works-on-my-machine" mentality that might even hinder cross-distro compatibility, let alone getting things to work on Windows and/or osX development machines. I guess a Rust binding for V8 is a tad borderline, not necessarily low-level but still an indicator that there's a lack of care for getting things to work on other machines.
- surajrmal 1y agoIs it big enough to prioritize fixing though? The answer seems to be a no so far.
- gr4vityWall 1y agoNode.js is (maybe surprisingly) used a lot in less common operating systems like FreeBSD and Illumos.
- ctz 1y agoLooks like it is in ports?
- mcraiha 1y agoI really like that bundle subcommand is back. No need to use workarounds.
- aseipp 1y agoNice list of solid changes. I really like Deno for scripting random glue code; I use it most places (maybe with the exception of random machine learning stuff, where python/uv fits.) Looking forward to gRPC support later this year, too, for some of my long-tail use cases. And the bundle command looks nice!
- outlore 1y agoReally love the ideas behind Deno, and tried to do things the Deno way (Deno.json, JSR, modern imports, Deno Deploy) for a monorepo project with Next.js, Hono and private packages. Some things like Hono worked super well, but Next.js did not. Other things like types would sometimes break in subtle ways. The choice of deployment destination e.g. Vercel for Next also gave me issues. Here is an example of a small microcut I faced (which might be fixed now) https://github.com/honojs/hono/issues/1216 https://github.com/honojs/hono/issues/1216 In contrast, Bun had less cognitive overhead and just "worked" even though it didn't feel as clean as Deno. Some things aren't perfect with Bun either like the lack of a Bun runtime on Vercel
- Ciantic 1y agoIt works surprisingly well when used in npm compatiblity mode, a lot like Bun is used. Running `deno install` in a directory with package.json will create a leaner version of node_modules, running `deno task something` will run scripts defined in `package.json`. Deno way of doing things is a bit problematic, as I too find it is often a timesink where things don't work, then if you have to escape back to node/npm it becomes a bigger hassle. Using Deno with package.json is easier.
- shepherdjerred 1y ago100%. I was all-in on Deno, but there were just too many sharp edges. In contrast, Bun just works.
- WorldMaker 1y agoYou picked a stack that is still very npm-centric, especially private npm packages. The sweet spot for doing things the Deno way still seems to be choosing stacks that themselves are very Deno and/or ESM-native. I've had some great experiences with Lume, for instance, and targeting things like Deno Deploy over Vercel. (JSR scores are very helpful at finding interesting libraries with great ESM support.) Obviously "start with a fresh stack" is a huge ask and not a great way to sell Deno, given how much time/effort investment exists in stacks like Next.js. But I think in terms of "What does Deno do best?" there's a sweet spot where you 0-60 everything in Deno-native/ESM-native tools. Also, yeah, a lot of Deno's npm compatibility keeps getting better, as mentioned in these 2.4 release notes there are a few new improvements. As another comment in these threads points out, for a full stack like the one you were trying, using Deno package.json first can give a better compatibility feeling than deno.json first, even if the deno.json first approach is the nicer/cleaner one long term or when you can go 0-60 in Deno-native/ESM-native greenfields.
- impulser_ 1y agoSurprised they went with esbuild for bundling instead of Rust based Rolldown which in about to be v1.
- jitl 1y agoesbuild is very stable and mature at this point, Rolldown is still rapidly evolving.
- drewbitt 1y agoThe LSP works quite a bit better than when I tried it a few months ago. It had memory issues back then. Thanks!