14 ms·

What the Hell Is a Deno?

166 points by harrylucas 6y ago

rvz 6y ago
Node => Deno => Done. One can simply say, 'Deno is like Node but done right'.
- harrylucas 6y ago
  I think its only the natural progression. there are definitely some flaws with it, it isn't perfect. However, the tradeoffs really do seem to swing in favor of deno.
  - hombre_fatal 6y ago
    It's too little, too late. Deno today might have been more interesting years ago when you had to write your own Typescript definitions for every library because TS had no traction. In 2020, Deno is just a stone's throw from `ts-node server.ts`. And the permissions system lacks the granularity to be useful.
- hst-m 6y ago
  'node'.split('').sort().join('')
  - cellularmitosis 6y ago
    its also a nice illustration of little endian vs big endian.
- bitwize 6y ago
  Deno : Node :: Deltarune : Undertale
  - deleted 6y ago
    [deleted]
  - mtm7 6y ago
    * This comment fills you with determination.
mrpopo 6y ago
> Both the browser and node.js use the same engine - the V8 engine. RIP every other engine, I guess?
- harrylucas 6y ago
  Oops that was definitely a mistake on my side! Good pickup though, I've updated it to include a link to a full list :)
- akdor1154 6y ago
  > RIP every other engine, I guess? In practice, pretty much :(
  - applecrazy 6y ago
    React Native uses JavaScriptCore, the JS engine for WebKit, at runtime.
    - statictype 6y ago
      Only on iOS right? Or is it embedded everywhere?
      - soylentgraham 6y ago
        Embedded in IOS & OSX, but one of the few that's easy to get a build of (or compile) in Linux, Windows, Android Chakra also easily builds on osx, ios, embedded in windows. V8 is a PITA to build & get a build of. (Wish it wasn't)
      - quantummkv 6y ago
        Everywhere. Even the android builds use JSC or Hermes instead of V8
danenania 6y ago
Deno definitely looks interesting! All the examples I’ve seen so far are using the ‘deno’ command to run .ts or .js scripts. Can it also package standalone binaries like go/rust—-to make a cli tool, for instance? If so, how do permissions work in that scenario? Does the user need to grant permissions on every invocation or is there some way to whitelist a script/binary?
- rahulete 6y ago
  Packaging to standalone executable is being worked on https://github.com/denoland/deno/issues/986 https://github.com/denoland/deno/issues/986
  - danenania 6y ago
    Nice! Will be interesting to see how permissions work in that case.
AtlasBarfed 6y ago
The author already inflicted one of the worst "worse is better" victories I can think of in the history of computing. Now he's fighting his own monstrosity.
- harrylucas 6y ago
  Author of the artcile (me) or Author of Deno?
  - deleted 6y ago
    [deleted]
  - ericol 6y ago
    I think he means Ryan Dahl Anecdotally, there are several languages (French, "Argentinian" Spanish to name a couple) where it's common to re arrange the syllables of the words backward-ish (More often than not for slang - argot for France, lunfardo in Argentina - uses).
    - aixi 6y ago
      What do you mean by your last sentence? The sentence makes complete sense and is not backwards translated to spanish
      - ericol 6y ago
        Hey sorry if that was not easy to understand, I was referring to the name of the thing. "Deno" is the same as "Node" with the syllables arranged backwards.
  - AtlasBarfed 6y ago
    Right, of Deno/Node, not you.
- dang 6y ago
  Please don't cross into personal attack in HN comments. I grant you that this is borderline, but it's still dipping a toe into those black waters.
