Not sure that “CDNs aren’t supposed to go down” is a very reassuring point, nor one that Deno’s authors would make in its defence.
Deno’s vendoring approach isn’t like a stopgap in case third party servers go down. It’s the ’right’ way in Deno, and is another brilliant fix to Node’s approach.
Node always makes you go through a formal step to install a dependency - and then you’re still reliant on npm’s CDN being online during your builds anyway. The only way to break that build time dependency is to use a clunky, nonstandard hack to check in your node_modules, like yarn 2.0 or pnpm, which then takes you right off Node’s “golden path” (such as it is) and creates loads of incompatibilities.
Deno’s approach is the best of both worlds.
1. With Deno you can import direct from a URL with no formal install step, which is great for prototyping. The caching engine makes it fast without a need for every little toy project to have to have a giant node_modules folder.
2. Vendoring your scripts provides a dead easy, golden-path way to make your project completely non-dependent on third party during build, ie gives you same advantage as using Yarn 2 or pnpm in Node, but as a first class citizen of the runtime, so it’s efficient and standardised and will therefore not have tons of ecosystem incompatibilities.