The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. <i>Especially</i> if policies could also be applied to node packages.<p>Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it library-specific. Or perhaps there are non-obvious blockers that make it too hard?<p>If there <i>are</i> plans to do this, isn't it better to do it sooner rather than later? Better to get library authors in the habit of specifying permissions/policies now while the ecosystem is still small. If you wait too long, it will be a ton of work to retrofit all the existing libs.
I haven't had the same success with Deno that I expected. At first, I was shocked by how good the tooling is, and I was super happy with its dependency management. All of the problems started once I started getting into actual business logic.<p>`redis` and `ioredis` `npm` packages don't work with Deno, even with the Node compat layer (I tried). So you have to use the Deno driver for Redis. But you look up the library for this, and it's experimental: <a href="https://deno.land/x/redis@v0.25.5" rel="nofollow">https://deno.land/x/redis@v0.25.5</a><p>Same deal with Postgres. `pg` would not compile at all. Knex also didn't work (this was an older project). I'm assuming this is because these two packages use native Node.js plugins.<p>I like Deno a lot, and the out of the box TypeScript support is a gamechanger, but I had a really tough time working with it and actually being productive.
In the security model section it doesn't mention workers. In Deno, workers can be given different permissions. The article suggests having different permissions per file. I think it might be nice to have both but if I could only have one I would want separate permissions per worker. Files aren't always split along the same lines that permissions should be split. I would like to be able to control permissions by url prefix though - so some library doesn't do more than I want it to. It might mean setting up a worker if I want to make sure it doesn't indirectly use more dependencies.
I hoped this article would provide more info than it actually did.<p>For me, a javascript developer that mainly use Node.js for work, Deno is interesting and I want to use it but the hosting part is what prohibits me from using it. In node it's easy to run production code with pm2, you can cluster it and it's super easy to configure it so that it will run one node process per available core.<p>With Deno, you can't do this because there is no clustering available so you kind of have to run it on single core machines to get maximum performance out of your hardware. In other words, on cloud solutions like Deno deploy or a Kubernetes cluster configured to run it on single cpu docker containers.<p>I am not interested in that and as long as it is that way, running Deno is unfortunately a waste of my hardware. Sure there are web workers and they are great for stuff but if my process dies for some reason I don't want that to halt the application.
I've been using Deno for a large compiler project I've been working on over the last couple years, and for the most part it's been a dream<p>Of course that's not the most representative example, because a compiler can almost entirely dodge the ecosystem problem, but I thought I'd offer it anyway
node.js nowadays is a total disaster. I've been able to hold down the fort with turbo repo, but even then it's been a touchy strategy. I want to switch to Deno, and I'm interested in articles like this. Either that, or, because of the state of nodejs/NPM modules, and it's ever-increasing surface area of doom and resume driven development node modules, either somehow switch to deno or go back to just HTML and vanilla js. I just can't get any work done. I'm saying this as a developer with 27 years experience and who has written my own server side spidermonkey solution pre-nodejs.
> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer.<p>wat<p>(Deno seems worth checking out though!)
> ‘Deno’ (like ‘Node’ but backwards)<p>Yeah, no.<p>I wonder if more people just assume that to be true, heh. I kind of was expecting it, weirdly enough.<p>Hint: "node" is "edon" backwards. Not sure if that name is taken for something Javascripty ... * goes to check * yeah, I found [1] which seems to be 4 years old, tagline "Run browser JS in the terminal".<p>[1] <a href="https://github.com/dbkaplun/edon" rel="nofollow">https://github.com/dbkaplun/edon</a>
It is disappointing to see this message as the basics of what the software is on their site (<a href="https://deno.land/" rel="nofollow">https://deno.land/</a>):<p><pre><code> Deno is a simple, modern and secure runtime for JavaScript, TypeScript, and WebAssembly that uses V8 and is built in Rust.
</code></pre>
Only to have that immediately followed by really poor practice of suggesting this as the installation method:<p><pre><code> curl -fsSL https://deno.land/install.sh | sh
</code></pre>
This is not strictly related to Deno -- lots of software does this -- but if you're going to suggest your thing is more secure than the other guys' thing (which is implied by calling your thing secure), you shouldn't then be immediately throwing that credibility away.<p>Yes, the page offers a link to the "Releases" page at their github repository. However, anyone familiar with any kind of UX will understand immediately that this is effectively burying the link and subtly makes the statement that you don't really want to bother with that other way of doing things. They also don't provide a gzipped/bzipped tarball for the linux install but a zip file instead, adding an additional barrier/dependency.<p>I understand this is an area where security is losing the tug of war to ease of distribution/access but it pains me to see it on any project, let alone the potentially good ones.