esperent 6y ago
Node with a hat and fake moustache.
dvt 6y ago
> Javascript is great. But... in saying that it has a few quirks and can work in some unexpected ways. Typescript has just as many[1] (in fact more, as it's a superset) quirks than Javascript. I like using it (and it makes JS type-safe-ish), but it's not really some kind of paradigm shift. Not sure how I feel about import maps. They are quite literally the same thing as package.json. In fact, converting between the two takes about 20 lines of code[2]. I'd bet my bottom dollar that everyone's going to use them, which is going to lead to exactly the same types of problems as Node. [1] https://blog.asana.com/2020/01/typescript-quirks/ https://blog.asana.com/2020/01/typescript-quirks/ [2] https://github.com/WICG/import-maps/issues/60 https://github.com/WICG/import-maps/issues/60
- harrylucas 6y ago
  100% agree that typescript has it quirks and definitely agree about import maps most likely going to be the way you use deno. However there are tradeoffs with everything you use. It really comes down to which tradeoffs are the right ones for you, which may not be the same for someone else.
- com2kid 6y ago
  In regards to that first link, discriminated unions are awesome in general, it is a pattern that occurs all over the place in real world code and having compiler support for it is very nice.
- torb-xyz 6y ago
  Frankly I find TypeScript with strict mode turned on to be a safer and saner than C# and Java because of explicitly nullable types alone. I _never_ get null pointer exceptions in my own TypeScript code. Combined with fairly strict ESLint you get something that catches a lot of problems at compile time. Of course it's still far cry from being as safe as for example Rust. And yeah the inconsistency of JavaScript/TypeScript can be frustrating for sure. I think my dream language is one that is simply TypeScript cleaned up to be made consistent and sheds a lot the features and retains a simple core.
  - jjjensen90 6y ago
osrec 6y ago
I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring. I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment. I'll be watching Deno very closely these next few months!
- tannhaeuser 6y ago
  The set of core libraries like express (fka connect) + dependencies is the stdlib. It was developed in early node.js days as part of CommonJS, which was an initiative for a portable/modular server-side JavaScript runtime with many implementations besides node.js (RingoJS, Narwhal, Helma, TeaJs/v8cgi). The existence of a community-driven lib effort, the portable nature of JavaScript, and the existence of choice was the entire reason I even looked into node.js.
  - jfkebwjsbx 6y ago
    Other languages had all that, plus a better standard library, plus a type system, for years before Node was a thing. Node got popular because it enabled frontend devs that only knew JavaScript to move easily to backend, not any technical reason.
- Lunrtick 6y ago
  I definitely agree, the insane dependency chains really make me uncomfortable. However, not every project will involve pulling in such crazy stacks. I recently experimented with Hapi + TypeORM. Hapi's core goal is to use only what they directly maintain, and I think it works really well! Node_modules is still not tiny, but it's at least an order of magnitude better than what I'm used to.
- brabel 6y ago
  Deno is great ! It makes it possible for us to write TypeScript and execute it really fast, without a build system to worry about! The only thing that, to me, is a big problem, is that, even though you have types in your TS code, you're basically throwing them away at runtime, wasting huge opportunities for optimisation that even the V8 can't recover. If V8 had support for strictly typed TS code, can you imagine how fast it could get it to run?! I think that's the next stage in the evolution of JavaScript/Node/Deno: Node -> Deno -> Done.
CalmStorm 6y ago
Deno's sandbox security is somewhat similar to Mandatory Access Control (MAC) implemented by SELinux and AppArmor. But it looks like not as fine-grained as MAC. In the example: deno run --allow-net myWebserver.ts With SELinux, one can specify the port range and network interface that the application is allowed to access. It also provides audit log that can be examined by the admin. Maybe there is no need to reinvent the wheel but just use some form of MAC if you really care about security.
- Matthias247 6y ago
  From the docs at https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions: > --allow-net=\<allow-net> Allow network access. You can specify an optional, comma separated list of domains to provide a whitelist of allowed domains. So it seems to allow for a bit more fine-grained configs than just opening up everything.
- jessaustin 6y ago
  Am I wrong in thinking that this example specifically does not protect against the threat posed immediately preceding it? As in, one is running a script that foolishly imports a nefarious package that uploads tasty environmental variables to an evil server, which it can do when network access is not controlled. Well, what if myWebserver.ts imports that package? A more fine-grained approach that limited network access by source file might be valuable.
  - wwweston 6y ago
    > A more fine-grained approach that limited network access by source file might be valuable. This is what I think I'd like to see as well. The most common case isn't that I don't trust the program I'm running, it's that the level of trust for my dependencies plus their dependencies is essentially opaque.
  - pacoverdi 6y ago
    That's my impression too (see my other comment). Each package published to Deno could come with a set of declared permissions (similarly to Android apps). When importing the package in a module, Deno should detect that permissions scoped at current module level are wider than what the package requires, and automatically narrow down the list of authorized calls. This would probably be very costly. Suppose that I'm importing a function from lodash (that requires no permissions) and my module calls it repeatedly while also accessing the file system...
irjustin 6y ago
My gripe with npm was the lack of a lock file. - Yarn helped solve that, but because of its backwards compatibility to node_modules, you could not have different versions sitting side-by-side. - Node_modules could have a different version installed vs lock file and no one would know without looking. It seems Deno is able to solve the side-by-side versions and distributing the 'lock' to the file itself. The Deno team is trying to create a 'map' file to consolidate the 'distributed version' issue. Sadly, Ruby's Bundler has solved this for years and while I love TypeScript, I'm always saddened by the state of package management in the Node space. I'm not saying Bundler perfect, but its basis with canonical lock and ability to have side-by-side versions allows me not to think about that issue.
- ChristianBundy 6y ago
  Does package-lock.json not fill this void? It's been a thing for a few years IIRC.
  - irjustin 6y ago
    Partially, like the yarn.lock it only filled half the problem. The other half is being able to have multiple versions installed at the same time and freely, confidently referencing the version I want. node_modules can only have one version and it's not hard to have version drift even while having a lock. The standard answer is to do the `rm -rf node_modules` & install. Often that fixes whatever problem creeped in. Blowing away a package directory to solve problems for years should not be the answer.
    - ChristianBundy 6y ago
      > The other half is being able to have multiple versions installed at the same time and freely, confidently referencing the version I want. It's not well-known, but it is possible: "dependencies": { "sodium-native-2": "npm:sodium-native@2", "sodium-native-3": "npm:sodium-native@3" } > node_modules can only have one version and it's not hard to have version drift even while having a lock. Don't get me wrong, npm is haunted, but I use it daily can't remember having experienced "version drift". The only reason I have to `rm -rf node_modules && npm install` is that `npm update` (even with --depth) doesn't do its job, so if you want to update all deep dependencies then you have to blow up your lockfile. (Btw, if you are experiencing some "version drift" problem, I'd recommend `npm ci` as an alternative to `rm -rf node_modules && npm install`.)
fearingreprisal 6y ago
For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some of the mistakes of a terribly engineered language. Javascript should never have been considered a serious language for back-end development. Node.js to me seems like someone's 'Frankenstein's monster'-esque experiment that escaped its captivity and wreaked wide-scale havoc on the surrounding world.
- osrec 6y ago
  Terribly engineered because it's not type checked, or for some other reason?
  - petre 6y ago
    Many reasons, some of which Dart fixes. Too bad it hasn't catched on. Now it's a language to build mobile apps with. Maybe it will be usable for cross platform desktop GUIs as well. And hopefully some of its sane language features will be ported to future versions of ES. https://medium.com/flutter-community/the-ultimate-javascript-vs-dart-syntax-guide-2f7d8ad8bde6 https://medium.com/flutter-community/the-ultimate-javascript...
