I feel like I’m the only person in the world who disagrees with this sentiment: “Node.js is still based on callbacks, while there are far better ways to deal with asynchronicity in modern JavaScript”.
I love callbacks. The entire world went all promises and async/await but I find callbacks to be far more explicit and manageable.
I’m also an old codger who will stay on ES5 forever. All the new syntax just doesnt feel like the javascript I grew up with :)
That is because you are comparing it with promises.
Naturally, blocking IO calls are trivially understood by anyone that looks at them. And they solve a zillion intricate problems which arise from letting the concurrency of a web server to leak to programmer implementing request handling.
This is obviously a bad idea and resulted in a decade of discussions where none is need.
It’s kind of ironic that what is essentially a server backend leaves to the programmer the responsibility of not completely freeze the whole server, indeed countless times happening by accident and still get a hip reputation While PHP with all its warts has solved this problem by design to the point that most of its users are not even aware of it, and is regarded as a an amateurish toy.
Sorry for my ignorance, but is there the intention to support version-based dependency resolution with deno, or will all dependencies just be duplicated?
Eg. if I import two libraries, one uses http://somewhere/underscore/1.1.0/index.js, and the other http://somewhere/underscore/1.2.0/index.js, but both libraries only actually require 1.0.0 < underscore < 2.0.0, will always two copies of underscore be downloaded?
If the answer is yes, this might push people culturally to smaller dependency trees, which may be no bad thing. (As an aside: I suspect the “you can only install one copy of a dependency at once” in python - despite being a technical limitation - has contributed to API stability in libraries).
A slight re-wording of the title: “Does this mean goodbye to a technology that is incredibly widespread and is one of the most popular web development languages in existence?”
I believe the modules get cached locally. You wouldn’t be able to get uncached modules, but you can’t install from a package manager either.
EDIT: relevant quote
When the application is executed for the first time, Deno downloads and caches all modules in a global cache. It is possible to store them in a custom directory using the $DENO_DIR environment variable.
If you import a version of the same module in like 10 different files, e.g. writing this in each file:
import * as log from "https://deno.land/std@0.75.0/log/mod.ts";
And then want to bump the version from say 0.75.0 -> 1.0.0, does this mean you have to bump it in each file…?
Anyone else feel like punting on dependency management is a fatal flaw in Deno’s design? I realize npm is flawed, but to just give up and use URLs for everything seems regrettable. How are developers to know when dependencies need updating? Doesn’t the decentralization of dependencies increase the surface area for attacks?
How are developers to know when dependencies need updating?
If only there were a URL you could check for updates.
Doesn’t the decentralization of dependencies increase the surface area for attacks?
At a network level, yes. Personally I recommend storing your dependencies yourself regardless; having them in-repo means you have the same review workflow for third party code, which IMO is worth doing most of the time.
I didn’t realize Deno had set up an official registry for third party modules. I suppose sarcasm is one way to get me to do my homework.
Back in May when 1.0 was announced, I heard an interview with Kit Kelly. He basically implied there was no registry; dependency management was just URLs; and if that bugged people, they could find stuff on pika.dev, which at the time was just npm under the hood. That just seemed like madness. If I’d kept listening, I would have caught the bit where he talked about deno.land/x.
I’m curious to know what the plan is for warning users of third party modules about vulnerabilities or attacks that are discovered after the modules have already been registered.
I didn’t realize Deno had set up an official registry for third party modules. I suppose sarcasm is one way to get me to do my homework.
Oh cool! I’m really glad you pointed that out, because I was only referring to the import URL - if I’m importing ‘github.com/foo/bar’ I have a pretty good idea where to look for new versions. Having a registry is much nicer.
Deno is great! It solves a lot of problems I have with node. However, it’s very young. It’s nowhere near “goodbye node” level.
I feel like I’m the only person in the world who disagrees with this sentiment: “Node.js is still based on callbacks, while there are far better ways to deal with asynchronicity in modern JavaScript”.
I love callbacks. The entire world went all promises and async/await but I find callbacks to be far more explicit and manageable.
I’m also an old codger who will stay on ES5 forever. All the new syntax just doesnt feel like the javascript I grew up with :)
That is because you are comparing it with promises.
Naturally, blocking IO calls are trivially understood by anyone that looks at them. And they solve a zillion intricate problems which arise from letting the concurrency of a web server to leak to programmer implementing request handling. This is obviously a bad idea and resulted in a decade of discussions where none is need.
It’s kind of ironic that what is essentially a server backend leaves to the programmer the responsibility of not completely freeze the whole server, indeed countless times happening by accident and still get a hip reputation While PHP with all its warts has solved this problem by design to the point that most of its users are not even aware of it, and is regarded as a an amateurish toy.
Betteridge’s law says “no”, but I’m certain somebody out there is making the switch.
Sorry for my ignorance, but is there the intention to support version-based dependency resolution with deno, or will all dependencies just be duplicated?
Eg. if I import two libraries, one uses
http://somewhere/underscore/1.1.0/index.js, and the otherhttp://somewhere/underscore/1.2.0/index.js, but both libraries only actually require1.0.0 < underscore < 2.0.0, will always two copies of underscore be downloaded?If the answer is yes, this might push people culturally to smaller dependency trees, which may be no bad thing. (As an aside: I suspect the “you can only install one copy of a dependency at once” in python - despite being a technical limitation - has contributed to API stability in libraries).
A slight re-wording of the title: “Does this mean goodbye to a technology that is incredibly widespread and is one of the most popular web development languages in existence?”
to which the answer is, quite obviously: No.
What bugs me about Deno is the module/import system. How do you work offline?
I believe the modules get cached locally. You wouldn’t be able to get uncached modules, but you can’t install from a package manager either.
EDIT: relevant quote
If you import a version of the same module in like 10 different files, e.g. writing this in each file:
import * as log from "https://deno.land/std@0.75.0/log/mod.ts";And then want to bump the version from say
0.75.0->1.0.0, does this mean you have to bump it in each file…?The deno manual recommends re-exporting dependencies in a “deps.ts” file.
Thanks – I hadn’t gotten that far yet / spoke too soon :).
Anyone else feel like punting on dependency management is a fatal flaw in Deno’s design? I realize npm is flawed, but to just give up and use URLs for everything seems regrettable. How are developers to know when dependencies need updating? Doesn’t the decentralization of dependencies increase the surface area for attacks?
If only there were a URL you could check for updates.
At a network level, yes. Personally I recommend storing your dependencies yourself regardless; having them in-repo means you have the same review workflow for third party code, which IMO is worth doing most of the time.
I didn’t realize Deno had set up an official registry for third party modules. I suppose sarcasm is one way to get me to do my homework.
Back in May when 1.0 was announced, I heard an interview with Kit Kelly. He basically implied there was no registry; dependency management was just URLs; and if that bugged people, they could find stuff on pika.dev, which at the time was just npm under the hood. That just seemed like madness. If I’d kept listening, I would have caught the bit where he talked about deno.land/x.
I’m curious to know what the plan is for warning users of third party modules about vulnerabilities or attacks that are discovered after the modules have already been registered.
Oh cool! I’m really glad you pointed that out, because I was only referring to the import URL - if I’m importing ‘github.com/foo/bar’ I have a pretty good idea where to look for new versions. Having a registry is much nicer.