3 ms·
This argument is so interesting, essentially it's "there is no other Deno, so you don't have to worry about using a slightly incompatible implementation and get
by camgunz 4y ago
This argument is so interesting, essentially it's "there is no other Deno, so you don't have to worry about using a slightly incompatible implementation and getting bugs".
But a lot of people think that multiple implementations and specs are good things (I personally don't know which way I go on this one). And thinking about it, I kind of don't buy the argument. There are specs for JavaScript and TypeScript, and multiple standalone JS and TS engines: node, QuickJS, duckjs, Bun, etc.
I also don't buy the "minimal, practical" take on dependency management. It sounds like they just built a package manager into Deno itself and put versions in the URL, which feels like the opposite of minimal and more like "batteries included". Again not saying this is bad--the Python ecosystem suffers pretty badly from not having their dependency story totally mapped out--just quibbling over the characterization.
On the other hand, I do buy the security thing. AFAIK this is the first scripting runtime to essentially integrate pledge [0], which is real interesting.
[0]: https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- andyferris 4y agoMy take is that Deno borrows a lot from web standards and functionality provided accross browsers. In the case of dependency management, they use a pattern which would also work for client code shipped to a web browser (in that case the client would assemble the code - like if you had a reference to load mathjax or google analytics or whatever, or you could alternatively vendor and ship them yourself). To me Deno is basically modern web standards + very nice tooling for use as a scripting or serverside language (typescript interpretter, format, compile, vendor, test, lockfiles/import maps, ability to explicitly include/exclude capabilties from runtime, etc).