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'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.