wperron

Actually the most apt comparison here is if Bob sends over a contract for $1000, but then goes "oh no I'm sorry, I really meant $800"

There are not takebacks here.

Actually, I know there legally could be, as these situations aren't always black and white, however the company, being such a position of power compared to the employee, loses all goodwill in this situation. If I were in this situation, I would already be sending out feelers.

If you're not following those companies' offerings then it stands to reason you haven't heard about it but all three of them did broadcast pretty widely that they were using Deno, I would assume quite a few people were aware of this.

It's not a hot take, it's just a bad take, and a complete failure to understand the value proposition of these types of offerings (and why we're seeing so many of them pop up these days)

Has been possible (and surprinsingly easy) for a while through CDNs like skypack or esm.sh

Netlify, Supabase and Slack whitelabelling Deno Deploy for starters, I'm sure there are others out there self-hosting as well

It's really not, and it's even saying so explicitly in the article.

The whole conversation is a bit hard to follow, there was an issue initially, then this PR and then another Discussion that's linked somewhere in the PR. I'll let you go read those, I don't recall exactly what decisions were taken and what's the roadmap for this to become stable.

Dynamic imports are... wild, to say the least. Unfortunately they will always be inherently harder to secure, and will most likely always be treated differently than static import statements. At least that was the consensus in Deno.

Hi, I'm one of those people in the PR advocating for this change :) I think you may have missed the point of comparing the security aspects to NPM. By saying "it's no less secure" it's not saying "well it's just as bad, so what's the point?", but rather "given that it doesn't introduce any more vulnerabilities, what does this model unlock for us?"

HN comments probably aren't the best place to go in-depth on this topic, but just off the top of my head, HTTPS imports allow a greater detachment from a centralized registry, something we're seeing used a lot in the Go ecosystem, and we're moving server-side JavaScript closer to how browser JavaScript works, which is a good thing for anyone using the language, as it reduces friction across the board. This might not be something obvious for people working mostly/only on the backend, in which case those frictions aren't as apparent, but they are there nonetheless.

If you actually read the (admittedly long) thread, it's pretty clear that those imports are not resolved at runtime, and Deno has never evaluated imports at runtime either. Dependencies get evaluated and downloaded prior to startup, very similar to Go in fact.

> I’d argue URLs are fine until you get massive use of a single package and it weaves itself into a complex dependency tree across multiple other critical projects. Then you worry about the what if’s.

This is already an issue with npm. My personal take on this is that at that point that dependency should be vendored as much as possible but obviously it's hard to fight the existing inertia on this one. Also worth noting that the [std lib][1] is an attempt at a pragmatic solution to the problem where these foundational packages that are seemingly used by every framework out there essentially converges to the standard lib. I agree it's not perfect at the moment but it's a start.

[1]: https://deno.land/std

deno.land/x is _not_ a central registry. It's something we maintain as a convenience to the community, but we actually go to great lengths to make sure it doesn't receive preferential treatment from the CLI. Importing modules from nest.land, skypack.dev, esm.sh or jspm.io is common in the ecosystem and is something we're looking to keep encouraging.

It's also pretty easy to vendor in your dependencies so that they don't move between the time you commit and the time your server starts. We also support lock files so you don't _have_ to vendor your deps too. Versioning is up to the server you import from, but typically you'd put version in the URL somewhere (ideally a pinned version).

Security-wise, There are other articles out there that detail this but it's not fundamentally less secure than importing from npm as you're still pulling a JavaScript file from the internet in both cases. The cool thing here with URLs is that it's pretty easy to audit and create an allowlist of known-good and trusted servers to import from in your org.

As for vulnerability reporting & patching; I think we're still lacking a good vulnerability database, that much is true, but fixing deeply integrated deps that have vulnerabilities is pretty easy using import maps really.

yeah, it's a bit awkward and you have to dig through the docs to find it. We're thinking about making it the default behavior.

Transpiling TS to JS on startup does incur a cold start penalty, you can minimize it by using the `--no-check` option to transpile with SWC instead of TSC but it's still there. On subsequent runs though, it'll start up instantly because the JS is cached locally after transpiling (you can even trigger this step yourself with `deno cache`)

Beyond that, you still have the v8 engine running the JS, so yeah in most cases performance will be pretty much what you can expect from Node _except_ with regards to anything that reaches out of the sandbox (like filesystem or network access). These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages, and Promise-based APIs all the way down. For the builtin HTTP server for example you can expect higher throughput from Deno. Tail latencies also tend to be better with Deno.

You're not immediately going to get "blazing fast, native speeds" but you can get some nice optimizations.

> Prometheus has a pull model, which I can see the appeal of, but I don't really like.

That's such an antiquated statement at this point. Prometheus might have been pull-only in a distant past, but the remote write protocol has been alive and well for a long time now, and it works amazingly well, at surprising scale.

Whenever someone tells me "it's just syntax sugar, it doesn't matter" I usually point them to mathematics. This is both beautiful and horrifying in equal measure and _I love it_

There's a couple of reasons. Internally, there's quite a few things that we do in Rust that aren't actually taken care of by TypeScript -- Having our own LSP allows us to connect those bits (like the module graph resolver for example) directly to the internals of Deno, in-sync with the Deno version you have installed.

Deno also does more stuff than just providing Type definitions, embedding TypeScript and doing module resolution; it's a complete toolset -- there's things that we can cover having our own LSP that the TypeScript LSP can't. Linting, formatting, testing etc.

Pro tip: don't import those libs from deno.land/x. The runtime is agnostic to where you're pulling libs from, and that's by design. The AWS SDK v3 for example works great through the Skypack CDN, and you're pulling the canonical one, not simply a port maintained by a third party.

Sorry you've had this experience -- the LSP is improving a lot with every release, this one included, try it out and let us know what you think. We really appreciate issues for the LSP on GH

The canonical answer is _maybe_. If your Node lib relies on Node built-ins, you won't be able to import it directly from GitHub for example. However, CDNs like Skypack and esm.sh do polyfill some of those to Deno. Your mileage may vary depending on the lib you're trying to import. Some will work better on one CDN, some on another -- you really just have to try it for yourself. A surprising amount of libs work without issues.

The AWS sdk v3 works really well from Skypack, check out our docs for our Deploy platform, it has an example with DynamoDB https://deno.com/deploy/docs/tutorial-dynamodb#write-the-app...

Thanks for reporting, we recently moved our blog to deno.com/blog and haven't updated the post -- we'll fix that as soon as possible

Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exactly TypeScript)