- hombre_fatal 6y ago
  This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.
  - thelazydogsback 6y ago
    Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node (and Deno, FWICT) lack general native or green thread support for true multi-processing without serialization to separate clusters, so you are forced to use async and timers for long-running or parallel work.
thawaway1837 6y ago
The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, with maybe some interface info. So why do people not throw the same kind of fit about nearly every other programming environment as they do for Node/NPM? And frankly why do those other environemnts not have the ridiculous security breaches we have seen in Node/NPM land? The real problem with Node/NPM i suspect is a lack of a standard library. Simply having a standard library would have greatly reduced dependency and package hell. Further, a standard library would mean people would be more willing to write a little more code rather than include a new dependency.
- fastball 6y ago
  Yeah, I feel like Deno will reduce dependency usage, and people will hurrah and say "look, using URIs as deps actually worked to make things easier!", when in reality the reason dependency hell freezes over is because Deno actually has an STL.
  - galaxyLogic 6y ago
    I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm. I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".
    - colejohnson66 6y ago
      The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills. Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.
leeoniya 6y ago
do permissions in deno propagate to all dependencies recursively? like, if i grant filesystem access to a top-level script, did all its imports just inherit that permission, too? if so, i can see this type of system being mostly worthless.
- mkj 6y ago
  Doesn't seem to limit them? Using something like Caja https://developers.google.com/caja/docs/about https://developers.google.com/caja/docs/about might work, using object capabilities rather than ambient privileges. Not sure if Deno helps at all there though.
- etaioinshrdlu 6y ago
  Yes... it would actually be quiet amazing to have different libraries in different sandboxes with defined communication channels. The browser actually does something quite a bit like this with iframes. Iframes are sandboxed and can only communicate through postMessage. There's more to it but at a simple level it looks like this. Chrome nowadays even runs iframes in a separate process! Finally... https://www.chromium.org/developers/design-documents/oop-iframes https://www.chromium.org/developers/design-documents/oop-ifr... This is actually quite impressive because it presents a decent illusion to JS that all frames are running under the same thread.
  - memexy 6y ago
    You could implement this by fine grained imports and subprocess execution. Node.js actually has a very nice sub-process communication API: https://nodejs.org/api/child_process.html#child_process_subprocess_channel https://nodejs.org/api/child_process.html#child_process_subp.... At some point I remember writing some gpg wrappers with Node.js and I remember the subprocess API being one of the more pleasant ones to work with. In the case of more stringent Deno process sandboxing, the parent process would spawn another Deno process with a smaller set of capabilities.
    - Pozzuh 6y ago
      Deno uses the web standard Worker API to implement sub processes. They are also working on fine-grained permissions for these workers [1]. [1] https://github.com/denoland/deno/issues/4867 https://github.com/denoland/deno/issues/4867
boromi 6y ago
Is the goal to have this also work for electron executables?
battery_cowboy 6y ago
> This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts FYI, I read the whole article without JS fine, thanks for making the site work without it even if it says it doesn't.
memexy 6y ago
Deno is on my list of tools to play with. It's sandboxing capabilities are the main selling point for me because it will allow executing semi-trusted/un-trusted code on private data sets. If I know that the code can't access the network or do anything fancy with the file system then I can treat the untrusted code as a pure function and know that the output will only depend on the input. This is a very desirable property and I'm looking forward to the type of code and data sharing it will enable.
- jfkebwjsbx 6y ago
  Sandboxing has been possible for many years before Deno. Running untrusted code is not popular for good reasons.
  - memexy 6y ago
    I'm aware but Deno allows more programmers to take advantage of those capabilities in a way that will make sense to them which will lead to more and better applications. I think every programmer intuitively understands what network and filesystem access means. Deno has made sandboxing much more approachable and since those capabilities are front and center instead of some hidden feature more people will take advantage of them to structure their applications.
randombytes6869 6y ago
Deno is the Java-fication of JS. I'm sure there will be Node-like tide of "JS is better than Java now that we have X" even though Deno brings JS closer than ever to Java. Despite being cynical, I don't think its a bad thing. Java does a lot of things right. Deno -> Java Runtime security options -> Security Manager. URL based packages with simple HTTP-> Maven works same way. Bigger standard library -> Java's is huge. Types -> Java, yes. Single executable -> Fatjars. All the features mentioned in this article have been in Java over a decade. Its relieving to see a JS runtime that finally gives in to enterprise niceties. Us Java devs like to crap on JS for reasons besides being "boomers". The features Deno brings were all real reasons to use Java instead of JS up until this point. Now if they would only fix threading, I would consider Deno/JS a real contender for backend dev
- SPBS 6y ago
  Funny, I thought it was the Go-fication of JavaScript. Look at the 'contributing' section of their stdlib: "deno_std is a loose port of Go's standard library. When in doubt, simply port Go's source code, documentation, and tests. There are many times when the nature of JavaScript, TypeScript, or Deno itself justifies diverging from Go, but if possible we want to leverage the energy that went into building Go. We generally welcome direct ports of Go's code."
  - randombytes6869 6y ago
    For Deno this seems like a very good choice. Pick the good parts from Go and reuse them. I applaud Deno for going its own way with the module system though... That's been a hot topic in Go for a very long time
sholladay 6y ago
I am the author of Pogo, a web server framework for Deno that has friendly APIs and is secure by default. It supports React out of the box and has the best documentation of all the frameworks. GitHub: https://github.com/sholladay/pogo https://github.com/sholladay/pogo Video tutorial: https://www.youtube.com/watch?v=Fe4XdAiqaxI https://www.youtube.com/watch?v=Fe4XdAiqaxI
- AbuAssar 6y ago
  any plans to support angular out of the box too?
  - sholladay 6y ago
    Not at the moment, but I'm open to suggestions. Angular uses some custom syntax, right? Deno supports JSX natively, which makes it easier to support React. Do you know if there is a way to use Angular's syntax in Deno? What would the server need to do to make Angular development more convenient?
