We bet big on deno with Windmill (OSS platform to turn scripts into internal UI and workflows) [1][2] and are extremely pleased. The language design choices and the performances/caching strategies are a perfect match for building a distributed workflow runtime at scale. However, the compatibility with npm was the most requested feature. Before the compatibility mode with npm was released, we were about to build a completely separate mode of execution based on node. This solves it very elegantly.
Also super excited about the lsp improvements. I believe we are the only project to have a webeditor that features lsp integration with deno in the web (to test, go on [3], New Script -> Next, it works really well). It's very pleasant to work with and make the webeditor experience match closely a local dev setup. We are super excited about the improvements and I am about to try tonight if we can have the inline hints work with monaco. As we are fully open-source, one can see how we are able to pull it off [4][5].
I'm an eager and early adopter of Deno. I however look forward to ecosystem improvements, and the interop with npm is helpful. I was working on a side project recently that was a simple CRUD app and I just ended up going with Express on Node after fighting with Oak on Deno for a few days. It was still in the way enough to slow down the rapid fire development process that happens when you're still figuring out an idea.
Yeah NH gives a warped lens on how ready these runtimes & frameworks are for real work.
Threads about Deno and Bun pop up almost weekly, yet in my experience they remain a long, LONG way from the stable (and admittedly stale) experience we have with Node and NPM
> Yeah NH gives a warped lens on how ready these runtimes & frameworks are for real work
I think it's more that HN is warping reality on how ready they are for real work. We are shaping what is going to happen next in tech, and how quickly, by being eager and ready to give things a try and, in a mix of above average skill and curiosity, being able to make it work at a fairly sophisticated level, despite its current shortcomings.
Npm packages already do too much, with package.json being used to run scripts that have permission to do nefarious tasks to relying on C libraries.
If I were to use Deno it would be with the understanding that I'd need to find dependencies that are generic and standard... Not expect everything from npm to work by default.
If I used either I'd specifically look for dependencies that are standard enough to not matter or
Hopefully it has changed, but when I was using Deno, there wasn’t a standard for TypeScript libraries that worked in both environments (due to Deno requiring file extensions on imports and tsc requiring no file extension on imports). There was a workaround using import maps, but it’s not tenable for large libraries.
I'm using deno (with oak) for a side project and it's great. I experimented with bun as well, but came back to deno because I got frustrated with bun's segfaulting (this was pretty early after their announcement).
From the little I've read about just-js, I'm not sure it's even trying to be a competitor with the others for their main use-cases
I think Deno has the strongest overall vision, and it's a vision I really want to see become the new default
Bun is compelling with its blistering pace and its ruthless dedication to performance, compatibility, and Just Works user experience. However, it's still very new and missing a lot of key features, and subjectively it just feels too "chaotic" for my tastes. They're designing it as they go, as fast as they can, but it feels like a wild ride. I'm not sure the creator even knows exactly where it'll end up, and in general it seems to prioritize "does everything you'd like it to right now" over "lay a new, better foundation for how the JS ecosystem works, unburdened by the historical baggage of Node"
Two very different mindsets; it'll be really interesting to see which one wins. Personally I'm rooting for Deno, but I think each of them is pushing the other one to be better.
What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node folk want to move away from CommonJS in general (even staying within the NPM ecosystem) & having multiple targets for modules you write has given that effort some good pushes.
A simple example of this in my mind is the node: prefix added to CommonJS functions in NodeJS. This has some perf/caching advantages, which may have been the main driver, but also introducing a protocol prefix to module strings happens to improve extensibility/flexibility/compat across the ecosystem - there are transpilers that change e.g. import to require() or vice-versa, so extra context in module strings is helpful there. Deno's npm: prefix has a similar effect (it would be cool if this made it into Node someday - having control over module locator strategy at import granularity seems interesting; it would certainly make a lot of bundler hacks currently in use for things like CSS/etc. simpler)
I see NPM compatibility as a temporary stopgap. They tried to make a hard break all at once, and then Bun made it clear that no, actually people still really want access to that existing ecosystem for now.
But new code written for Deno starts out on that better foundation without CommonJS, several different module-resolution algorithms, manual transpilation, competing linting and testing standards, etc etc. They just need to bridge the gap in the meantime, until Deno's own ecosystem gets more filled out. That's the dream anyway.
The pedigree of Deno does speak for at least something as well. Who better to address the flaws of a lasting project someone created than the creator themselves? Just from incentive alignment it’s a powerful motivator.
Bun seems most promising to me, because it's chasing amazing performance _and_ widespread adoption.
Like Just-JS has amazing performance [1], but the author is "just" (a very amazing/talented) benchmark hacker and not necessarily trying/wanting to put in the effort to have "a node replacement" and/or extend his Techempower-specific optimizations into APIs/libraries that would affect the performance day-to-day business apps (which I don't blame him for).
Deno is kinda :shrug: b/c its original "great security" pitch doesn't really matter to anyone who runs in containers.
As a quick note, while containers offer a degree of isolation, depending on your use case you might not want to put too many eggs into that basket (Linux privilege escalation bugs do happen). E.g. Firecracker VM is a relatively easy improvement to make of course, and on cloud env the container isolation might be Amazon’s/Microsoft’s problem. Just figured it would be good to mention not to see containers as a silver bullet, while they are better than not using containers on a shared host (and a useful tool in general :-)
My guess is none of them will ever replace Node.js, but they will all help shift the momentum of Node.js to be faster, better support for Typescript, etc. Similar to how folks created io.js at one point and that eventually got merged back into Node.js.
Deno seems like to offer a better dev experience, and because it's created by Dahl it's the only one I take seriously as an alternative.
imo just-js and bun are too early to tell. They're in that stage where they're cool and people talk about them, but they haven't gotten to that stage where there's adoption and therefore real criticism. Basically bun/just-js are being judged on their potential, while Deno is starting to be judged on its reality.
I think they all serve different use cases. I'm not sure I could say one is more promising than another, because they're _all_ promising, and I don't see them as being in direct competition with each other.
I'd say deno, because they've already established a proper ecosystem since day one, has a working usage such as Deno Deploy[0] and Fresh[1], and already addresses some issues about distribution issue on Node, while bun still acts like a replacement for Node.
I have nothing bad to say about the other two but Deno is pretty great, I'm hoping it topples node.js at least, it seems poised to do so. Really lookin forward to playing with deno deploy too.
Better IDE support is huge. I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up, so this effectively removes a big barrier to adoption for a lot of folks.
Excited to see how well Deno's security features pan out under broader, real-world usage.
The ability to infer types from NPM packages. If you have existing codebases with non-trivial apps, reworking all your dependencies makes the prospect of picking up Deno a non-starter.
My understanding is prior to this release the Deno LSP didn’t have visibility into types from packages originating from NPM.
Compatibility issues likely still exist, but I suspect the scope of work for an MVP substitution of Node for Deno is in the realm of possibility now when it wasn’t before.
Deno has its own language server, unfortunately. This is necessary because of a few key aspects of Deno code that are incompatible with the regular TypeScript support, and it means Deno's editor integration is often a step behind mainline TypeScript
It did still partially work but there was some friction with resolving types from ESM modules. For example in typescript+node if you're importing another module with esm you'd still have to import javascript like so:
```
import { Example } from "./example.js" // the actual file is example.ts
```
While in Deno you actually import the typescript file
```
import { Example } from "./example.ts"
```
That difference alone was enough to trip up the built-in typescript language tool and add friction.
Another thing is that Deno has a built in formatter / linter, you don't use a 3rd party tool like eslint, so having the ide just know how to do the linting and formatting is nice, the default typescript language plugin can't do that.
Also, Deno formats other file types including json, yaml and markdown.
As a side note, this comment in itself is interesting. We are seeing tighter integration between frameworks and IDEs, almost a reversion back to early visual studio days. Will be interesting to see how each nudge the other.
The coupling here is actually extremely loose. It's based around implementing an LSP server, which is editor/IDE agnostic. It trades depth of integration for breadth of support. I think it's the total opposite of the old days!
Excited for the improvements, some big wins there!
But surprised to see so many removals in the Changes section to what seems to be a minor version of a 1.x release. Nothing that hurts me personally, altho not Semantic Versioning and cautions shaky ground to build on?
Thanks for clarifying, could be perhaps more evident in the changelog.
I know Node had this idea of unstable APIs, but in practice it's hard to enforce of course, if you're building a software & gotta rely on them.
Maybe this is a weird question, but how does Deno compare to Node when it comes to the various "languages that compile to JS"? For example Purescript, Fable, Elm, etc. does everything mostly just work, or should one stick to Node for those?
For languages that can emit clean ESM JavaScript source and don't depend on special tooling or runtime support you can totally drop the generated JS files into a Deno project and import them.
...but you're even _more_ on your own w.r.t. bugs, compatibility issues, and the basic assumption that everything will be running inside Node, and therefore trivially able to access e.g. `npx` or various scripting+automation tools.
Your best bet today is to run Node in your development environment, then use the generated code in a Deno service/CLI wrapper/etc. It's clunky, but you can get there.
Things mostly just work. Remember Node.js is mostly APIs on top of JS the language. If those tools compile to JS in the browser, they can compile to Deno. Deno is a more stabdards-based runtime than Node, it's closer to how the browser works.
Appreciate the improvements to npm compatibility. Does anyone have a sense of how close Deno is their estimate that 80-90% of npm packages would be working? I think they said this was what they were hoping for back in August.
> RBTree has been removed from the collections module in favor of RedBlackTree.
> direction has been removed from the collections module in favor of Direction.
> CSVStream has been removed from the encoding module in favor of CsvStream
Hmm I smell an interesting story here. If it's renaming for the sake of renaming then that's kinda dumb and breaks backwards compat for no reason, but presumably there's a better reason somewhere?
At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are.
The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted.
I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime would be if the standard module was depending on runtime APIs that have a breaking change.
std library is still considered "unstable" and the sub modules contained in there tend to have their own lifecycle as well. There has been effort to try to mature std to get to a stable version, which means cleaning up lots of things that would detract from long term maintainability.
Our editor integration is completely editor agnostic. Deno implements the Language Server Protocol [1], which essentially all editors support. Because of this the new inlay hints feature, is supported on all editors that support inlay hints and use our LSP integration. The Jetbrains integration for Deno uses our LSP, but I don't know if they support inlay hints yet.
VSCode is the only integration that the Deno core team maintains and develops. A rough poll indicates that about 80% of Deno users use vscode.
JetBrains/WebStorm now utilises the Deno language server directly (the same one that the VSCode integration uses) but they control how features are expressed in their client and when they deliver them, something the core team can't directly control.
So for various reasons, VSCode ends up being the focus.
I'm curious how strongly Deno matters to the developers in this space. Honestly, I just don't care. I really, really don't care. When Node.js succeeded PHP in industrial practice, it was enough then to get me to move since everyone had already jumped onboard quickly.
Now, it's gotta take a LOT for me to want to move. I'm already too productive with Linux, Nginx, MySQL, and Node.js w/ Express, and React on the front-end. I have little to no reason to try anything out.
On a similar note, while people are switching from Webpack to Turbopack, I'm kicking back writing actual product features with a near buildless process. Because I simply don't care. I use the "Run JSX Preprocessor" straight out of the docs as I work and commit the output.
Screwing around with switching back and forth and changing build configurations every few years reminds me of when back in the day people would supercustomize their desktop environments instead of just accepting them as they are.
Is anyone really working up a sweat over security theatre like passing in args to flip permissions flags?
Could you imagine how ridiculous that would sound in literally any other programming environment? That you can't trust your own software and its dependencies--that YOU built?
I get what you're saying. For me too everything is about developer experience, stability and business value. Rewriting to Deno will be a massive time sink with the lack of npm support and the small community compared to Node.js. Still, I applaud the effort to take JavaScript/TypeScript on V8 to the next level.
Also super excited about the lsp improvements. I believe we are the only project to have a webeditor that features lsp integration with deno in the web (to test, go on [3], New Script -> Next, it works really well). It's very pleasant to work with and make the webeditor experience match closely a local dev setup. We are super excited about the improvements and I am about to try tonight if we can have the inline hints work with monaco. As we are fully open-source, one can see how we are able to pull it off [4][5].
[1]: https://windmill.dev
[2]: https://github.com/windmill-labs/windmill
[3]: https://app.windmill.dev
[4]: https://github.com/windmill-labs/windmill/blob/main/frontend...
[5]: https://github.com/windmill-labs/windmill/blob/main/lsp/pyls...