We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.

We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem

_If_ the browsers do get a std lib akin to what we've built for deno, I would be comfortable archiving the deno_std repo and pointing people to use the browser one. We're not yet 100% compatible with browsers in the stdlib, but being compatible as much as possible is one of our goals, specifically to address the browser/server-side divide and generally make it simpler and more enjoyable to program in JavaScript

It's important to remember that while, yes, CommonJS made Node popular, it did so because it filled a void in the Javascript syntax and specs. There was nothing to formalize the concept of a "package" back then.

That's not true any more, ES Modules have made it into the spec, so that's what Deno is using.

As for package-lists, the current convention in the community at the moment if you have a decently sized library is to have a `deps.ts` file where you re-export all of your dependency, making it an equivalent to package.json and helps with upgrading dependencies across a codebase.

TypeScript is already optional in Deno! it will run any .js file just fine, and you even skip the compilation part.

to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really)

The truth is, even with a centralized repository, we're still importing user-code, made by humans that may not be well intentioned or simply not know that their code is vulnerable: proxying within your network and running periodic checks against the content of the local cache would be good practice, no where the code came from

Maybe... it depends on the amount of _trust_ that you put in the remote domain. My prediction is that the Deno ecosystem will aggregate around a few, large repositories that will have good guarantees araound immutability and good track records to addressing vulnerabilities.

For large projects like React, lodash, eslint whatever, I expect some of them will start hosting their libraries on their own networks, like it used to be when Javascript was only frontend and you would have a script tag importing jQuery directly from jQuery's CDN. The reason it worked was because jQuery was sidely known and trusted.

_If_ the node library uses explicit file imports, and ESM instead of CJS, it _is_ already possible to just do `npm install` and import from "./node_modules" -- again the problem is that Node's import resolution algorithm is horribly complex and not very explicit, but it's possible to be explicit using Node, and that would make it compatible in Deno

The beauty of Deno is that it's agnostic about where you import your code; At the moment deno.land/x only allows tags to be published - no semver range resolution, and doesn't allow versions to be removed/update. nest.land is another popular one, and is build on top of the arweave blockchain, bringing that chain of trust you mention.

The ecosystem is still in evolution but I expect that it stabilize around a few generic registries for smaller libs, and larger libs hosting their code themselves in the long run. The point is; while URLs _can_ be very loosy goosy ways to address code, they can also be made very strict - it will depend on the actual server behind it.

As a side note, npm is already pretty poor at providing those guarantees anyway, I find it interesting that it's usually assumed to be a safe way to install dependencies.