- bufferoverflow 6y ago
  > "and is secure by default" Extraordinary claims require extraordinary evidence.
  - sholladay 6y ago
    I think you misunderstood me. I simply meant that the default configuration optimizes for security. For example, Deno and other frameworks listen on `0.0.0.0` by default, which is convenient for development but is not worth the security concerns, in my opinion. Instead, Pogo uses `localhost` unless you explicitly override that setting, meaning much less risk of accidentally exposing your server publicly. This is not some revolutionary feature, it's just attention to detail that I think you'll notice cumulatively. Additionally, I would like to pay for a thorough security review when we have more features and users. I doubt any of the other frameworks will do that as it's extremely rare in OSS. Of course, that means very little until it actually happens. But know that my intention is to deliver the first Deno framework that I would personally feel comfortable using in production.
warent 6y ago
This comment is a meta-critique on the blog itself. I've noticed a recent trend arising on the web of applying a text shadow to code to make it seem like it's glowing. I don't know where people started thinking this was a good idea but I hope it doesn't gain too much traction. When I saw it in this blog, I blinked and rubbed my eyes because I actually thought my vision was blurring... Another nitpick which may be totally invalid and I'm open to being educated on this. It seems odd (i.e. inaccurate) that, at the end, the myProgram.bundle.js is being called an "executable binary." It's just minified JavaScript. Is it a binary because it has been minified and optimized, or is all JavaScript suddenly considered "binary?"
- uryga 6y ago
  re: "binary", i think the article just uses the term incorrectly – it's probably intended to mean "single file thing you invoke directly". i'm guessing they didn't just say "script" bc of possible confusion with <script> tags
- marcodave 6y ago
  I'm guessing that "binary" can be interpreted as "blob of unreadable mess when opened in a text editor"
pacoverdi 6y ago
I assume that permissions are given at application level, not at module/import level? This means that if I write an application that requires filesystem access and has external dependencies, I'm essentially giving them access to the filesystem even if they don't need it. These dependencies could silently check whether they have permissions and do something fishy only if that is the case. It would be nice to be able to import dependencies in a nested sandbox but I guess it is not a simple problem.
- SCdF 6y ago
  I haven't looked into it, but TFA suggests you can do it call by call.
  - pacoverdi 6y ago
    Well I'm not sure. The doc says: Access to security sensitive areas or functions requires the use of permissions to be granted to a deno process on the command line. [1] The only other mention of permissions in documentation is that a program may query or revoke permissions. [1] https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions [2] https://deno.land/manual/examples/permissions https://deno.land/manual/examples/permissions EDIT: formatting
- fanf2 6y ago
  What deno wants is something like caja - https://en.m.wikipedia.org/wiki/Caja_project https://en.m.wikipedia.org/wiki/Caja_project - object-capability security for JavaScript. Sadly I believe the caja project was not successful because it is very hard to avoid ambient authority in JS without becoming incompatible with everything.
aabbcc1241 6y ago
The example on permission isn't great. It said the library you used cannot access your database password from env and send it over the internet unless you allow so. When you're putting database password in the env, most likely you need to permit env var and network access for your database client library. Then at the same time, the library in example can do that malicious thing. The problem here is, deno request the permission per process, not per library import
- andolanra 6y ago
  One thing you can do is explicitly revoke permissions. This allows you to start the program with more permissions and then give them up as the tasks that required them are done, e.g. allowing environment variable access at the beginning and then revoking it before you start a server: https://deno.land/manual/examples/permissions https://deno.land/manual/examples/permissions It's not as fine-grained as allowing libraries specific permissions, but it gets you part of the way there.
- curryst 6y ago
  I think the network permissions allow you to specify IP ranges it is allowed to connect to. So you could limit it to only being able to connect to the DB server. It would still be an issue for things that need global internet access, though.
marcodave 6y ago
Some random comments: - good to see native TS support - Would be nice to see a builtin maven/gradle-like standard build system, which IMHO not having it in node.js was a major let down for me. Sure, you have gulp/grunt, but having to write repetitive code (which can be buggy!) for running a compiler/test/packager? With another set of plugins? just give me some standard tool and let me call the equivalent of "mvn package", which will compile/test/package my application with sane defaults. - the dependencies-as-URL is going to be hit hard as soon as some big fish corporation wants to use Deno for some in-house projects. What if those corps disallow calling https://deno.land/my/dep https://deno.land/my/dep and pretend to use internal repo? now all 3rd party dependencies won't work unless manually modified to use the internal corp repo. - I predict that the --allow-this --allow-that will evolve in a SecurityManager-like complexity, that only the early enthusiasts will understand, and the rest will simply put the equivalent of "--allow-all" and let the ops deal with security issues
- 0-O-0 6y ago
  Build systems are generally required for frontend code and that's a bit out of scope for a project like this. Even if it wasn't - frontend landscape is wild and everchanging - arriving at sensible, useful defaults would be very hard.
ldeangelis 6y ago
One point that was not mentioned: Deno is distributed as a single binary. Combined with the security options, I think it's a great feature for small scripts in an enterprise context.
sktrdie 6y ago
I love how Browsers & Deno have shown how we can do dependency management using urls containing code (ESM). This is a huge step forward. This makes me think, is file-based code-split strategy enough? What if we'd put code (not data) behind GraphQL and request only the actual piece of code we need to use? import { foo } from 'https://graphql/ https://graphql/{ give: { me: { foo }}}'
- brabel 6y ago
  Just `import { foo } from 'https://graphql/'` https://graphql/'` is enough for that.
