Deno 1.0
deno.land
deno.land
> ...
> 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 browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal. The above example will fail unless the --allow-net command-line flag is provided.
The Deno feature that seems to draw the most fire is dependency management. Some skeptics may be latching onto the first point without deeply considering the second.
Deno is just doing the same thing a browser does. Like a browser, there's nothing that JavaScript running on sandboxed Deno can do that a browser can't - in principle. So the security concerns seem a little over the top.
The one caveat is that once you open the sandbox on Deno, it appears you open it for all modules. But then again, that's what NPM users do all the time - by default.
As far as criticisms around module orchestration, ES modules take care of that as well. The dependency graph forms from local information without any extra file calling the shots.
This seems like an experiment worth trying at least.
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 from any url and run it immediately', means it's going to be much less secure than the already not-that-secure NPM ecosystem.
That means that I am actually a lot more vested into it, and if I want to put it in production, then I have to be concerned about things like this.
When somebody says they think X is broken, and they present a solution Y which they say is better, I am definitely entitled to ask why they think Y is better when I can't see the difference.
You're entitled to your opinion, of course. I had to read through the docs to understand their module system and intent. And I find it very exciting.
yarn global add ts-node prettier
echo 'alias deno="ts-node"' >> ~/.zshrc
echo 'alias deno-fmt="prettier --write"' >> ~/.zshrc
Internals are nicer but that's with anything without ugly legacy.
They are working to get node_modules work in deno so I am kind of worried that it will be nodev2 all over.
” We feel that the landscape of JavaScript and the surrounding software infrastructure has changed enough that it was worthwhile to simplify. We seek a fun and productive scripting environment that can be used for a wide range of tasks.”
Sounds intriguing to me. As a fan of starting projects of as simply as possible, I will certainly be tinkering with Deno.
Moreover Idk how granular the network permission is, but if its implementation is smart, you could block almost all outbound network access except the ones to your DB and the few API you may need to contact.
But indeed, if there is a separate user account for the application, then chmod can be used for some control to its access to files and directories.
iptables + namespaces gives you the rest.
NodeJS is also working on policies (1) which allows you to change permission to single modules or files.
For the network access I have an issue[0] open that asks to separate permissions to listen on the network from permission to dial. Also, along the way I want to have the ability to let the OS pick the port as an option.
Permissions are meant to work by whitelisting. So you wouldn't open access to the whole system just to talk to your DB, or to operate on some files.
What deno does is move package management away from the framework distribution. This is great - one thing I hate about node is that npm is default and you get only as much security as npm gives you. (You can switch the npm repo, but it's still the overwhelming favourite because it's officially bundled.)
Deno can eventually give you:
import lib from 'verified-secure-packages.com'
import lib from 'packages.cloudflare.com'
I have only the bare minimum of like, experience with nodejs. Would you mind fleshing out why that is so?
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 installing random NPM modules.
> and run it immediately
NPM packages also do this -- they can have install scripts that run as the current user, and have network access that can allows them to fetch, compile, and execute random binaries off the Internet.
From a security point of view, Deno is just making it clear up-front that you are downloading random code snippets, so that programmers are less likely to make the mistake of trusting a largely unmoderated package repository to protect themselves from malware.
I lean towards calling that a reasonably big security win on its own, even without the other sandboxing features.
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 add a hash and a size after the url, to force a check.
Well, using message digests, NPM or Yarn can pretty much guarantee content addressable versions, too. Do not have to use IPFS or blockchains, just because...
Or similar to node_modules, have some way to pull your dependency graph & host locally — At least for enterprise-y adoption I imagine that people will want to have _their_ copy of the code and choose when to update it even if in theory the remote code is locked down.
These concerns and the conversation around them are good and healthy. Give it some time. People will experiment with what works and over time best practices will emerge for the set of trade offs that people are willing to make.
If you don't need the firewall, you can just run in a chroot under a low-privilege user.
I mean, if you do otherwise, you are not following best practices and the voice of reason.
I think that overall you're right, but it's worth noting that deno can restrict file system access to specific folders and can restrict read and write separately. It's plausible to me that you could have a web server that can only access specific folders.
Servo is absolutely not production ready. A couple of particular pieces of Servo, such as Stylo and WebRender, can be considered production-ready, but no so much the project as a whole.
<url><newline><size in bytes><newline><hash>
import { serve } from deno.http.server;
Most people would want the option to do dependency management on a per-project basis as well. Simply allow a command-line parameter to provide one or more other directories to source from first (besides presumably the global one for your installation).
If we wanted the file to be generated automatically, maybe something like this:
import { serve } from deno.http.server at "https://deno.land/std@0.50.0/http/server.ts";Not saying that makes it a bad idea, but importing/downloading trusted code over http(s) is not simple even if the protocol sorta is.
Yup! I am really excited about Deno and curious about how popular it will be in a few years.
Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land :-)
Am curious how Parallelism could be handled in the runtime? Besides exposing WebWorkers, would shared memory be a possibility? V8 looks like its heading toward a portable WebAssembly SIMD accelerator.
>>> Promises all the way down
Async / await is a great pattern for render loops by resolving to continuous window.requestAnimationFrame calls. Here is a nifty example computing a Buddhabrot and updating new data quite smoothly:
http://www.albertlobo.com/fractals/async-await-requestanimat...
It's a multi-domain Let's Encrypt X3 certificate and I believe most LE users will be in a similar boat now.
Cisco sounds like a router might by running a MITM on you?
Edit: This looks to be confirmation that that root (or one by a very similar name) is used by a MITM tool:
https://docs.umbrella.com/deployment-umbrella/docs/rebrand-c...
This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex.
One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be compiled down web assembly and have llvm spit out a highly optimized binary. This not only benefits demo, but the rest of the internet.
TSC has done some great architectural changes in the past like doing mostly functional code, rather than lots of classes.
The target we should be aiming for is a powerful typed language like typescript that complies very quickly to webasshmbly that can run in guaranteed sandbox environments.
https://github.com/swc-project/swc
It's still not feature-complete, but there aren't any alternatives written in Rust that I know of.
Also: If I'm not entirely mistaken Microsoft initially planned to have a TypeScript-specific interpreter in Explorer. This also might indicate that something like that could be possible.
1: https://www.microsoft.com/en-us/research/publication/static-...
From the description, it doesn't sound like Deno needs the type information for V8 optimizations (I thought they had explored that, but I don't recall, and the description here is unclear), so maybe switching to more of a two pass system of a simple as possible "type stripper" (like Babel's perhaps?) and leave tsc compilation for type checking as a separate background process. Maybe behind some sort of "production mode" flag so that type errors stop debug runs but in production assume you can strip types without waiting for a full compile?
Maybe even writing a type stripper in Rust isn't a bad idea, but definitely trying to capture all of tsc's functionality in Rust seems like a fool's errand.
I use it with ts-node all the time for my docker images that require fast startup.
node -r ts-node/register/transpile-only xyz.ts
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 depend on goes down, just as I have a huge spike in traffic?
Say what you want about Node's dependency management, but atleast I'm guaranteed reproducible builds, and the only SPOF is the NPM repositories, which I can easily get around by using one of the proxies.
And this is different from NPM how? Except that I've now lost all the tooling around NPM/Yarn.
Not saying Deno won't devolve into this sad state at some point. Maybe it already has. But it seems to try to combat some of the problems by being honest and pragmatic about dependencies, promoting minimal external tooling and removing some of the dangerous abstractions from NPM.
To me Deno seems like a desperately needed and well thought out reset button.
Semi-related rant over.
The default in Deno is questionable choice. Just don't fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.
After all, the whole point of a URL is that it unambiguously identifies resources in a system-independent way.
Not decoupling the source of the package (i.e., the location of the repository whether it is on remote or local) and its usage in the language is a terrible idea.
from foo import bar
# foo should not be a URL. It should just be an identifier.
# The location of the library should not be mangled up in the code base.
The issue you bring up can be solved in several ways: for example, xml solves it by allowing you to define local aliases for a namespace in the document that’s being processed. Npm already sort of uses the package.json for this purpose: the main difference is that npmjs.com hosts a centralized registry of module names, rather than embedding the mapping of local aliases->url in the package.json
About 100 python files, each one approximately 500-1000 lines long.
Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL):
- How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor dependency resolution or upgrades, maintenance, deprecation?
How will these problems be solved? Yes, I understand the benefits of the URL - its a unique identifier. You need an intermediate "look up" table to decouple the source from the codebase. That's usually requirements.txt, poetry.lock, pipenv.lock, etc.
One off scripts would do `from https://example.com/package import bar` and bigger projects could define a translation table (e.g. in __init__.py or similar) that defines the translation table for the project.
Embedding this sort of metadata in the runtime environment has a lot of advantages too: it’s a lot easier to write scripts that query and report on the metadata if you can just say something like `import deps; print( deps.getversions(‘https://example.com/foo’)`
One of the best parts about web development is that, for quick POC-type code, I can include a script tag that points at unpkg.com or similar and just start using any arbitrary library.
// deps.ts
export {
assert,
assertEquals,
assertStrContains,
} from "https://deno.land/std/testing/asserts.ts";
import { assertEquals, runTests, test } from "./deps.ts";
Let's say I needed a `leftpad` lib from npm - it would be imported and re-exported from `./lib/leftpad.js` and my codebase would import leftpad from `./lib`, not by its npm package name. If / when a better (faster, more secure, whatever) lib named `padleft` appears I would just import the other one in `./lib/leftpad.js` and be done. If it had incompatible API (say, reversed order of arguments) I would wrap it in a function that accepts the original order and calls padleft with the arguments reversed so I wouldn't have to refactor imports and calls in multiple places across the project.
It's an upcoming feature on the browser standards track gaining a lot of traction (deno already supports it), and offers users a standardized way to maintain the decoupling that you mentioned, and allows users to refer to dependencies in the familiar bare identifier style that they're used to from node (i.e. `import * as _ from 'lodash'` instead of `import * as _ from 'https://www.npmjs.com/package/lodash'`).
I imagine tooling will emerge to help users manage & generate the import map for a project and install dependencies locally similar to how npm & yarn help users manage package-lock.json/yarn.lock and node_modules.
This is starting to look like a case of being different just so you can say you're different.
In my opinion this is Deno’s biggest selling point.
Could you elaborate on this? Is it that Deno is against the whole 'small packages that do one thing well' principle and instead in favor of complete libaries? How exactly would it dissuade me from installing hundreds of dependencies?
> The idea there is to include only what you need deliberately and it manage it as a remotely written extension of your application.
I have a node app, in which I deliberately only included the dependencies I need. The package.json lists exactly 8 dependencies. However, the node_modules folder already has 97 dependencies installed into it. The reason of course is that these are dependencies of dependencies of dependencies of dependencies.
Wouldn't Deno have this same issue? Are the dependencies also distributed in compiled form as a single file akin to windows DLLs?
How is that not "decentralisation"
And if you are importing single files from a remote url, I would question your sanity.
yep, that's basically the same. deno has the benefit of using the es module system like it is implemented in browsers.
I'm only asking because lots of people seem to be loving this new dependency management, so I'm pretty sure I'm missing something here.
Imports from URL would allow me to know exactly what I'm getting.
You can install a specific version from git via yarn/npm.
How do you trust a url more without reading the code?
What's going to stop deno ecosystem from putting minified js files on cdns and import them?
Deno has the functionality of npm, the tool, built-in.
The difference is that like Go, Deno imports the code directly from the source repository.
In practice it's going to be github.com (but can be gitlab or any code hosting that you, the author of Deno module, use).
NPM is a un-necessary layer that both Go and Deno has removed.
It's better because it's simpler for everyone involved.
In Go, I don't need to "publish" my library. People can just import the latest version or, if they want reproducibility, an explicit git revision. Compared to Go, publishing to npm is just unnecessary busy work.
I've seen JavaScript libraries where every other commit is related to publishing a new version to npm, littering the commit history.
In Go there's no need for package.json, which mostly replicates the information that was lost when publishing to npm (who's the author? what's the license? where's the actual source repository?).
As to this being insecure: we have over 10 years of experience in Go ecosystem that shows that in practice it works just fine.
Do you manually install a list of libraries provided by the author's readme?
1 - not wipe the cache folder at each build? It's easy and secure. Oh and your build will be faster.
2 - use a cached mirror of the deps you use? It's like 10min to put in place and is already used in companies that care about security and availability anyway.
3 - you have https://deno.land/x if you want to put all your eggs in the same npm basket
I still don't understand how this is better than NPM, and how Deno solves the horrible dependency management of Node, but maybe if I actually build something with Deno I'll get some answers.
> [With NPM] the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web.
Subjective.
> Centralized currency exchanges and arbitration is not in line with the ideals of the web! - Cryptocurrency
Nek minute. Besides, let's get real here; they will just end up centralized on GitHub. How exactly is that situation much different than npm or any other language ecosystems library directory being mirror-able?
git does not require Github to be online to work, nor relies on Github existence for its functionality.
And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).
I hate to break it to you but dependency management has been a massive issue in golang until the devs formally adopted go mod.
Only Google seemed okay with checking in their dependencies to version control. Everyone else was doing crazy hacks like https://labix.org/gopkg.in
You will ask, what about adding the OS to your SCM too, yeh why not have the full software stack. But you can generally draw a line between strong abstraction layers: Hardware | Kernel | OS | runtime | your app. Some modules do have strong abstraction layers, but others are just pure functions which you could just as well copy into your own repo.
I haven't seen anyone commit vendor and not complain about it. But now you finally don't have to commit vendor for reproducible builds. All you need is a module proxy. The "all you need" is not really meant seriously of course.
And I personally prefer to not commit vendor and complain about it.
I don't think it it is an unsolvable problem. For example, other solutions could be using a mirror proxy to get packages, instead of directly from the source, or pre-populating the deno dir from an artifact store. It would be nice to have documentation on how to do those though.
Even if it was better supported, I wouldn't want to start using it just so I can include all my dependencies in git. Of course if you are using something like vfs for git anyway, then increasing the repo size is less of an issue. It still feels wrong to me though.
If I have an application that uses, say, moment.js and want to import a specific locale, typically this is done using a dynamic import.
https://github.com/ChALkeR/notes/blob/master/Gathering-weak-...
- node ships with npm
- npm has a high number of dependencies
- npm does not implement good practices around authentication.
Can someone compromise npm itself? probably, according to that article.
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 want to get the latest packages automatically? But isn't that a security risk as well, as not all changes are improvements?
They would do well to have an option to optimize dependencies for vendoring.
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.
Almost all successful, mainstream, techs are like that. From a purely technical perspective, they are awful (or where awful at launch), they were just adopted because they were easy to use. When I say awful, I mean for professional use in high impact environments: financial, healthcare, automotive, etc.
Examples: VB/VBA, Javascript, PHP, MySQL, Mongo, Docker, Node.
Few people would argue that except for ease of use and ubiquity, any of these techs were superior to their competitors at launch or even a few years after.
After a while what happens is that these techs become entrenched and more serious devs have to dig in and they generally make these techs bearable. See Javascript before V8 and after, as an example.
A big chunk of the HN crowd is high powered professional developers, people working for FAANGs and startups with interesting domains. It's only normal they criticize what they consider half-baked tech.
Perhaps the HN-hate is not about simplified greenfield tech as much as it is about breaking established brownfield processes and modules.
Or how about attack vectors like DNS poisoning? or government-based firewalls?
I know there's this[1], but somehow I still feel uneasy because the web is so fragile and ephemeral...
At the very least I would like to have the standard library offline...
[1] https://github.com/denoland/deno/blob/master/docs/linking_to...
What is anyone going to do about it? Anything has a chance of getting hacked or goes down just when you need it, be it GitHub, npmjs.org...
Blaming the tool for not having a protection against DNS poisoning is a bit far fetched.
See the "go-bindata" problem.
Separately I’m not sure what is enforcing this “small dependency graph” aside from making it hard to import things I guess. I wouldn’t be surprised if you end up with the normal behavior of people coming up with cool things and other people importing them.
Dependency management is a major cornerstone of any infosec program. There is more to that than just auto-installing a new dependency version.
> I’m not sure what is enforcing this “small dependency graph”
Because a large dependency graph is slow, insecure, and fragile.
We seem to agree? I said check. It’s very useful to have something tell you what’s out of date and what the updates are.
> Because a large dependency graph is slow, insecure, and fragile.
I asked “what”, not “why”. What is enforcing this idea you have of how Deno will be used? I feel like you want it to not be used with lots of dependencies, thus aren’t accounting for how to handle them. However, just because that’s the desired way to use it doesn’t mean it will be used that way. Lots of dependencies may end up still becoming the norm, at which point you’ll wish you would have more clearly defined how it should be done instead of letting the first third party solution win (as ended up happening with npm).
* A deps.ts that handles all external dependencies and re-exports them
* Import maps
Neither of these really give you a way to do the equivalent of "npm update". But I almost never want to update all my packages at once.
I don't like running "npm update" to try and get security updates, though. npm packages aren't very rigorous about PATCH level changes.
Since this stuff is breaking an new anyway, it would be nice to see dependency resolution and a reasonable way for historically reproducible builds (prod runs server 1.0.4 which is 5 years old, let's build that locally to do some bug fixing, using the same dependencies, gradually bringing it up to current 3.7.1...).
Sounds like the lifecycle management of deno projects will about as much fun as php before package management. And about as reliable.
[1] https://deno.land/manual/linking_to_external_code#it-seems-u...
With Deno, both of these use cases seem way harder to satisfy. None of your dependencies can say "hey, I work with versions 1.1 to 1.3 of this dependency", instead they link to a hardcoded URL. The best chance of overriding or updating anything is if Deno supports a way to shim dependencies, but even then you might need to manually analyze your dependency tree and shim a whole bunch of URLs of the same library. On top of that, as soon as you update anything, your shims might be out of date and you need to go through the whole process again. To make the whole process easier, Deno could compare checksums of the dependencies it downloads and through that it could show you a list of URLs that all return the same library, but this would be like the reverse of package.json: instead of centrally managing your dependencies, you look at your dependencies after they have been imported and then try to make sense of it.
That's a real problem that needs to be solved.
Also, what happens when two lib A and lib B depend on different versions of lib C? Each have their own scoped instance of C?
The runtime does runtime things and someone can build a package manager to do package manager things.
The benefit of having runtime + package management bundled into one is you have an opinionated and standard way of doing things - the downside is if the package manager stinks then the whole ecosystem stinks.
I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support. I'm excited to see how Deno can take advantage of native TypeScript support to make a REPL more productive: subtle type hinting, integrated tsdocs, and type-aware autocomplete (especially for a future pipeline operator).
> fish
I see what you did there, and I approve.
I think stepping outside the npm ecosystem is going to be a bigger issue then people think.
I'm sure I'm missing something obvious in that example, but that capability terrifies me.
It's also exactly what the websites you visit do. ;)
I'm not sure how this works in detail here, but at least in NPM you got a chance to download packages, inspect them and fix the versions if so desired. Importantly, this gave you control over your transitive dependencies as well.
This seems more like the curl | bash school of package management.
Edit: This is explained in more detail at https://deno.land/manual/linking_to_external_code and indeed seems a lot more sane.
> It's also exactly what the websites you visit do. ;)
Well yes, and it causes huge problems there already - see the whole mess we have with trackers and page bloat.
Even with all NPMs flaws, I do feel this is a bit of throwing the baby out with the bath water. Time will tell.
That's not true here. If I'm running a web server I'm going to need to give the app permission to read the files being served and access to the database. That something that never happens in the browser.
This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NPM world does not currently have.
Deno does have lockfiles: https://deno.land/manual/linking_to_external_code/integrity_...
I prefer imports from URLs. And I loathe npm. I get why people would disagree though.
Always commit your lock files people
I don’t know the state of the art anymore, but I’m sure they have ways to make it easy to vendor deps in the repo.
"web browsers already do this ;)" isn't a good comparison.
Actually, no Deno webserver I've written gets fs access. Some only get --allow-net.
Here is the page with more detail. https://deno.land/manual/getting_started/permissions
It can even restrict access down to a specific directory or host. This is cool.
Whereas any NPM module can map your subnet, lift your .ssh directory, and yoink environment variables, wily-nily.
It's happened before.
It'd be nice to have some capability model where modules can only access things through handles passed to them, but probably infeasible for a project like this.
> Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime.
du -hs node_modules
1.7G node_modulesSo I basically have to do manually, what NPM/yarn do for me already?
You can use lock-files, bundles, and many other features that makes dependencies management easier.
import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
I don't find versioned URLs much more difficult to work with than package@<version> though.
jokes aside, i wonder how import-via-url will impact tooling. having to parse arbitrary JS (or even run it, for dynamic imports?) seems like it'd make writing a "list all dependencies" tool much harder than a "dumb" JSON/TOML/whatever file would. though i guess Go does a similar thing, and afaik they're fine
You can add an “integrity” attribute to script tags in the browser.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
This is pretty much like all the bash one-liners piping and executing a curl/wget download. I understand there are sandbox restrictions, but are the restrictions on a per dependency level, or on a program level?
If they are on a program level, they are essentially useless, since the first thing I'm going to do is break out of the sandbox to let my program do whatever it needs to do (read fs/network etc.). If it is on a per dependency level, then am I really expected to manage sandbox permissions for all of my projects dependencies?
If you want to "feel" as safe, you have import maps in deno, which works like package.json.
Overall, I think Deno is more secure because it cuts the man in the middle (npm) and you can make a npm mirror with low effort, a simple fork will do. Which means you can not only precisely pin which code you want, but also make sure nobody knows you use those packages either.
Take it with an open mind, a new "JSX" or async programming moment. People will hate it, then will start to see the value of this design down the road.
I don't detest NPM in the way that some people do, but I have always worried about the implications of the fact that nearly the entire community relies on their registry. If they ever fell over completely, they would have hamstrung a huge amount of the JS community.
npm installs aren't the same as installing from a random URL, because:
* NPM (the org) guarantees that published versions of packages are immutable, and will never change in future. This is definitely not true for a random URL.
* NPM (the tool) stores a hash of the package in your package-lock.json, and installing via `npm ci` (which enforces the lockfile and never updates it in any case) guarantees that the package you get matches that hash.
Downloading from a random URL can return anything, at the whims of the owner, or anybody else who can successfully mitm your traffic. Installing a package via npm is the same only the very first time you ever install it. Once you've done that, and you're happy that the version you're using is safe, you have clear guarantees on future behaviour.
they know there is a bad mitm vector and won't fix it
It'd be interesting to look at ways to mitigate that by requiring anybody using a package version to rehost it for others (since they have a copy locally anyway, by definition). But then you're talking about some kind of IPFS server built into your package manager, which now needs to be always running, and this starts to get seriously complicated & practically challenging...
Do you trust this thing? Better off developing it yourself, or working with something you trust then.
>> Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.
Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems.
As for the dependencies-as-URLs, I don't mind it, and may prefer it. I've been experimenting with minimizing my dependencies lately, and vendoring them in git submodules. It's worked fairly well.
[0]: https://github.com/pull-stream/pull-stream
[1]: https://github.com/reactive-streams/reactive-streams-jvm
But in JS the receiving end will just keep firing off data events until you pause it, or use something like reactive streams to request data as you're ready for it.
That's my understanding of the situation at least.
> To mitigate this problem, a pause() method was added. This could solve the problem, but it required extra code; and since the flooding issue only presents itself when the process is very busy, many Node programs can be flooded with data. The result is a system with bad tail latency.
Are they saying that even with correct use of pause() there are still issues?
All the reactive streams stuff still had been push streams, just with some backpressure bolted on. The issue was that without async/await, you always end up with some kind of callback model, which then again results in a push model.
Whereas with async/await you can just mostly model IO like any kind of synchronous IO.
Putting aside security, availability and mutability is a massive problem, anyone can stop hosting their module, or worse, change an existing published module at any time.
Why not take some inspiration from maven central, and run a central repo that actually provides some validation on the quality of and consistency of published artifacts.
Because then it would be hard to have a new hot framework every day.
Users who need centralization / QA from their packaging ecosystem can always opt in to a centralized repository.
> Supports TypeScript out of the box.
Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).
The catch for me is that it's probably not suitable for a sever in production as mentioned elsewhere in this thread.
I noticed in a couple of popular TypeScript (+React fullstack) boilerplates, that they were using ts-node to run the server in production.
Unlike babel-node, there's no mention in the documentation to avoid using it in production - but I figured there'd be performance impact, since it's transpiling on the fly (I suppose just once per require).
> The browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal.
I read this and I started looking around for the camera API or maybe for the Audio API. And the thing is that I can't seem to find anything about it. I can't see anything about it in "The Manual" or in the API reference.
Then I thought that there may not be documentation because it just mimics the browser's API. Ok, but... there must be some command-line flag to give permission to it, right? Can't find it either. Maybe "it was just an example; there's no media API just yet"?
But then I set out to find available command-line flags in general. And I can't find those either. There's this [0] but is that all? There's just --allow-net, --allow-read and --allow-write? Or is there some other place where the available permission flags are listed?
-A, --allow-all Allow all permissions
--allow-env Allow environment access
--allow-hrtime Allow high resolution time measurement
--allow-net=<allow-net> Allow network access
--allow-plugin Allow loading plugins
--allow-read=<allow-read> Allow file system read access
--allow-run Allow running subprocesses
--allow-write=<allow-write> Allow file system write access
> Early on in the project we had hoped that "V8 Snapshots" would provide significant improvements here. Snapshots have certainly helped but it's still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust.
> This will be a massive undertaking and will not happen any time soon; but it would provide order of magnitude performance improvements in a critical path experienced by developers. TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch.
> All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It's not yet 100% safe, but we're getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself.
We'll also have to wait on who will be the first to have a production ready Javascript Engine written in Rust that could replace V8, if you're talking about safety.
Even with the "safe" bindings, you will still get the same C and C++ vulnerabilities found in V8 that will also be present in Deno.
That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.
ts-node is a runtime able to run TypeScript. It is definitely much much slower at execution, not just at startup time. It's useful for hacking around, I use it as a REPL but even for a dev environment it's faster to use tsc's incremental compilation with a file watcher, and execute the resulting JS
TypeScript is just an extra.
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 compile with tsc.
JavaScript at Stage 3 and above is a stable compile target, and Deno should just run that.
The issue is that the TypeScript it loads today, it might not load in the future.
My love of the C++, Java, C#, ad nauseum, lineage of Enterprisey OOP languages turned to hate about 15 years ago, though, so take my assessment with a grain of salt.
“C with classes” seemed like a good idea, we were told back in the 80s in school, since garbage collection is impractical. Er, yeah. Worse is better...
And in the 80s it was even more so due to CPU and RAM performance.
> 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.
though i think it just strips the typescript annotations. but this may be workable if during dev there's some kind of guarantee that the typechecking has already been done.
>> We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust.
Funny, I was just talking about something like this in an earlier TypeScript discussion today. I was saying that I don't understand why Microsoft doesn't have their own native TypeScript runtime engine by now.
I have nothing against TypeScript as a language but I hate the TypeScript transpiler; it should be packaged as an engine, not as a transpiler. I just hate having to debug mangled transpiled code and dealing with sourcemaps. I want to be able to run and debug my own code, not some alternative mangled version of it.
I think Deno is a promising project in the sense that they seem to understand the drawbacks of transpilation and are actually trying to provide TypeScript support which feels native. Everyone else seems to be ignoring this problem including the creators of TypeScript.
what would they do with it? ship it in Edge? great, now some small fraction of users can run TS natively. but most can't, so everyone would still transpile to JS anyway...
it could work if Google did it, but i don't think MS has enough market share to have an influence here
Look into ts-node. It lets me run and debug the TypeScript itself before transpiling it.
- 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 good old leftpad) won't break all applications, etc. Since package locations are hard-coded in the package files, it becomes challenging to do this.
The argument that deno is mimicking a browser is thin. Browsers are client side, they don't access databases or lives inside your firewall. Server applications are much more sensitive to security issues than browsers.
The majority of the interest lies in the fact that Ryan Dahl[1] was the original creator of Node.JS[2], which is currently a very popular Javascript runtime and web backend.
Dahl released the initial version of Node.JS in 2009[3]. After a decade of experience working on Node.JS and growing the community, Dahl decided to create an alternative Javascript (and Typescript) runtime in mid/late 2018 called Deno which is now v1.0.
Just to nit-pick: Ryan Dahl had stepped away from node and the surrounding ecosystem in 2012. So for the vast majority of node's lifetime, he hasn't really been involved. Node in 2012 was a very different project.
(That doesn't take away from his observations or from the things that deno does differently. Just trying to reduce confusion.)
We've launched Deno support on repl.it here (in beta): https://repl.it/languages/deno for folks to try out.
You know what would be extra amazing? Incorporating (at some point in the future) all of the very smart stuff that the unison people have been doing. That would be _tremendous_ for code re-use and guarantees about remote packages. What I wouldn't give for a JS vm that could do all that. . . .
What’s the relevance of IPFS?
Deno's lead is Ryan Dahl, the creator of Node.
In the past, Dahl's expressed regrets over choices he made early on in Node's development, and on the direction Node has gone since he left the project many years ago.
He bravely presented on this topic at jsconf eu, 2018: https://www.youtube.com/watch?v=M3BM9TB-8yA, it's a fantastic talk.
The last 10 minutes are a pitch for what a "better Node" would look like, if he were to start from scratch in 2018. The end result of that train of thought this project, which we should probably think of as bourne-again node.
Deno's development is (presumably) strongly influenced by his experience and furstrations with Node's shortcomings in both performance and developer ux.
EDIT: I'd like to add that clearly he is able to spend his time as he wishes.
Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.
This really feels like the fundamental response in the js world and why we see much churn.
Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.
People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.
Except there aren't any breaking changes in JavaScript, are there? Even in Node if anything is deprecated that is done over time in many years.
Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript.
More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix.
The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases.
Why is that amusing? I specifically chose that example for that exact reason. I was highlighting the difference in the audience and use case.
> However I'd suggest this is not one of those cases.
I don't see the argument that supports that, either in the post or your reply.
The thing is, I can see Beepboo 1.0 being announced in 2025 to address the things that went wrong with deno. Because there will be design mistakes. And at what point do you say 'oh too many people rely on this software to fix this, I have to start over'?
Couple this with a very real trend-chasing and resume pushing in frontend dev and I'm starting to understand why people are so cynical about this stuff.
Typescript is something more palatable to me because it wasn't throwing the baby out with the bathwater.
My apologies I misread.
> ... there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes.
The thought that Node.js should have been 'fixed' instead of creating Deno is where I disagree. At a glance I can see a few reasons:
- Node.js maintainers + community may not even think there is something to be fixed (see various discussions in this thread about module resolutions)
- Politics, death by committee, inertia
- Effectively a dependency with npm registry (although not technically)
- Lack of backwards compatibility with changes (e.g. module resolution)
> The thing is, I can see Beepboo 1.0 being announced in 2025
Node.js was initially released in 2009 so it's probably fairer to suggest Beepboo 1.0 will be released in 2030. And yes, if it improved on Deno and solved inherent problems that couldn't be solved internally, I would wholeheartedly cheer it along.
I think it's also worth mentioning that Node.js is at a level of stability and maturity that people who plan to and have already built on it, aren't left abandoned.
Software changes, languages change. Billion dollar companies adapt or migrate.
Or maybe as Perl 6
Is it fair to say (a managed) deno is what Cloudflare Workers is? If not, what would be key differences between them?
They're not really directly comparable other than "A JavaScript runtime built on top of V8."
Workers doesn't support TS directly, though you can compile TS to JS and run it, of course. (My team maintains a worker and this is what we do, and it works well)
Deno has its own APIs, as does Workers. Worker's main API is the Service Worker API, Deno's is not.
Workers is focused on V8 isolates as a means of achieving multi-tenency. I don’t believe Deno does anything specific here.
Deno is mostly implemented in Rust, the Workers runtime is written in C++.
Deno is open source, Workers is not.
Workers is being used at scale in production, Deno just launched its 1.0.
I am very excited to see what happens with Deno. :) Fun history: I had been dreaming about doing "Chakra Core + Tokio" a few years back, but didn't find the time. I'm skeptical of the dependency approach Deno is taking, we'll see what happens!
Deno implements the web worker API, which launches different isolates. You could implement something kind of like CF Workers in pure TypeScript, but probably not replicate your resource enforcement.
It's also a pretty good Rust v8 implementation. Before we (fly.io) abandoned our JS runtime we were rebuilding it with that.
Ironically, we also tried Chakra Core + Tokio. It sure would be nice to have a not-google JS engine.
Ah interesting! Did you abandon it for reasons other than “deno exists”? Would love to hear more about how it turned out, good or bad.
Deno’s existence gives me hope we can bring back the JS API, I'd love to have nginx-as-a-TypeScript-API.
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.
That's exciting! I wonder if that binding is public for end users to use, or if it's an internal design
Something like this is already done with only allowing access to certain APIs if they are called from certain types of event handlers, until the callstack of the event handler is left.
I think that Deno should define a standard dependency fetching protocol, and allow proxying transparently at a native level. If it does, that kind of dependency management will be fine.
Under-mentioned feature. I may migrate my personal site to Deno just for that latency drop.
I've read the docs and it says it caches on the initial execution and doesn't update unless it's forced to update, but what happens when you for example publish a deno module to github, and someone else downloads it and runs it, and turns out the URL contains completely different library at his execution point?
HALLELUJAH that there is a clear, simple separation of when (a) you expect a lock file to be checked to guarantee integrity and (b) when you want it to be generated. The complete insanity that was npm shrinkwrap and lockfiles for years, summed up in this stackoverflow post https://stackoverflow.com/questions/45022048/why-does-npm-in... , always baffled me in that it seemed like it could have just been so easily avoided about being explicit when you're writing a lockfile vs. when you're using it.
That said, why not be even MORE explicit about it, i.e. "--use-lock=lock.json" vs. "--write-lock=lock.json"?
However, it still seems risky to me in case a library is not available. Is there a central repository planned? Or are you expected to vendor everything and ship your project with dependencies included?
The initial thing is the fear "whoa, that is hella insecure!" which, I agree NPM is basically the same problem... although, with NPM - Git system, you can 1. fork a version and use that version (which you can do with this, just host different url) or two you can freeze version you are using and theoretically only update after checking stuff out (I guess you would have to do the same with host different url, seems more difficult process)
Also NPM basically makes a local cache of the files you will be importing, I guess the first time you run your program it must get the files and then caching keeps them from updating until the resource updates? Maybe I'm missing something and it isn't like that but if it is like that I find that weird because you are arbitrarily adding extra performance overhead to parts of your system as code loads and sees it needs to get a resource that has updated? I guess what would end up happening is versioning would be in the url and an expires header set a long time in the future, like you might do with static assets now, but Deno doesn't require that, it will be an outgrowth of this import from url system. Will there be situations where someone has done the caching poorly, or set the header badly or whatever and you are loading a resource too often? I would expect so, anyway I guess there will have to be testing of Deno's caching https://www.mnot.net/blog/2017/03/16/browser-caching
Finally, in NPM's system if a module I'm importing is a little bit weird I can always just go into the folder quickly and start debugging and maybe fixing the code, and then when I've got things working the way I think they should with changes do an actual fork pull-request, or just fork and use my fork of the code, or if it turns out as it often does that I've misunderstood something revert my changes to their code and go fix my code instead. I can of course still achieve the same effect with Deno but the workflow would have to be different and I think would end up being more convoluted, at least in the beginning.
These are the initial worries that I get when seeing import from some url. I suppose someone has already thought these things through and I'm unnecessarily worried so if that someone is you (the reader of this long post) you can maybe assuage my worries.
Or in other words, wouldn't it have been easier and better to make an optionally headless version of the Servo browser with additional native APIs and some enhancements like being able to run JavaScript directly in addition to HTML?
The choice made means that Deno can't be used, at least directly, to make desktop applications, and also doesn't have all the features that browsers have for free, like multiprocess and multiple sandboxes, network traffic inspector, local storage, GPU compute, etc.
Sure, I guess you could shim it somehow like is happening in the node ecosystem but then.. I'm not sure what the stock situation brings to the table TBH.
As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal.
If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 second delay while it "compiles" my "TypeScript". (Again I don't write TypeScript so I don't need this feature). I should note, subsequent runs will be faster, but as I'm developing I don't want delays between my runs.
Since it's not even native TypeScript, it's just embedded the tsc which builds and caches the compiled code, why not let TypeScript developers add their bundling pipeline in the same way as they've always done.
Anyway, I'm very interested in the fact it's built in Rust and seems to be faster than node after compilation in many aspects. Congratulations to the Deno guys and thanks for all the effort.
[edit] Correcting myself. I was wrong. As @jon889 informed me, you can actually run a `.js` file and it will skip compilation. Again I remain that the TypeScript compiler should not have been included, but the fact I don't have to use it completely mitigates my main concern.
Deno runs JavaScript faster than node:
echo "console.log(1 + 2)" > not-ts.js
time deno run not-ts.js
3
0.01s user 0.01s system 89% cpu 0.025 total
time node not-ts.js
3
0.03s user 0.08s system 53% cpu 0.203 total
You can!
Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.
But in seriousness, Go compiles like lightening for me. But yeah, I think everyone has their own needs when they choose their tools. I choose Node for its speed at development and runtime.
And as others have noted: there's no downsides for those who wish to simply use straight JavaScript.
TypeScript's design is very much that of a typing layer over a dynamic language. It's unsoundness and various loopholes to escape typing mean it's not much of a help for typed compilation.
But your point stands I think this subset will be incompatible with how many (including myself) writes TypeScript.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
For instance, will a lockfile prevent someone from eavesdropping on the download of a modules through http? If so, please kindly tell me how!
I would prefer https-only, sure, but it doesn't buy you very much security.
I don't want to write an full lecture on how many attacks are possible when people don't use https. It has been commmon knowledge for way more than a decade
EDIT: I mean hashes of dependencies.
That is important for single-file scripts, if this is meant to be useful as a bash replacement for scripting.
Having to download two separate files for a script and execute it with special arguments already adds too much friction to that scenario.
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
import { dependency } from 'http://whatever.url/@1.0.3'
with hash '6f09aa686a6263f9e992'
The additional benefit is that you also don't need to trust the server to not replace code for a URL under your nose from one you have previously verified. So like a lockfile, but without needing to download a separate file (because you also want verification on the first run) and a command-line argument on launch - which makes it a much more viable replacement for bash scripts (in fact, that's why I care about the ability, I wouldn't mind https-only). Am I missing something here?
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.
Is there any possible way to face this vulnerability without either 1) linking to a resource over HTTP or 2) loading a resource from someone else who linked to another resource over HTTP?
Case one is the devs fault for doing it; case two is also the devs fault for not even checking their dependancies.
As infrastructure grows, there will be tools that either extend the environment to block/log HTTP stuff, or catch HTTP URIs in static analysis. Both of these, specially in combination, would be more than enough.
Knowingly leaving this kind of things in the codebase totally invalidate Deno being secure. There is not possible discussion in 2020 about https not having to be enforced. People thinking otherwise should not be allowed near a computer for their own good.
I know it's not an identical problem, but it does demonstrate that we probably agree that the onus is on the user to assess the risk of any arbitrary code they run on their machine, including the risk associated with the transport they use to obtain that code.
Funnily enough I actually agree with you that I would prefer to prevent http imports by default. However doing so won't make importing a library secure, and conversely allowing it doesn't mean it is insecure.
As an aside, I noticed you have posted the same one line message about the risk of a MITM attack with http imports 4 times in this thread. You might find it more helpful to contribute to the discussion by explaining why you think that.
Linux is not branded as a "Secure thing" right? Here Deno is building marketing on something inacurate.
browsers have been benefiting from decades of innovation to mitigate the security issues of execution of JavaScript.
CORS headers is the latest of theses innovations. Deno allow you to fetch code as a browser would without providing you with any of the safety browsers can have. Mostly because it would not make sense to have a runtime doing that.
Deno is not a browser but takes the risks of a browser. Running Deno install is as safe as browsing the internet using Windows CP without SP 2 and Internet explorer bellow 6.
Also, importing a module in https does not mean this module won't import anything using http. Should you review the code of all imported modules? This is virtually impossible.
Deno must disable http by defaulkt and provide a flag to re-enable it. This is factually a security issue in Deno.
I wouldn't be surprised if this was exactly the direction that Deno was trying to move towards. Fewer direct dependencies with some amount of transitive trust.
I.e. "[Deno] has a set of reviewed (audited) standard modules"
> Windows CP without SP 2 and Internet explorer bellow 6
I get the point you're trying to make with this hyperbole but browsers still let you view http pages (by default).
> Deno must disable http by defaulkt and provide a flag to re-enable it. This is factually a security issue in Deno.
Again I agree with your idea about disabling by default but there is another perspective (and I think Ryan deserves some empathy).
The marketing around Deno has been made toward that and it makes no sense to reach 1.0.0 with such a big security issue unhandled.
Also, this part is even more frightening https://github.com/denoland/deno/issues/1064#issuecomment-43....
At this point, it is clear that Deno is lying for marketing reason by calling itself secure.
Of course Ryan deserves empathy, so does Bert. But in the meanwhile during their talks at major conferences, they have trolled a lot another project. The maintainer of that other project now get weekly/daily pings from deno supporters trolling them.
Deno's culture seems big around trolling atm, a CoC could have fixed it, the th (B)DFL has decided another way.
I'm not familiar with the surrounding politics and don't particularly want to be involved, but I appreciate the explanation.
I think evolution & starting over can both be appropriate steps forward, I don't question the Deno project, but to have the exact same people who created Node.js say "OK here's the new new JS hotness," I think "how can we expect this time to be different" is a reasonable question. Or perhaps these ecosystems are not meant to last/be supported more than 10ish years?
Explanation for why I want that:
I've started making an game RTS game - think starcraft but you can program your units.
Currently I'm trying to decide what language to expose to players. The two main requirements are that it's secure (I'll be running player A's code on player B's computer) and that it has a deterministic method of counting execution time (so that player A and player B's computer can both make the same decision on whether or not a script took too much time).
I'd appreciate any hints towards other languages I should look at as well.
I have security concerns about all the lua runtimes I've seen. They (very understandably) do not seem to be particularly battle tested against malicious use, and they have a history of security issues when I check their bugs list. Otherwise I'd love to use lua.
This is definitely a requirement, a very scaled down one since I don't want any interaction with the outside world apart from the game engine (for determinism purposes).
> probably making your own JS parser/engine could be the way to go
That sounds like a lot of work to do well. If I had infinite time I suppose re-implementing a common language would be the best way forwards, but I don't, especially for a hobby project.
I'm coding the game in Rust, but I really don't care what the language is coded in, linking in a language runtime isn't a problem.
deno run https://deno.land/std/examples/welcome.ts
But if you visit https://deno.land/std/examples/welcome.ts in your browser you get back HTML, not raw code.
Anyone know how this works? Is deno.land a special case or is there some Accept header cleverness or something going on?
$ curl 'https://deno.land/std/examples/welcome.ts'
console.log("Welcome to Deno ");
$ curl 'https://deno.land/std/examples/welcome.ts' -H 'Accept: text/html'
Not seeing how url-based package management is safer when a package host can use a server that sends a special payload to certain requester ips, headers, cookies or referrer.
Until there are firm guarantees around what you get from a url, a trust-able third party is needed, even if just as an option.
No-one, at all, for the love of jeebus: Do another node-like thing, but make it in rust on top of C++ (or is the other way around ?), somewhat similar but generally incompatible, have a whole different set of APIs, a bunch of new tools and yet another package/module system.
The benefit of NPM is that every package version is immutable...
Also first class Typescript support is great, but they are just using tsc internally... isn't that directly tying a typescript version to the DENO version?
You can already do decentralisation with npm by simply not using`npm i some-package --save` and instead, modify the package.json yourself.
Now the problem with deno is that if I import 5 packages (locked to a specific version) across 50 files and I want to update them to a new version, am I really gonna need to go into every single file and change the URLs??
That's just insane, I get the whole idea of decentralisation but why can't we concentrate all packages into a single file??
Sire this is all good for distribution because you won't have to run `npm i` every time you want to run your program, but more often than not, I'm the one that's going to use my program and I don't mind running `npm i` beforehand and feel safe that I have all my packages downloaded and ready to go, instead of worrying that my program will fail at run-time because the URL for one of my packages is down..
I disagree with this assessment. Lua is still far superior as an embed-able scripting language/runtime. I suspect the preference for JavaScript is mostly due to the Deno developers' familiarity and preference.
I disagree with this assessment.
[0] https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...
Probably it will not replace node soon, but it is a possible outcome.
Also didn't luajit had the problem that it would never move to more recent version of lua? I remember that some years ago there was some talking about this.
Have you talked with the TS people to see if maybe there are some bottlenecks that could be rewritten in Rust rather than rewriting everything? Even though I would love to have TSC in Rust, it seems like it would be a huge amount of work.
So Lua, but Javascript? Could be neat
I like that Deno is resetting some of the underlying assumptions that Dahl made in Node. But I think he's throwing the baby out with the bath water. I actually like and prefer an explicit node_modules directory. Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy. Not sure why so much effort was made to avoid this module pattern. I really think using URLs is going to be a maintenance nightmare. Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports? Seems very odd unless I'm missing something big. Also, not a fan of the hidden .deno cache directory, but whatever.
Having to send along a shell script in order to even start an app is another problem. "Here's a JavaScript file which will do some task. In order to run it, you need to make sure you include these 10 command-line flags for security purposes. To make sure you don't forget them, I've included various shell scripts you can run depending on your platform." That's not improving anything.
I don’t even like TS, but it’s pretty clear I can discount your opinion because you don’t even know what you’re talking about.
Isn't there a risk of cross platform incompatibility with some of the packages that compile on install?
This is my biggest beef. When building large scale applications there are many more files with imports than a typical large scale golang project that uses the url import scheme. It's just going to be a really annoying thing to deal with. ATM I see deno being great as a replacement for nodejs scripts and smaller scale projects. But for massive projects I don't see the gain.
It's constructive to make claims like people using Typescript are "pretending" to do something and should stop.
People use Typescript because they've decided that Javascript with static typing is useful.
> function add(x: number, y: number): number {...}
You don't have to do this in TypeScript. In fact, you can use TypeScript without transpiling your code and without creating any types yourself.
Why would you do that? Because a lot of open-source libraries now come with types included, so you get type-checking for those APIs essentially for free.
> I'd just use Java
Java has a nominal type system. If you want a new type, you have to create it.
TypeScript has structural typing with type inference. That means you "just code" and the compiler will pick up your types if you go. If you write inconsistent code, it'll warn you. If you want to refactor a type, you now have enough metadata for your code to do that confidently.
> When is Typescript going to have its own version of the V8 engine and just leave JavaScript out of it?
Microsoft has had its own V8 competitor since around the time TypeScript was released[1]. They literally can't leave JavaScript out of TypeScript because every JavaScript program is a valid TypeScript program. TypeScript is a superset of Javascript. Other than the type system, it does not introduce any new features that are not on the EcmaScript roadmap.
> harkens back to the classic Microsoft Embrace, Extend, Extinguish strategy
Uh, no, it doesn't, because they have (A) open-sourced all of it, and (B) they haven't extinguished anything. Even if they did, there are massive numbers of people, including Google, who use TypeScript in production and would keep it going. There is no practical way to extinguish anymore.
In fact, all of their behavior (e.g. with the .NET ecosystem) suggests that Microsoft doesn't do those things anymore.
Clearly without packages we are not going to use deno. Also I don't want to switch from well-proven packages like express/koa to an new unknown http server just because it supports deno.
By the way a new http server doesn't "support" deno any more than Express "supports" node -- it's the other way around.
* separate out the Node APIs from the rest of your application logic as much as possible as those will be different unrelated API conventions.
* convert your application from using require to using ES6 modules. This won’t work if you have more that few highly trivial dependencies as Node requires picking one way of importing files and that one way extends to your dependencies as well.
* Node uses callbacks for asynchronous logic where Deno uses promises, so ensure all callback functions are passed by reference so that the difference is an API difference instead of a logic difference.
It's not the first time I see js iterators used and abused this way, and every time I feel that js and it's users are ready for full-blown monads and do notation instead.
1. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won't hurt anyone, but it's certainly never something that I've wanted. I expect most people will simply white-list most access by default in all new projects.
2. deno bundle: Initially, when I heard about this, I was excited. The need to bundle code via webpack and similar systems is one of the worst things about front end browser development. It introduces tons of complexity and makes debugging much harder. So I thought, wow, maybe deno is going to just give us a first-class solution to this problem that will just work. Nope. They are only concerned with bundling code such that it can be run elsewhere by deno. A friend put it thus: "we don't want bundlers anymore, so we're making deno bundle, the one true bundler!" "does it do any of the stuff that webpack does?" "mostly no, because it's not meant for that" Read the comments on https://github.com/denoland/deno/issues/2475 to get a sense of what I'm complaining about.
3. URL Imports. Packages in node.js are stupendously easy to use. Making me import from a URL instead of typing `yarn add foo` and `import * as foo from 'foo'` does not make my life any easier. It certainly makes the implementation easier, and I'm glad to see the last of node_modules and path-climbing module resolution. But the URL-based system offers no equivalent that I can see to lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial features. This is something that node developers need and want, and if Deno doesn't provide it, 3rd parties will. My worry is that we'll end up with competing third-party solutions and a fractured ecosystem, due to Deno's failure of leadership here.
4. Stack traces: The single worst thing about using node is the frequency with which you get utterly useless stack traces that tell you nothing about the true source of the error. It was easier to debug C++ programs 20 years ago that it is to debug node.js apps today. But as far as I can tell, deno isn't making any efforts to improve this. That's ok, they don't have to fix every problem. But it does make me worry that they don't know what node.js developers actually care about, if this wasn't on their "must fix" list.
5. Typescript by default. I really like typescript. I mostly want to use it instead of javascript these days. But tsc is slow. Slooooooow. Really really slow. I am worried that most deno programs are going to be very slow to start up in practice. (Before you say "caching", 99% of the time that you want to start a program, it's because you just changed the source code. caching can only do so much in this case). And I am extremely skeptical of the plan to build a new typescript compiler in rust.
I'll conclude with praising a few things that I am very glad to see: No more node_modules, Web APIs, and a promise-based stdlib.
New implementation of WHAT? Is this a JS Engine, or a wrapper around V8? Which version?
Guys - whatever it is - I love it (!!!), but this is a very long and wordy article that does not well summarize the most relevant things, and uses words, long explanations for issues that I think are just a little specific.
"First Class Typescript" - does this mean just 'transpilation at runtime'? Or does it mean something more hardcore? What does it mean at all?
This could be 1/2 as long a 2x more explanatory and precise.
Finally - it all looks super cool - but why specifically am I interested in this over things like Node? Speed, security?
Not to take away from the great work.
> Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.
import { serve } from "https://deno.land/[email protected]/http/server.ts";
React/React Native/Expo?
(I've been using deno for ~6 months but I'm happy we hit 1.0!!!)
Wouldn't that actually be python?
I hope this results in a faster typescript compiler.
1) I make a public / private key pair.
2) I log on to a DNS-like system, and create an account for myself, upload my public key.
3) I start up a Deno server, giving it my private key, and I give it the address of the DNS. Deno uses my private key to inform the DNS that it exists and is serving traffic. (Much like any Dynamic DNS server.)
4) My friend does the same - makes a public / private key pair, finds a DNS he likes, uploads his public key, makes a Deno server and registers it with the DNS.
5) My friend and I trade DNS+public keys. It's a URL to the DNS that has the public key in it.
6) I go to some administrator page on my Deno, it looks a lot like this [1]. I create a new Connection, and plug in the DNS+public key of my friend. He does the same on his server.
7) On my admin page, I pick an app that I want to use to communicate with my friend. I can see a list of my Connections, and I just check off a box that the app has permission to communicate with that friend.
8) This app that I've picked, it only sees the world through an incredibly narrow API. It's like WireGuard. Deno handles all of the communication and permissions, much like Sandstorm.io. The first thing I want is just queued-up JSON messaging. The app can send and receive JSON messages. I envision that I want it to be in messaging mode (rather than "streaming online"), so it has something like ZeroMQ under the hood to pub/sub, client/server, all that. But roughly it has a bi-directional pipe for sending and receiving JSON and can queue up messages when the other server is offline.
9) I now have a sandboxed app that can't talk to the rest of the world, has its own private VPN-like connection to another process. All traffic is encrypted like WireGuard. The DNS aspect lets my friend move his server if the IP changes.
I feel like if some project kind of like Sandstorm, kind of like Dynamic DNS, kind of like WireGuard, and kind of like Deno all got together, they would make a beautiful thing.
When I think about how I wish Diaspora worked, as a way to replace Facebook, this is it. I wish it was built on top of something like this. This is the atomic unit of distributed, yet safe, that I wish internet apps were made out of. I imagine that I would be setting up hosting of the Deno server nodes for my friends and family, since I'm their tech support guy. But they'd be in charge of their own connections and apps in their nodes.
So, HN, time for you to tell me that it's 1) a terrible idea, 2) already exists, 3) why don't I just make it myself. Right? =)
> error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:20 | 25 | pub fn define(tts: proc_macro::TokenStream) -> proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro`
error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:48 | 25 | pub fn define(tts: proc_macro::TokenStream) -> proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0433`. error: could not compile `swc_ecma_visit_macros`. warning: build failed, waiting for other jobs to finish... error: failed to compile `deno v1.0.0`, intermediate artifacts can be found at `/tmp/cargo-installFIkSV2`
Caused by: build failed
TypeScript is way too slow for what it does and that's ridiculous for a language that rejects useful features because it doesn't want to "stray too far" from ECMAScript.
In my view, typechecking doesn't belong in the "compiler" part of TypeScript. It should stay in the IDE. The compiler should just strip type annotations and do other trivial transformations.
Reminds me of https://npm.anvaka.com/#/view/2d/react-native
Good luck, though. Everyone lives in a different (mental) tribe I suppose...
That blog article just looks like an intro for beginners who don't quite know what static typing entails. Yes, static typing is different from runtime checks, that's why it's static.
What does that mean? "browser engine"
Does it execute JavaScript code?
Edit:
I bought your Rust book on Amazon, supposed to be delivered this Friday. I can't wait!
Ah cool! I hope you like it! :)
I think it falls into the same category as Koa (TJs successor to Express) and the upcoming "Rome" project. Someone creates a successful open-source project and then at some point in the future decides to make a better one with questionable tangible benefit and various downsides of its own.
The downsides I can see of Deno so far are that it is slower than node, it is not compatible with any server-side node code because it has rewritten the standard library, and it is inspired and based on the Go standard library, seemingly using Go idioms and so on.
Its benefits are questionable, vague, and not really proven.
I'm the co-founder of https://deno.services . We would like to make Deno first language in history comes with its own infrastructure.