I was interested in Deno from the start. It has a few very nice features. Notably the sandboxing model, native Typescript support and browser based API surface.
But I also was quite skeptical of their dependency model with plain url imports.
With the current implementation you end up with a half-baked import map that's essentially a poor mans package.json, but without any of the tooling that you'd expect. (like npm upgrade, npm outdated)
It recently dawned on me what they are going for: a "cloud native" computing platform that doesn't require builds and packaging. Targeting both Javascript and WASM.
I do believe there is quite a lot of promise in the project. The tooling can improve. It'll be interesting how things evolve.
I didn’t know what deno was.
It’s a typescript native alternative to nodejs that adopts the browser security model, replicates the golang standard library rather than node’s and is written in Rust.
Here's our token-based (JWT) user management server using Deno - if you want to see an example.
I'm still waiting for abortable fetch feature, since I have to deal with some services that have unstable network connection and often got stuck and never drop their connection.
Is there any progress over this one? Last time I heard, they still have to wait till rusty_v8 got matured enough for this feature to be available.
The addition of sandboxed storage (i.e. access to localStorage and sessionStorage APIs without requiring disk permission) is really interesting.
It seems very in line with the model of deno as an edge compute runtime - esentially ephemeral cache on the edge - I wonder what usecases will emerge for this?
I like the ideas behind Deno, but I'm wondering if testing should be so included in the standard library, unless it is extremely flexible.
Each team will have different problems when it comes to scaling, running tests in parallel - sometimes on the same machine, sometimes on multiple machines, e2e tests vs unit-tests, etc. This looks like a problem you solve in a library, not something to add in the core.
How is the built in testing? I'm a bit wary because Jest is so good and wonder if it can compete on every front it's baking in.
It reminds me of Angular coming with it's own Router, Forms, Animations and then since they're provided officially, alternatives don't get created and then the half of the team leaves and the packages are abandoned.
Great to see Deno going from good to better and better steadily over the past year. It is such a pleasure when compared with Nodejs projects. Always appreciate products that make life easier.
Node is amazing, but it was Electron that really made Node something that every school kid had to learn.
As long as Electron has no plans to support Deno, it will be WAY behind in traction.
/useless prediction
What's the status of grpc both as client and server? I seem to recall reading somewhere that some features(trailing headers?) needed to call grpc as client were out of the fetch spec and thus would to be implemented. It's also not clear from this issue either. https://github.com/denoland/deno/issues/3326
I have been following the progress of Deno for a little bit, and slowly but surely the project is evolving from a full-scale Node.js replacement to a serverless/edge compute platform. I get that it's the hot thing in tech these days, but to me that just isn't very appealing.
Has Deno failed to get adoption? I haven't seen it used anywhere to be honest.
Demo is awesome but ironically I haven't been able to use it because I always want something from npm
SemVer != Decimal
Somehow, Deno doesn't excite me.
I love to explore new stuff in programming. Have done with Python, Java, JS (Node), React, Angular, Vue, etc.
Deno just doesn't cut it.
Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.
It's Deno 1.10, not Deno 1.1.
As an old webdev who was full-stack before Node even came out, and avoided it completely, all I can say is; Have fun, kids! jingle jingle
Still not tempted by Deno to be honest.
All the problem that currently exist in Node are being ported to Deno straight up.
The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues.
Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of having 1000+ dependency from NPM you'll have 1000+ dependency from remote URL with everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process...
The way Ryan managed Node and how the ecosystem as turned to chaos because of is lack of vision and strategy make me not want to try any of it's tech again. Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly.
I don't think that's how you manage a language , when I look at Zig I'm way more confident of what's being done that the current state of Deno...
Node.JS is one of my main language , but the ecosystem around it is an absolute disaster.