Exploring Deno Land 🦕
We talk with Ryan about the massive success of Node and how it impacted his life, and how he eventually created Deno and what he’s doing differently this time around. We also talk about The Deno Company and what’s in store for Deno Deploy.
Sign in or Join to comment or subscribe
I don’t like “one language apologists”, which you guys keep hosting uncritically on The Changeling” for some reason: “all dynamic languages are basically the same as V8 is the fastest VM in the world” (not a direct quote) so you should write all of your stuff on deno.
So here is and reason to the insanity:
And no - bash does not start a process for every line of code.
I would very much like to hear, someday, a developer that invested a lot into some language of framework, saying something like: “this is the tool I chose to use, it is great and here are all the ways it is great, but I recognize there are some usecases for which it isn’t the greatest”
Ultimately, I really don’t care from where I import my scripts. As Ryan agrees, if you really want to trust a source, you have to audit the code. However, there is one substantial difference between importing from npm and the script tag on the one side, and an URL on the other side: subsource integrity.
Unless npm has been compromised, I can trust that a (potentially audited) version will be the same the next time I install it. The same is true when the script tag is used with the
integrityattribute. As far as I know, ESM imports don’t have an instrument for that. And we all know it’s easy to change a hosted script or its Git tag. So I see importing URLs as a step to simplify dependency management, but it’s not adding security to the system.