[kibleopard]

The issue with Deno, personally, is that it feels like it doesn’t deviate enough from NodeJS to even make it worth taking the time to learn/migrate projects over to it. From what I recall, the only really new and nice features are: a) sandboxed by default b) no need for a node_modules folder since you can directly import from a URL

And is that really worth dumping loads of money into developing further? I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.

[cloverich]

The standard library will be a killer feature. Even for people that know the existing ecosystem (as I do), as more libraries fall out of fashion or become abandoned, and people have to pick up (several) new libraries from scratch for basic tasks, they'll realize (as I did) its not actually any different than just using Deno. I don't know if that will be enough, but that's one of the angle's I'm watching closely now. I'm partly biased because I like playing with streams, and those can be a nightmare in Node.

[cdaringe]

Hard pass. There are globs of features and design changes that make it worth the switch immediately if your use context can allow for it. I've now done a handful of apps and libraries in it, and given the option, I'd never look back to node. I don't say that lately. Node's was the best. These new designs are more than marginally overcoming the shortcomings of node. The motivation for migration is strong, and if best proven through experimenting. If you are TS saavy, do yourself a favor and try it out.

[fendy3002]

> I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.

It depends on migration effort. Take typescript for example, it's very similar with JS that migrate the codebase is not that painful. If the standard library and package manager can prove to highly useful, we'll see two possible scenario that aren't mutually exclusive:

1. People migrating to Deno

2. Newer nodejs version follow what Deno has

In the end it's good for us

[leodriesch]

I think the biggest missing piece right now are the big libraries: Webpack, Babel, Next.js, ESLint (maybe this will no be needed with `deno lint`), NestJS. Stuff like that. I'd think it's hard right now to spin up a project that you would've usually used these frameworks for without writing a lot of infrastructure code yourself.

[adkadskhj]

I feel like sandboxing could be huge, but WASM might be cutting the legs out from that feature.

Sandboxing doesn't sound so unique or innovative when WASM is coming along and doing the same thing, and with a much wider audience and thus more likely to have massive traction.

[afiori]

They compete on different use cases, most js/ts apps cannot be (reasonably) compiled to wasm and also wasm sandbox doesn't limit what the environment can do.

As a glaring strawman if you expose eval to wasm it will not help you.

Deno's sandbox will allow you to crate a dedicated worker with no network/disk access to handle sensitive informations, or to force your application to use a specific worker as a proxy (by making it the only thing with network acess)

[clarle]

I think sandboxed by default can make a lot of sense for the large companies that can potentially suffer heavy losses if an unauthorized attacker got into the file system.

The other feature is TypeScript as a first class citizen which is pretty great for devs.