growlist 6y ago
I'm interested to read the content but find the writing style and the visual layout make it difficult.

166 points by harrylucas 6y ago

rvz 6y ago

Node => Deno => Done. One can simply say, 'Deno is like Node but done right'.

harrylucas 6y ago
I think its only the natural progression. there are definitely some flaws with it, it isn't perfect. However, the tradeoffs really do seem to swing in favor of deno.
- hombre_fatal 6y ago
  It's too little, too late. Deno today might have been more interesting years ago when you had to write your own Typescript definitions for every library because TS had no traction. In 2020, Deno is just a stone's throw from `ts-node server.ts`. And the permissions system lacks the granularity to be useful.
hst-m 6y ago
'node'.split('').sort().join('')
- cellularmitosis 6y ago
  its also a nice illustration of little endian vs big endian.
bitwize 6y ago
Deno : Node :: Deltarune : Undertale
- deleted 6y ago
  [deleted]
- mtm7 6y ago
  * This comment fills you with determination.

mrpopo 6y ago

> Both the browser and node.js use the same engine - the V8 engine. RIP every other engine, I guess?

harrylucas 6y ago
Oops that was definitely a mistake on my side! Good pickup though, I've updated it to include a link to a full list :)
akdor1154 6y ago
> RIP every other engine, I guess? In practice, pretty much :(
- applecrazy 6y ago
  React Native uses JavaScriptCore, the JS engine for WebKit, at runtime.
  - statictype 6y ago
    Only on iOS right? Or is it embedded everywhere?
    - soylentgraham 6y ago
      Embedded in IOS & OSX, but one of the few that's easy to get a build of (or compile) in Linux, Windows, Android Chakra also easily builds on osx, ios, embedded in windows. V8 is a PITA to build & get a build of. (Wish it wasn't)
    - quantummkv 6y ago
      Everywhere. Even the android builds use JSC or Hermes instead of V8

danenania 6y ago

Deno definitely looks interesting! All the examples I’ve seen so far are using the ‘deno’ command to run .ts or .js scripts. Can it also package standalone binaries like go/rust—-to make a cli tool, for instance? If so, how do permissions work in that scenario? Does the user need to grant permissions on every invocation or is there some way to whitelist a script/binary?

rahulete 6y ago
Packaging to standalone executable is being worked on https://github.com/denoland/deno/issues/986 https://github.com/denoland/deno/issues/986
- danenania 6y ago
  Nice! Will be interesting to see how permissions work in that case.

AtlasBarfed 6y ago

The author already inflicted one of the worst "worse is better" victories I can think of in the history of computing. Now he's fighting his own monstrosity.

harrylucas 6y ago
Author of the artcile (me) or Author of Deno?
- deleted 6y ago
  [deleted]
- ericol 6y ago
  I think he means Ryan Dahl Anecdotally, there are several languages (French, "Argentinian" Spanish to name a couple) where it's common to re arrange the syllables of the words backward-ish (More often than not for slang - argot for France, lunfardo in Argentina - uses).
  - aixi 6y ago
    What do you mean by your last sentence? The sentence makes complete sense and is not backwards translated to spanish
    - ericol 6y ago
      Hey sorry if that was not easy to understand, I was referring to the name of the thing. "Deno" is the same as "Node" with the syllables arranged backwards.
- AtlasBarfed 6y ago
  Right, of Deno/Node, not you.
dang 6y ago
Please don't cross into personal attack in HN comments. I grant you that this is borderline, but it's still dipping a toe into those black waters.

esperent 6y ago

Node with a hat and fake moustache.

dvt 6y ago

