I'm afraid I'm missing something:
Deno doesn't have npm, right? So if I want a third party library, I have to go find it, grab the url, download it, and add it manually? Or use a URL, and if URL changes, I have to do the same thing again from the start?
I just don't see much point in Deno at this point, it takes one of the biggest advantages of Node, throws it out the window and declares itself the winner... and I just don't get it. From what I've read the author is proud with the fact deno has smaller and more predictable latency (from receiving request to answering request) but... handles 2/3 of node's requests per second, so we lose 1/3 of the performance for a bit of latency, and that is, like, one of the biggest advantages.
As I said, I just don't get it. If anyone can explain what is Deno supposed to replace or what problem it wants to solve, I'd be very grateful. Thanks in advance!
Pika.dev, jspm, I believed someone will create something like npm later on, remember node didn't have npm from day one, like golang go mod, php composer, python pip, etc they are invented later on (even by third party developer)
I'm not a fan of all the bloat either, but it doesn't seem like we can change much, other than pulling all that code directly into our project and bloating the project files instead.
And then again, deno gets rid of bloated node modules folder how? By creating deno crates or something? My guess is it will be just as bloated very soon. It is a side effect from the ecosystem that relies on updateable plug-ins which use other plug-ins.
Where would the bloat come from? Managing dependencies is as easy as creating a single typescript file with all the imports and Deno does the rest. No need to deal with node_modules. Here is a github issue discussing your grievances
P.S. I'm not here to convert you to Deno xD, but if you dislike the idea of learning another technology in the already overwhelming web dev environment then I totally get where you are coming from.
It's actually CTCI + leetcode that take up all of my time. Including weekends.
I plan to devote some time to hobby projects down the line (including getting to know typescript, which seems to blend well with Deno), but it is not very high on my priority list at the moment.
So if I want a third party library, I have to go find it, grab the url, download it, and add it manually?
The download step is not required and I don't see how this is much different than the npm way of doing it... please eloborate.
Well if you prefer the npm and package.json way of managing modules, then yes Node will be more convenient for you - for now.
The main reason that the developers of Deno have given for the use of an import system via urls is "Furthermore the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web." (quoted from the v1 blogpost, I highly suggest the 15min read if you are struggling to see the point of deno). So essentially they are trying to avoid the whole central-source-of-trust-by-a-company thing that happened out of necessity in Node, because it was so hard to manage packages and are trying to make importing packages as easy as including javascript files in a webpage (This also means you don't have to manually install packages). After all, if you read the blogpost, the ambitions of deno are to be runtime environment like a web browser.
In my opinion the way Deno manages dependencies is also simpler and more elegant than Node, because if we compare the workflows:
Node: npm init to create project -> search for a package -> npm install it -> accidently push node_modules ^^
Deno: search for a package -> import via url -> done
I've read the blog post, I just disagree with this approach. When you have a centralized repository, you can have a more or less reliable source of information, like number of downloads and a place to search for modules. When every module is individual, without a centralized place to find them all, finding a module you want turns into an adventure with pirates, treasure hunts and fool's gold. Thanks but no thanks, in a corporate environment I want stuff that just works, period. I want to know popular repository that does exactly what I want, the way I want it to, I want it to be supported and updated and bring minimum extra dependencies. How can I know if any of this is true for a random url on the web without a centralized repository?
I prefer everything centralized which is shared in background for higher reliability and fault tolerance. In my personal opinion, npm is harder to compromise than random URL. But I may be wrong about it.
As for workflow: I initialize far too few repositories per day to make it matter. Once it is initialized, install work flow is easier for node - npm install, done. Most of the time the app is conteinerized and npm makes work flow simple. Making import statement from a fixed name is, IMO, also easier - you know for sure you are importing a validated package you installed through npm, a source you trust (I do, at least). Importing from url begs the question of audit, update (was the content replaced with a new version with breaking changes? Do I have to find the up to date version myself and manually update the link?).
This all seems counter-productive to me. Maybe deno is just not for me?
Then I would just wait for a third party module auditer/provider like npm to arise (You will most likely still simply import via a url from a trusted domain of theirs, though).
I mean, if you are trying to get things done, then yes Node is probably better for you, because you already know it. At the moment Deno is still a young technology and doesn't have the 10 years of testing behind it's name. As the devs said in the v1 blogpost
For some applications Deno may be a good choice today, for others not yet.
I would at least give it a try in a hobby project, though, but I assume you have already done that... anyway the choice of technology is yours :)
I'm afraid I'm missing something:
Deno doesn't have npm, right? So if I want a third party library, I have to go find it, grab the url, download it, and add it manually? Or use a URL, and if URL changes, I have to do the same thing again from the start?
I just don't see much point in Deno at this point, it takes one of the biggest advantages of Node, throws it out the window and declares itself the winner... and I just don't get it. From what I've read the author is proud with the fact deno has smaller and more predictable latency (from receiving request to answering request) but... handles 2/3 of node's requests per second, so we lose 1/3 of the performance for a bit of latency, and that is, like, one of the biggest advantages.
As I said, I just don't get it. If anyone can explain what is Deno supposed to replace or what problem it wants to solve, I'd be very grateful. Thanks in advance!
Pika.dev, jspm, I believed someone will create something like npm later on, remember node didn't have npm from day one, like golang go mod, php composer, python pip, etc they are invented later on (even by third party developer)
Anything that gets rid of the bloated node_modules folder is a win for me.
I'm not a fan of all the bloat either, but it doesn't seem like we can change much, other than pulling all that code directly into our project and bloating the project files instead.
And then again, deno gets rid of bloated node modules folder how? By creating deno crates or something? My guess is it will be just as bloated very soon. It is a side effect from the ecosystem that relies on updateable plug-ins which use other plug-ins.
Where would the bloat come from? Managing dependencies is as easy as creating a single typescript file with all the imports and Deno does the rest. No need to deal with node_modules. Here is a github issue discussing your grievances
This talks a lot about all the issues I have with deno way. Sadly, the discussion is simply closed without an answer.
How about this reply
P.S. I'm not here to convert you to Deno xD, but if you dislike the idea of learning another technology in the already overwhelming web dev environment then I totally get where you are coming from.
It's actually CTCI + leetcode that take up all of my time. Including weekends.
I plan to devote some time to hobby projects down the line (including getting to know typescript, which seems to blend well with Deno), but it is not very high on my priority list at the moment.
CTCI... oh boy.
I also have rather limited time atm, but if you want create something down the line with deno, let me know.
The download step is not required and I don't see how this is much different than the npm way of doing it... please eloborate.
Well if you prefer the npm and package.json way of managing modules, then yes Node will be more convenient for you - for now.
The main reason that the developers of Deno have given for the use of an import system via urls is "Furthermore the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web." (quoted from the v1 blogpost, I highly suggest the 15min read if you are struggling to see the point of deno). So essentially they are trying to avoid the whole central-source-of-trust-by-a-company thing that happened out of necessity in Node, because it was so hard to manage packages and are trying to make importing packages as easy as including javascript files in a webpage (This also means you don't have to manually install packages). After all, if you read the blogpost, the ambitions of deno are to be runtime environment like a web browser.
In my opinion the way Deno manages dependencies is also simpler and more elegant than Node, because if we compare the workflows:
Node: npm init to create project -> search for a package -> npm install it -> accidently push node_modules ^^
Deno: search for a package -> import via url -> done
But that is simply my opinion :)
I've read the blog post, I just disagree with this approach. When you have a centralized repository, you can have a more or less reliable source of information, like number of downloads and a place to search for modules. When every module is individual, without a centralized place to find them all, finding a module you want turns into an adventure with pirates, treasure hunts and fool's gold. Thanks but no thanks, in a corporate environment I want stuff that just works, period. I want to know popular repository that does exactly what I want, the way I want it to, I want it to be supported and updated and bring minimum extra dependencies. How can I know if any of this is true for a random url on the web without a centralized repository?
I prefer everything centralized which is shared in background for higher reliability and fault tolerance. In my personal opinion, npm is harder to compromise than random URL. But I may be wrong about it.
As for workflow: I initialize far too few repositories per day to make it matter. Once it is initialized, install work flow is easier for node - npm install, done. Most of the time the app is conteinerized and npm makes work flow simple. Making import statement from a fixed name is, IMO, also easier - you know for sure you are importing a validated package you installed through npm, a source you trust (I do, at least). Importing from url begs the question of audit, update (was the content replaced with a new version with breaking changes? Do I have to find the up to date version myself and manually update the link?).
This all seems counter-productive to me. Maybe deno is just not for me?
Then I would just wait for a third party module auditer/provider like npm to arise (You will most likely still simply import via a url from a trusted domain of theirs, though).
I mean, if you are trying to get things done, then yes Node is probably better for you, because you already know it. At the moment Deno is still a young technology and doesn't have the 10 years of testing behind it's name. As the devs said in the v1 blogpost
I would at least give it a try in a hobby project, though, but I assume you have already done that... anyway the choice of technology is yours :)
I plan to try it together with typescript, they seem like a good match. I'm sure I won't be needing a lot of libraries when just starting out with TS.