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.
It might catch on, it might not. Not everyone has to like it.
I personally do like it a lot. I think of it as Node.JS with a better organized core (with the benefit of hindsight), use of browser APIs whenever possible, and built in Typescript. I think it might catch on once we have some mature MySQL, Express.js, etc libraries.
I know seeing popular tools be rewritten from scratch is tiresome, but I don't think it's unreasonable in this case given that Node.JS and Deno mostly get their JS implementation from a separate program: V8. In that sense, Deno isn't throwing all of Node.JS away. It's just a different attempt to make V8 a command line tool.
And of course, competition is good. Maybe Typescript will become more convenient in Node because of Deno.
Additionally: as someone who uses Linux in their day to day job, I think it's a phenomenal scripting tool and replacement / supplement for Perl / Python. I mentioned this in a comment here the other day, but with this short wrapper, you can execute a bunch of SSH commands simultaneously using the Promise.all JS function (familiar to web devs). Just an example of a cool thing you can do with Deno scripting. https://github.com/gpasq/deno-exec
> 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.
My problem with that statement is: if you knew him personally it's unlikely you'd have said it. And if you didn't, do you have enough samples to be sure he's 'that kind of guy'?
Are you comparing Deno to PHP? Should Deno have all the various database drivers baked in? SDKs to call out to Salesforce/Stripe/Zoom?
Should I pay a performance penalty for my app because you need to be able to read XML and make SOAP calls and want a tool that does that out of the box? Would you be happy to take a hit if the roles were flipped and I wanted Excel read/write?
I will not say Deno's perfect, I am still concerned/uneasy enough about how the whole dependency tree resolves for complex dependencies and is managed to not want to try it in production right now, but w.r.t to the ecosystem I'd say it's as good if not better than Node's, albeit smaller, given the focus on building a stdlib within this ecosystem for common usecases (http middleware, database drivers, common file formats etc)
> everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process...
the CLI args allow for tighter scoping that, and atleast the topic of sandox by default is being discussed and the painpoints/edge cases are coming to light, rather than the node/npm model of execute as user and done.
> 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 Deno you can already do a lot with only what is provided by the main executable. Here's a subset of the available subcommands:
bundle: Bundles JS. While it doesn't do everything that webpack does, it already provides enough to deploy SPAs.
coverage/test: Builtin test/coverage framework.
fmt/lint: Builtin lint/formatter.
IMO these provide basic tools that are likely necessary for any JS project, yet with Node.js you need a few hundred NPM deps to achieve the same functionality.
Not to mention the builtin Typescript compiler. Starting a few of years ago, I don't even consider the possibility of creating a Javascript project without using Typescript as the main language. With Deno you have it builtin.
I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies.
I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fit for a lot of people.
I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package.
It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world. I think it's half the reason things like jQuery, momentjs, lodoash and others exist, because people got frustrated with the lack of built-in functionality. npm has just made everything worse. Can't we have a .Net type framework for javascript? Minus the CLR and compilers of coarse, just the framework bits. Or if we need some kind of CLR type layer, why not build it with webassembly? Then all flavours of javascript can call into that? There has to be a clean way forward.
deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually)
regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low.
I know because I was there and I was making fun of maven and how it pulls half of the universe for a simple thing. Now nodejs is pulling the whole universe.
Yet the problem, in my opinion, is not package manager but rather "look I made a package, it does one small thing and it does it well and I dont want it to do more" which leads to many more packages because you really need that thing so what you are going to do? you will add a package on top of package. rinse and repeat and there we are
I am trying to expand my horizons from only node to other frameworks. I've seen so much hype around Deno so I looked into it the other day and I feel the same as you. It doesn't seem different enough from Node from a user standpoint. I also agree that the package system seems messy. For right now I'm going to steer clear and get out django and rails.
I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem.
Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since these libraries are smaller, it's easier to change one for another.
Because of that, community is much less likely to settle on one standard way of doing things just because of "how things are done here", and ecosystem continues to evolve and find better ways of writing code. Would any other language ecosystem that is widely used in production go from callbacks to different promise libraries, to standard promise api to async? I don't think so. (Edit: strike that, Rust seems to have done it too. Well, Rust is also awesome). Of course, it means that you have to learn more; but it also leads to things actually becoming better, and not because of some central mandate by language committee, but as a result of a more decentralised gradual evolution. (Not completely decentralised, just compared to alternatives).
In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase; in NPM, I've done meaningful contribution to a library less then an hour after learning about it's existence.
I can see why npm is annoying, but I wonder what would be a good role model for a better ecosystem. I can personally only compare npm to PHP, Python and Java, and I think npm is far superior. Do you have an example of a better ecosystem/package manager? I'm genuinely curious.
I use NodeJS daily, but I do agree some fundamental APIs are missing. For example, calling remote URLS is critical for most apps, yet Node only offers the "http" and "https" packages (and why different packages!). It should at least have "fetch" support and require installing the "node-fetch" dependency.
I'm glad Deno is here trying to push the ecosystem forward, at least with Typescript, and hopefully Node will learn from them.
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.
If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long run.
I can't stress how many times I had to review and undo automated dependency bumps because my app suddenly stopped working, and the times I was forced to I had to bump said dependencies in the lock file myself
In a compiled language, where code is compiled once and valid there 'til the end of times this is not even a problem. In an interpreted language where all code is evaluated every time you run your program, this makes automated dependency management an impossible task
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.
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.
I know a fella working on a Deno port of Ava (https://github.com/avajs/ava). When that and Koa are ported or compatible, I'll be giving Deno a legitimate go.
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.
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.
echopom|4 years ago
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.
hackerbrother|4 years ago
I personally do like it a lot. I think of it as Node.JS with a better organized core (with the benefit of hindsight), use of browser APIs whenever possible, and built in Typescript. I think it might catch on once we have some mature MySQL, Express.js, etc libraries.
I know seeing popular tools be rewritten from scratch is tiresome, but I don't think it's unreasonable in this case given that Node.JS and Deno mostly get their JS implementation from a separate program: V8. In that sense, Deno isn't throwing all of Node.JS away. It's just a different attempt to make V8 a command line tool.
And of course, competition is good. Maybe Typescript will become more convenient in Node because of Deno.
Additionally: as someone who uses Linux in their day to day job, I think it's a phenomenal scripting tool and replacement / supplement for Perl / Python. I mentioned this in a comment here the other day, but with this short wrapper, you can execute a bunch of SSH commands simultaneously using the Promise.all JS function (familiar to web devs). Just an example of a cool thing you can do with Deno scripting. https://github.com/gpasq/deno-exec
jeswin|4 years ago
My problem with that statement is: if you knew him personally it's unlikely you'd have said it. And if you didn't, do you have enough samples to be sure he's 'that kind of guy'?
Or are you extrapolating from N=1?
tehbeard|4 years ago
Are you comparing Deno to PHP? Should Deno have all the various database drivers baked in? SDKs to call out to Salesforce/Stripe/Zoom? Should I pay a performance penalty for my app because you need to be able to read XML and make SOAP calls and want a tool that does that out of the box? Would you be happy to take a hit if the roles were flipped and I wanted Excel read/write?
I will not say Deno's perfect, I am still concerned/uneasy enough about how the whole dependency tree resolves for complex dependencies and is managed to not want to try it in production right now, but w.r.t to the ecosystem I'd say it's as good if not better than Node's, albeit smaller, given the focus on building a stdlib within this ecosystem for common usecases (http middleware, database drivers, common file formats etc)
> everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process...
the CLI args allow for tighter scoping that, and atleast the topic of sandox by default is being discussed and the painpoints/edge cases are coming to light, rather than the node/npm model of execute as user and done.
tarruda|4 years ago
With Deno you can already do a lot with only what is provided by the main executable. Here's a subset of the available subcommands:
IMO these provide basic tools that are likely necessary for any JS project, yet with Node.js you need a few hundred NPM deps to achieve the same functionality.Not to mention the builtin Typescript compiler. Starting a few of years ago, I don't even consider the possibility of creating a Javascript project without using Typescript as the main language. With Deno you have it builtin.
ranguna|4 years ago
I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fit for a lot of people.
BatteryMountain|4 years ago
It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world. I think it's half the reason things like jQuery, momentjs, lodoash and others exist, because people got frustrated with the lack of built-in functionality. npm has just made everything worse. Can't we have a .Net type framework for javascript? Minus the CLR and compilers of coarse, just the framework bits. Or if we need some kind of CLR type layer, why not build it with webassembly? Then all flavours of javascript can call into that? There has to be a clean way forward.
kigiri|4 years ago
While not stable yet, they are working to address this very issue
Zig is looking great but also, solving a different problem
cztomsik|4 years ago
regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low.
I know because I was there and I was making fun of maven and how it pulls half of the universe for a simple thing. Now nodejs is pulling the whole universe.
Yet the problem, in my opinion, is not package manager but rather "look I made a package, it does one small thing and it does it well and I dont want it to do more" which leads to many more packages because you really need that thing so what you are going to do? you will add a package on top of package. rinse and repeat and there we are
mirekrusin|4 years ago
spamalot159|4 years ago
austincheney|4 years ago
What is an example of something you are hoping for?
m00dy|4 years ago
https://deno.services
golergka|4 years ago
I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem.
Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since these libraries are smaller, it's easier to change one for another.
Because of that, community is much less likely to settle on one standard way of doing things just because of "how things are done here", and ecosystem continues to evolve and find better ways of writing code. Would any other language ecosystem that is widely used in production go from callbacks to different promise libraries, to standard promise api to async? I don't think so. (Edit: strike that, Rust seems to have done it too. Well, Rust is also awesome). Of course, it means that you have to learn more; but it also leads to things actually becoming better, and not because of some central mandate by language committee, but as a result of a more decentralised gradual evolution. (Not completely decentralised, just compared to alternatives).
In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase; in NPM, I've done meaningful contribution to a library less then an hour after learning about it's existence.
Jean-Philipe|4 years ago
gbourne|4 years ago
I'm glad Deno is here trying to push the ecosystem forward, at least with Typescript, and hopefully Node will learn from them.
intrasight|4 years ago
the_duke|4 years ago
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.
Soremwar|4 years ago
If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long run.
I can't stress how many times I had to review and undo automated dependency bumps because my app suddenly stopped working, and the times I was forced to I had to bump said dependencies in the lock file myself
In a compiled language, where code is compiled once and valid there 'til the end of times this is not even a problem. In an interpreted language where all code is evaluated every time you run your program, this makes automated dependency management an impossible task
CraigJPerry|4 years ago
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.
adamsvystun|4 years ago
otabdeveloper4|4 years ago
okhuman|4 years ago
https://github.com/pmprosociety/authcompanion
8K832d7tNmiQ|4 years ago
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.
lucacasonato|4 years ago
e12e|4 years ago
davnicwil|4 years ago
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?
redleader55|4 years ago
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.
Soremwar|4 years ago
The current multi threaded and module isolated model however I think it's good for the great majority of projects, so I'm glad it's built in
uhhhhhhhhhhhhhh|4 years ago
[deleted]
intellix|4 years ago
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.
azangru|4 years ago
Much more minimalist than Jest. Very similar to Node's built-in testing [0].
- I don't believe the test environment is recreated between test files
- No way to mock imported modules, as far as I understand. I don't believe the built-in testing has any mocking or spying functionality at all
- No describe/it/expect syntax that Jest inherited from Jasmine (I am not sure where it came from initially — was it from RSpec?)
- The above means that there is no nesting of test blocks
- No setup or teardown functions (beforeAll, beforeEach, afterAll or afterEach)
On the other hand, it's fast. And it doesn't swallow up console logs, like Jest can do. No magic to it at all.
[0] - https://nodejs.org/dist/latest-v14.x/docs/api/assert.html
andrew_|4 years ago
jimmont|4 years ago
sam_goody|4 years ago
As long as Electron has no plans to support Deno, it will be WAY behind in traction.
/useless prediction
Soremwar|4 years ago
ledgerdev|4 years ago
unknown|4 years ago
[deleted]
paxys|4 years ago
unknown|4 years ago
[deleted]
unknown|4 years ago
[deleted]
Graffur|4 years ago
yepthatsreality|4 years ago
ralusek|4 years ago
ecmascript|4 years ago
domano|4 years ago
kumarvvr|4 years ago
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.
caspervonb|4 years ago
Macha|4 years ago
tarruda|4 years ago
whalesalad|4 years ago
dang|4 years ago
sanxiyn|4 years ago
dang|4 years ago
DrFell|4 years ago