> Javascript is great. But... in saying that it has a few quirks and can work in some unexpected ways. Typescript has just as many[1] (in fact more, as it's a superset) quirks than Javascript. I like using it (and it makes JS type-safe-ish), but it's not really some kind of paradigm shift. Not sure how I feel about import maps. They are quite literally the same thing as package.json. In fact, converting between the two takes about 20 lines of code[2]. I'd bet my bottom dollar that everyone's going to use them, which is going to lead to exactly the same types of problems as Node. [1] https://blog.asana.com/2020/01/typescript-quirks/ https://blog.asana.com/2020/01/typescript-quirks/ [2] https://github.com/WICG/import-maps/issues/60 https://github.com/WICG/import-maps/issues/60

harrylucas 6y ago
100% agree that typescript has it quirks and definitely agree about import maps most likely going to be the way you use deno. However there are tradeoffs with everything you use. It really comes down to which tradeoffs are the right ones for you, which may not be the same for someone else.
com2kid 6y ago
In regards to that first link, discriminated unions are awesome in general, it is a pattern that occurs all over the place in real world code and having compiler support for it is very nice.
torb-xyz 6y ago
Frankly I find TypeScript with strict mode turned on to be a safer and saner than C# and Java because of explicitly nullable types alone. I _never_ get null pointer exceptions in my own TypeScript code. Combined with fairly strict ESLint you get something that catches a lot of problems at compile time. Of course it's still far cry from being as safe as for example Rust. And yeah the inconsistency of JavaScript/TypeScript can be frustrating for sure. I think my dream language is one that is simply TypeScript cleaned up to be made consistent and sheds a lot the features and retains a simple core.
- jjjensen90 6y ago

osrec 6y ago

I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring. I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment. I'll be watching Deno very closely these next few months!

tannhaeuser 6y ago
The set of core libraries like express (fka connect) + dependencies is the stdlib. It was developed in early node.js days as part of CommonJS, which was an initiative for a portable/modular server-side JavaScript runtime with many implementations besides node.js (RingoJS, Narwhal, Helma, TeaJs/v8cgi). The existence of a community-driven lib effort, the portable nature of JavaScript, and the existence of choice was the entire reason I even looked into node.js.
- jfkebwjsbx 6y ago
  Other languages had all that, plus a better standard library, plus a type system, for years before Node was a thing. Node got popular because it enabled frontend devs that only knew JavaScript to move easily to backend, not any technical reason.
Lunrtick 6y ago
I definitely agree, the insane dependency chains really make me uncomfortable. However, not every project will involve pulling in such crazy stacks. I recently experimented with Hapi + TypeORM. Hapi's core goal is to use only what they directly maintain, and I think it works really well! Node_modules is still not tiny, but it's at least an order of magnitude better than what I'm used to.
brabel 6y ago
Deno is great ! It makes it possible for us to write TypeScript and execute it really fast, without a build system to worry about! The only thing that, to me, is a big problem, is that, even though you have types in your TS code, you're basically throwing them away at runtime, wasting huge opportunities for optimisation that even the V8 can't recover. If V8 had support for strictly typed TS code, can you imagine how fast it could get it to run?! I think that's the next stage in the evolution of JavaScript/Node/Deno: Node -> Deno -> Done.

CalmStorm 6y ago

Deno's sandbox security is somewhat similar to Mandatory Access Control (MAC) implemented by SELinux and AppArmor. But it looks like not as fine-grained as MAC. In the example: deno run --allow-net myWebserver.ts With SELinux, one can specify the port range and network interface that the application is allowed to access. It also provides audit log that can be examined by the admin. Maybe there is no need to reinvent the wheel but just use some form of MAC if you really care about security.

Matthias247 6y ago
From the docs at https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions: > --allow-net=\<allow-net> Allow network access. You can specify an optional, comma separated list of domains to provide a whitelist of allowed domains. So it seems to allow for a bit more fine-grained configs than just opening up everything.
jessaustin 6y ago
Am I wrong in thinking that this example specifically does not protect against the threat posed immediately preceding it? As in, one is running a script that foolishly imports a nefarious package that uploads tasty environmental variables to an evil server, which it can do when network access is not controlled. Well, what if myWebserver.ts imports that package? A more fine-grained approach that limited network access by source file might be valuable.
- wwweston 6y ago
  > A more fine-grained approach that limited network access by source file might be valuable. This is what I think I'd like to see as well. The most common case isn't that I don't trust the program I'm running, it's that the level of trust for my dependencies plus their dependencies is essentially opaque.
- pacoverdi 6y ago
  That's my impression too (see my other comment). Each package published to Deno could come with a set of declared permissions (similarly to Android apps). When importing the package in a module, Deno should detect that permissions scoped at current module level are wider than what the package requires, and automatically narrow down the list of authorized calls. This would probably be very costly. Suppose that I'm importing a function from lodash (that requires no permissions) and my module calls it repeatedly while also accessing the file system...

irjustin 6y ago

My gripe with npm was the lack of a lock file. - Yarn helped solve that, but because of its backwards compatibility to node_modules, you could not have different versions sitting side-by-side. - Node_modules could have a different version installed vs lock file and no one would know without looking. It seems Deno is able to solve the side-by-side versions and distributing the 'lock' to the file itself. The Deno team is trying to create a 'map' file to consolidate the 'distributed version' issue. Sadly, Ruby's Bundler has solved this for years and while I love TypeScript, I'm always saddened by the state of package management in the Node space. I'm not saying Bundler perfect, but its basis with canonical lock and ability to have side-by-side versions allows me not to think about that issue.

ChristianBundy 6y ago
Does package-lock.json not fill this void? It's been a thing for a few years IIRC.
- irjustin 6y ago
  Partially, like the yarn.lock it only filled half the problem. The other half is being able to have multiple versions installed at the same time and freely, confidently referencing the version I want. node_modules can only have one version and it's not hard to have version drift even while having a lock. The standard answer is to do the `rm -rf node_modules` & install. Often that fixes whatever problem creeped in. Blowing away a package directory to solve problems for years should not be the answer.
  - ChristianBundy 6y ago
    > The other half is being able to have multiple versions installed at the same time and freely, confidently referencing the version I want. It's not well-known, but it is possible: "dependencies": { "sodium-native-2": "npm:sodium-native@2", "sodium-native-3": "npm:sodium-native@3" } > node_modules can only have one version and it's not hard to have version drift even while having a lock. Don't get me wrong, npm is haunted, but I use it daily can't remember having experienced "version drift". The only reason I have to `rm -rf node_modules && npm install` is that `npm update` (even with --depth) doesn't do its job, so if you want to update all deep dependencies then you have to blow up your lockfile. (Btw, if you are experiencing some "version drift" problem, I'd recommend `npm ci` as an alternative to `rm -rf node_modules && npm install`.)

fearingreprisal 6y ago

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some of the mistakes of a terribly engineered language. Javascript should never have been considered a serious language for back-end development. Node.js to me seems like someone's 'Frankenstein's monster'-esque experiment that escaped its captivity and wreaked wide-scale havoc on the surrounding world.

osrec 6y ago
Terribly engineered because it's not type checked, or for some other reason?
- petre 6y ago
  Many reasons, some of which Dart fixes. Too bad it hasn't catched on. Now it's a language to build mobile apps with. Maybe it will be usable for cross platform desktop GUIs as well. And hopefully some of its sane language features will be ported to future versions of ES. https://medium.com/flutter-community/the-ultimate-javascript-vs-dart-syntax-guide-2f7d8ad8bde6 https://medium.com/flutter-community/the-ultimate-javascript...
