Even if this new thing has slightly nicer syntax or usage of promises or whatever, does this alone justify it's existence? Learning all this new tooling and ecosystem all over again? Dividing the web development ecosystem even more?
I really don't see how the problem it's solving is big enough for us to care really. I mean - enough already. In 8 years I'm sure Ryan Dahl can come up with an even better runtime written in Grust, will we then all be migrating our codebases from Node -> Deno -> Dynamite?
Deno 1.0
461–470 of 598 posts
Re: Deno 1.0
#462The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I…
Why can't you download all the packages you use actually with your source code? That's how software has been built for decades... I'm a desktop developer so I understand I'm the dinosaur in the room but I've never understood why you would not cache all the component packages next to your own source code. Since this is straighforward to do I presume there is some tradeoff I've not thought about. Is it security? Do you…
You can commit your node_modules folder into your repository if you'd like.
Re: Deno 1.0
#463This project looks really cool to me.
I'm glad the link to the video is there, because my intuition about pronouncing the name was incorrect.
It looks like it could be "deeno" OR "denno", and I was pushed to the former by the presence of the dinosaur graphic. Isn't that old fashioned dinosaur on the Flinstones pronounced deeno? Anywho... good name overall: short, no collisions (i think?), and no strong baseline associations.
And only right this instant am I realizing that this is an anagram of node... oh my god i'm slow. Now it's a great name.
Re: Deno 1.0
#464I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly. Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.
The GoLang-like URL import and dependency management are indeed an innovation in simplicity while simultaneously offering better compatibility with browser JavaScript.
Perhaps the HN-hate is not about simplified greenfield tech as much as it is about breaking established brownfield processes and modules.
Re: Deno 1.0
#465Earlier quoted context omitted.
>Can checksums/hashes be specified directly in the source file? That would defeat their point actually :D malicious attacker could inject any script by hacking on the network and replace modules that are downloaded through http
How? Say I have `script.ts`. That file exists locally on my computer and the code inside it is trusted (say it was downloaded from a trusted github project via https). It contains import { dependency } from 'http://whatever.url/@1.0.3' with hash '6f09aa686a6263f9e992' or something like that. If an attacker replaces stuff during transfer of the dependency, then the hash won't match (assuming a collision resistant hash…
there are a lot of issues with using a non secure protocol to do anything over the internet, actually someone summarized the issue on the Deno issue tracker.
According to them, confidentiality is also a risk. also someone could also send you garbage that would polute the memory of deno until it explode.
Re: Deno 1.0
#466Earlier quoted context omitted.
Arguably you can get (even more reliable) version pinning by copying typescript from that random URL & storing it in your own S3 bucket. Sure, you have _some_ work to do, but it's not that much and you 100% control the code from there on.
Well, I suppose they do (or will) provide a self hosted version of the registry. Like npm does.
If you publish your module versions on IPFS that would provide a guarantee to your users the module versions do not change once published. But hashes are not very memorable as module names.
Re: Deno 1.0
#467Earlier quoted context omitted.
> That combined with the 'download random code from any url What protection does NPM actually give you? Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable ins…
> What protection does NPM actually give you? Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well. I think this could be fixed quite easily if one could a…
I was curious about this so I looked into it. Seems like deno allows for lock files (similar to package-lock.json for NPM) https://deno.land/manual/linking_to_external_code/integrity_...
Re: Deno 1.0
#468Number of things come to mind: - How do you update dependencies? They are urls spread along many files which can be everywhere... Do I have to find and replace every import statement? - In some enterprise environments, we use mirroring of package distributors (Nexus, jfrog etc.). This give us the ability to audit what packages are being imported, create a cache of packages so that a single delete or unpublish (like g…
A lot of comments here can be answered by reading the documentation.
Re: Deno 1.0
#469Earlier quoted context omitted.
Deno really shouldn't run TypeScript files directly. Not only is TypeScript too slow for this, it receives far too many breaking changes. How will Deno decide when to upgrade its TypeScript compiler version? Will Deno have to have breaking changes every three months or so? Also, Deno appears to allow import TypeScript files with .ts extensions while tsc doesn't. This alone means the same code won't run in Deno and co…
I’m a huge TS fan and I agree. Deno is just running tsc for me it seems. So far I don’t see much advantage. It also potentially ties Deno to current trends. TS is pretty dang popular, but what if something else comes along and scoops it?
Note that Deno started out as Typescript runtime, it was it's tagline, they added the JavaScript later there.
> TS is pretty dang popular, but what if something else comes along and scoops it?
Earth is rather small, type inferencing dynamic language is really hard. There is simply no other language or team that has achived anything like TS. It's very unlikely that anyone else will do it for JS again. You can just look at amount of work in TS already.
Only thing that can "scoop it" is another language entirely taking off and leaving JS developers in the history. In that case the point becomes useless, it can happen to any runtime for any given language.
Re: Deno 1.0
#470> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…
See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…
I don't think thats very accurate.
You really need to gi watch the first Deno video made by Ryan Dahl at JSConf.