hombre_fatal 6y ago
This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.
- thelazydogsback 6y ago
  Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node (and Deno, FWICT) lack general native or green thread support for true multi-processing without serialization to separate clusters, so you are forced to use async and timers for long-running or parallel work.

thawaway1837 6y ago

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, with maybe some interface info. So why do people not throw the same kind of fit about nearly every other programming environment as they do for Node/NPM? And frankly why do those other environemnts not have the ridiculous security breaches we have seen in Node/NPM land? The real problem with Node/NPM i suspect is a lack of a standard library. Simply having a standard library would have greatly reduced dependency and package hell. Further, a standard library would mean people would be more willing to write a little more code rather than include a new dependency.

fastball 6y ago
Yeah, I feel like Deno will reduce dependency usage, and people will hurrah and say "look, using URIs as deps actually worked to make things easier!", when in reality the reason dependency hell freezes over is because Deno actually has an STL.
- galaxyLogic 6y ago
  I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm. I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".
  - colejohnson66 6y ago
    The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills. Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.

leeoniya 6y ago

do permissions in deno propagate to all dependencies recursively? like, if i grant filesystem access to a top-level script, did all its imports just inherit that permission, too? if so, i can see this type of system being mostly worthless.

mkj 6y ago
Doesn't seem to limit them? Using something like Caja https://developers.google.com/caja/docs/about https://developers.google.com/caja/docs/about might work, using object capabilities rather than ambient privileges. Not sure if Deno helps at all there though.
etaioinshrdlu 6y ago
Yes... it would actually be quiet amazing to have different libraries in different sandboxes with defined communication channels. The browser actually does something quite a bit like this with iframes. Iframes are sandboxed and can only communicate through postMessage. There's more to it but at a simple level it looks like this. Chrome nowadays even runs iframes in a separate process! Finally... https://www.chromium.org/developers/design-documents/oop-iframes https://www.chromium.org/developers/design-documents/oop-ifr... This is actually quite impressive because it presents a decent illusion to JS that all frames are running under the same thread.
- memexy 6y ago
  You could implement this by fine grained imports and subprocess execution. Node.js actually has a very nice sub-process communication API: https://nodejs.org/api/child_process.html#child_process_subprocess_channel https://nodejs.org/api/child_process.html#child_process_subp.... At some point I remember writing some gpg wrappers with Node.js and I remember the subprocess API being one of the more pleasant ones to work with. In the case of more stringent Deno process sandboxing, the parent process would spawn another Deno process with a smaller set of capabilities.
  - Pozzuh 6y ago
    Deno uses the web standard Worker API to implement sub processes. They are also working on fine-grained permissions for these workers [1]. [1] https://github.com/denoland/deno/issues/4867 https://github.com/denoland/deno/issues/4867

boromi 6y ago

Is the goal to have this also work for electron executables?

battery_cowboy 6y ago

> This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts FYI, I read the whole article without JS fine, thanks for making the site work without it even if it says it doesn't.

memexy 6y ago

Deno is on my list of tools to play with. It's sandboxing capabilities are the main selling point for me because it will allow executing semi-trusted/un-trusted code on private data sets. If I know that the code can't access the network or do anything fancy with the file system then I can treat the untrusted code as a pure function and know that the output will only depend on the input. This is a very desirable property and I'm looking forward to the type of code and data sharing it will enable.

jfkebwjsbx 6y ago
Sandboxing has been possible for many years before Deno. Running untrusted code is not popular for good reasons.
- memexy 6y ago
  I'm aware but Deno allows more programmers to take advantage of those capabilities in a way that will make sense to them which will lead to more and better applications. I think every programmer intuitively understands what network and filesystem access means. Deno has made sandboxing much more approachable and since those capabilities are front and center instead of some hidden feature more people will take advantage of them to structure their applications.

randombytes6869 6y ago

Deno is the Java-fication of JS. I'm sure there will be Node-like tide of "JS is better than Java now that we have X" even though Deno brings JS closer than ever to Java. Despite being cynical, I don't think its a bad thing. Java does a lot of things right. Deno -> Java Runtime security options -> Security Manager. URL based packages with simple HTTP-> Maven works same way. Bigger standard library -> Java's is huge. Types -> Java, yes. Single executable -> Fatjars. All the features mentioned in this article have been in Java over a decade. Its relieving to see a JS runtime that finally gives in to enterprise niceties. Us Java devs like to crap on JS for reasons besides being "boomers". The features Deno brings were all real reasons to use Java instead of JS up until this point. Now if they would only fix threading, I would consider Deno/JS a real contender for backend dev

SPBS 6y ago
Funny, I thought it was the Go-fication of JavaScript. Look at the 'contributing' section of their stdlib: "deno_std is a loose port of Go's standard library. When in doubt, simply port Go's source code, documentation, and tests. There are many times when the nature of JavaScript, TypeScript, or Deno itself justifies diverging from Go, but if possible we want to leverage the energy that went into building Go. We generally welcome direct ports of Go's code."
- randombytes6869 6y ago
  For Deno this seems like a very good choice. Pick the good parts from Go and reuse them. I applaud Deno for going its own way with the module system though... That's been a hot topic in Go for a very long time

sholladay 6y ago

I am the author of Pogo, a web server framework for Deno that has friendly APIs and is secure by default. It supports React out of the box and has the best documentation of all the frameworks. GitHub: https://github.com/sholladay/pogo https://github.com/sholladay/pogo Video tutorial: https://www.youtube.com/watch?v=Fe4XdAiqaxI https://www.youtube.com/watch?v=Fe4XdAiqaxI

AbuAssar 6y ago
any plans to support angular out of the box too?
- sholladay 6y ago
  Not at the moment, but I'm open to suggestions. Angular uses some custom syntax, right? Deno supports JSX natively, which makes it easier to support React. Do you know if there is a way to use Angular's syntax in Deno? What would the server need to do to make Angular development more convenient?
bufferoverflow 6y ago
> "and is secure by default" Extraordinary claims require extraordinary evidence.
- sholladay 6y ago
  I think you misunderstood me. I simply meant that the default configuration optimizes for security. For example, Deno and other frameworks listen on `0.0.0.0` by default, which is convenient for development but is not worth the security concerns, in my opinion. Instead, Pogo uses `localhost` unless you explicitly override that setting, meaning much less risk of accidentally exposing your server publicly. This is not some revolutionary feature, it's just attention to detail that I think you'll notice cumulatively. Additionally, I would like to pay for a thorough security review when we have more features and users. I doubt any of the other frameworks will do that as it's extremely rare in OSS. Of course, that means very little until it actually happens. But know that my intention is to deliver the first Deno framework that I would personally feel comfortable using in production.

warent 6y ago

This comment is a meta-critique on the blog itself. I've noticed a recent trend arising on the web of applying a text shadow to code to make it seem like it's glowing. I don't know where people started thinking this was a good idea but I hope it doesn't gain too much traction. When I saw it in this blog, I blinked and rubbed my eyes because I actually thought my vision was blurring... Another nitpick which may be totally invalid and I'm open to being educated on this. It seems odd (i.e. inaccurate) that, at the end, the myProgram.bundle.js is being called an "executable binary." It's just minified JavaScript. Is it a binary because it has been minified and optimized, or is all JavaScript suddenly considered "binary?"

uryga 6y ago
re: "binary", i think the article just uses the term incorrectly – it's probably intended to mean "single file thing you invoke directly". i'm guessing they didn't just say "script" bc of possible confusion with <script> tags
marcodave 6y ago
I'm guessing that "binary" can be interpreted as "blob of unreadable mess when opened in a text editor"

pacoverdi 6y ago

I assume that permissions are given at application level, not at module/import level? This means that if I write an application that requires filesystem access and has external dependencies, I'm essentially giving them access to the filesystem even if they don't need it. These dependencies could silently check whether they have permissions and do something fishy only if that is the case. It would be nice to be able to import dependencies in a nested sandbox but I guess it is not a simple problem.

SCdF 6y ago
I haven't looked into it, but TFA suggests you can do it call by call.
- pacoverdi 6y ago
  Well I'm not sure. The doc says: Access to security sensitive areas or functions requires the use of permissions to be granted to a deno process on the command line. [1] The only other mention of permissions in documentation is that a program may query or revoke permissions. [1] https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions [2] https://deno.land/manual/examples/permissions https://deno.land/manual/examples/permissions EDIT: formatting
fanf2 6y ago
What deno wants is something like caja - https://en.m.wikipedia.org/wiki/Caja_project https://en.m.wikipedia.org/wiki/Caja_project - object-capability security for JavaScript. Sadly I believe the caja project was not successful because it is very hard to avoid ambient authority in JS without becoming incompatible with everything.

aabbcc1241 6y ago

The example on permission isn't great. It said the library you used cannot access your database password from env and send it over the internet unless you allow so. When you're putting database password in the env, most likely you need to permit env var and network access for your database client library. Then at the same time, the library in example can do that malicious thing. The problem here is, deno request the permission per process, not per library import

andolanra 6y ago
One thing you can do is explicitly revoke permissions. This allows you to start the program with more permissions and then give them up as the tasks that required them are done, e.g. allowing environment variable access at the beginning and then revoking it before you start a server: https://deno.land/manual/examples/permissions https://deno.land/manual/examples/permissions It's not as fine-grained as allowing libraries specific permissions, but it gets you part of the way there.
curryst 6y ago
I think the network permissions allow you to specify IP ranges it is allowed to connect to. So you could limit it to only being able to connect to the DB server. It would still be an issue for things that need global internet access, though.

marcodave 6y ago

Some random comments: - good to see native TS support - Would be nice to see a builtin maven/gradle-like standard build system, which IMHO not having it in node.js was a major let down for me. Sure, you have gulp/grunt, but having to write repetitive code (which can be buggy!) for running a compiler/test/packager? With another set of plugins? just give me some standard tool and let me call the equivalent of "mvn package", which will compile/test/package my application with sane defaults. - the dependencies-as-URL is going to be hit hard as soon as some big fish corporation wants to use Deno for some in-house projects. What if those corps disallow calling https://deno.land/my/dep https://deno.land/my/dep and pretend to use internal repo? now all 3rd party dependencies won't work unless manually modified to use the internal corp repo. - I predict that the --allow-this --allow-that will evolve in a SecurityManager-like complexity, that only the early enthusiasts will understand, and the rest will simply put the equivalent of "--allow-all" and let the ops deal with security issues

0-O-0 6y ago
Build systems are generally required for frontend code and that's a bit out of scope for a project like this. Even if it wasn't - frontend landscape is wild and everchanging - arriving at sensible, useful defaults would be very hard.

ldeangelis 6y ago

One point that was not mentioned: Deno is distributed as a single binary. Combined with the security options, I think it's a great feature for small scripts in an enterprise context.

sktrdie 6y ago

I love how Browsers & Deno have shown how we can do dependency management using urls containing code (ESM). This is a huge step forward. This makes me think, is file-based code-split strategy enough? What if we'd put code (not data) behind GraphQL and request only the actual piece of code we need to use? import { foo } from 'https://graphql/ https://graphql/{ give: { me: { foo }}}'

brabel 6y ago
Just `import { foo } from 'https://graphql/'` https://graphql/'` is enough for that.

growlist 6y ago

I'm interested to read the content but find the writing style and the visual layout make it difficult.