18 ms·

Deno Is a Browser for Code

276 points by beefman 6y ago

paulryanrogers 6y ago
> The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. Guessing it uses containerization or virtualization, hopefully with no gaps in security.
- cookrn 6y ago
  I don’t know that it uses either of those tools as the built-in approach. It could have changed, but last I read, it used V8’s built-in Isolate concept to provide the sandbox and that when an Isolate is created, it is only provided the underlying system access specified by CLI flags or other options e.g. Filesystem, Network, etc...
  - lioeters 6y ago
    According to its architecture description ¹, there are no containers or virtualization involved in Deno. I found deno::CoreIsolate in the source ². Userland process isolation seem to be provided by V8 Isolate. The execution and security model remind me of recent trend in FaaS, in particular running WebWorkers (or similar), WASM, etc. Found a fascinating presentation about how V8 is used at CloudFlare ³. "..using V8 isolates instead of containers or VMs, achieving 10x-100x faster cold starts and lower memory footprints.." --- ¹ https://deno.land/manual/contributing/architecture#schematic-diagram https://deno.land/manual/contributing/architecture#schematic... ² https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd8a95419405d6bfa3dd/core/core_isolate.rs#L77 https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd... ³ Fine-Grained Sandboxing with V8 Isolates - https://www.infoq.com/presentations/cloudflare-v8/ https://www.infoq.com/presentations/cloudflare-v8/
  - gutino 6y ago
    V8 is a sanbox by default, it does not expose any I/O functions. not even to the stadart output.
- tptacek 6y ago
  It's running Javascript, not native code. You virtualize (and containerize, if you believe that's a meaningful security boundary) to handle execution of arbitrary native code --- or of runtimes, like Node.js, that proxy to arbitrary native code. The Deno runtime deliberately doesn't do this.
  - colejohnson66 6y ago
    But couldn’t the code you download easily just execute `rm -rf / --no-preserve-root`? The problem isn’t executing code from a random URL (which NPM still has); it’s that even though there’s a sandbox, there’s still ways out of it.
    - earthboundkid 6y ago
      Not in Deno. To run that, you’d need to shell out, which Deno won’t let you do without explicitly granted permission at the CLI.
      - tptacek 6y ago
        You can in Node, because Node bridges the whole platform standard library by default. Deno does the opposite: you have to opt programs into the platform capabilities you want to give them.
      - gfxgirl 6y ago
        Which you will nearly always give permission to do anything useful.
    - jdminhbg 6y ago
      Others have noted Deno has good protections around this, but I would add that it has those because running a package from NPM is in and of itself just executing code from a random URL, and that has caused plenty of problems in the past.
- maxmcd 6y ago
  https://github.com/denoland/deno/blob/9090023c33de7b64ae41425db71c9ab4d5b1237f/docs/getting_started/permissions.md https://github.com/denoland/deno/blob/9090023c33de7b64ae4142... Deno runs js in v8 and all syscalls go through the rust runtime. The limitations are pretty coarse (but i'd say a great start).
orta 6y ago
I think this is a good article, and worth the time to give it a read. When Deno was first announced I was not sold on this aspect of the system. Over time though, and after having wrote a barely-above-trivial app in Deno. I've started to come to the conclusion that Deno's form of dependency management is a fresh perspective which ties closer to how browsers work and is a welcome simplification. The article covers a few ways that you can get production/reproducible builds out of the box which is usually people's first worry.
- jppope 6y ago
  agreed
earthboundkid 6y ago
Odd that the article doesn’t mention Go. Deno works like Go. It’s slightly different in that Go added a system for version rewrites recently (“modules”), but other than that it’s the same, and if importmaps ever happen, it will be the exact same. Also Deno has a command line fallback for its version of GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. But other than cosmetic differences, it’s pretty much identical to Go.
- maxmcd 6y ago
  I've been skimming the arguments so I might have missed something big, but isn't the key distinction that Deno can take anything from a URL? Go's "go get" is backed by version control systems, but you could freely point your deno at "http://dangerous.com/evil.ts" http://dangerous.com/evil.ts". I thought the concern was about the potentially problematic flexibility.
  - earthboundkid 6y ago
    Go has a system for telling where to fetch based on the URL response. You can basically send anything if you are evil, but Go modules keep a hash of seen content (what Deno calls a lockfile), so you’d notice that it changed.
  - 14u2c 6y ago
    Isn't that the advantage though, that you can do exactly that without concern. > deno run --allow-write=~/only-evil-here http://dangerous.com/evil.ts http://dangerous.com/evil.ts
- parhamn 6y ago
  > GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. This gave me a laugh but it’s not fair! I’d guess most of the GOPATH outcry was the annoyance around managing automated and other non-dev environments.
  - 6y ago
oddthink 6y ago
This may be inviting downvotes, but I still don't understand the use-case of Deno. Why would I use this over something like Python? In Python, I find I can do most things I want with the standard library plus a handful of well-known packages, so even just downloading the tarballs and installing manually isn't all that onerous. Why do I want a "browser for code"? I may just be out-of-touch, as a purely backend/machine-learning/quality engineer. Clearly, this is a real need in the front-end / JavaScript space, but coming from the outside I just don't quite understand yet the value proposition here. Can anyone explain?
- root_axis 6y ago
  if you have everything you need in python then you're not really the target audience. deno is an answer to the current state of the npm ecosystem. Not that you shouldn't switch to deno from python, but you should only do that if you already had a reason why you wanted to switch to node from python.
- paxys 6y ago
  Your question really is "why use server-side JS over Python" and that doesn't have a real answer, just never-ending arguments.
  - mst 6y ago
    Let's paint it blue!
- shriek 6y ago
  > Clearly, this is a real need in the front-end / JavaScript space I think you answered your own question there. If you already know JS/TS and want to dive into server code then this is more approachable than learning a brand new language.
- ordinaryradical 6y ago
  >Why would I use this over something like Python? That's more a js vs python question than a Deno question so I don't think you'll find many answers here as we'd veer off-topic. >I find I can do most things I want with the standard library A standard library exists for Deno as well. Code from any URL is not an argument against having a standard library. The distinction being made is whether or not package management should be brittle and baked into the programming model to accept only one source of truth vs. any. Any source of truth has the advantage of letting better solutions evolve and reveal themselves over time, which is great for longevity, standards, etc. etc. > Why do I want a "browser for code"? My understanding is that this a lot to do with reproducing how front-end code behave "in the wild." If you have a full browser, you aren't tricking your programming model into thinking it's being run in a browser. I think this has tooling advantages in the short term (i.e. simplicity) and more subtle ones in the long term.
xixixao 6y ago
2 reasons why this could be a faulty approach: 1) Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This naturally invites a single central repository over the decentralization of the web. 2) Very few people publish their own websites. Why? It's complicated, costly. This is why Facebook and Twitter fair so well. So even the decentralized web eventually diverges onto a centralized platform that solves the hosting problem. Why reintroduce the problem when there is already a fairly un-problematic central registry? If the security model is the real winner, I don't see why it could not be back-ported to Node - it likely will be if Deno takes off in any way.
- jclulow 6y ago
  I don't have an opinion on Deno per se, but I quibble with this part of your point: > Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This implies that there is in fact one good way to do most things, but in practice different people want different trade-offs and forcing them into a single codebase isn't possible when the options are mutually exclusive. You can't have a library that is simultaneously strict about types (panics if you pass a string instead of a number, say) and forgiving about types (automatically coerces strings to integers or vice versa).
paxys 6y ago
The key paragraph: > The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. You, the person invoking the code, get to tell that code what it can and can’t do, externally. Also, like a browser, code can ask you permission to do things, which you can choose to grant or deny. The big problem with Deno is that permissions, once granted, apply to every imported URL. You cannot ask it to let one script access the file system, another access network and the rest of them run fully sandboxed. This makes it so that you either only import scripts you already fully trust (making the permission system useless) or don't allow any access (making the ecosystem useless).
- chii 6y ago
  > ask it to let one script access the file system, another access network and the rest of them run fully sandboxed. this is actually quite a difficult problem to solve. You're balancing the security needs with usability. Browsers have an advantage on this aspect, because they can make the assumption that the webpage does not require filesystem access. i think fully sandboxed OS-esque security model is the only way this can work. Like on android, where each app sees only their own filesystem, and app-to-app interaction is done via a permission based system that the user has to approve.
  - bryanrasmussen 6y ago
    They could have maybe looked at E for some inspiration on how to solve the problem http://erights.org/ http://erights.org/
  - aabbcc1241 6y ago
    On android the apps has access to shared folders. For example my music player can scan and read files under /mnt/sdcard/Android/data/com.dropbox.android/files/ It maybe more isolated if it follows the nix file system model?
- freeopinion 6y ago
gfxgirl 6y ago
Deno seems like the next mongo db fiasco waiting to happen. Insecure by default. The fact that it doesn't grant permissions by default is irrelevant, servers need permissions to function (access databases, access files, access the network, etc...). The incentives are all wrong. If I MITM a website at best I gain access to the data of the few users that pass through my part of the net. If I MITM something Deno is using I get access to the server. That's orders of magnitude more data I get access too and therefore the incentive to MITM (or other) is much much MUCH higher.
- chrisco255 6y ago
  I agree, they should force cached, sandboxed fetching by default and have people opt in to dynamic fetching.
draw_down 6y ago
I think this is pretty good. I like the use of URLs as identifiers for your dependencies, just because it’s so unambiguous. I also like re-exporting deps manually. My only real point of discomfort is how the runtime seems to be a bit too closely tied to the actual download and transport of these files/URLs. Like, importing from https implying all further imports are from https is nice, I guess, but is really stretching the browser metaphor imo. I guess that is really my main point of contention, I agree with the security model but I don’t agree that websites are particularly analogous to code dependencies.
gigel82 6y ago
You hardcode the dependency version in the actual URL string in JavaScript code? How in the world is that manageable? I run `npm update` once a week and it brings down a dozen or so updates (occasionally `npm outdated` as well with manual testing). I bet we'll have a bunch of competing standards for "dependency management" in deno coming online really soon, because there's an obvious need for that. Also, are dynamic dependencies a thing? Can I run some code to decide (at runtime) whether I import this.package or that.package? Holy hell... with test coverage the way it is in most projects, that's going to blow up really fast.
- PudgePacket 6y ago
  > You hardcode the dependency version in the actual URL Websites have been doing this for .. 20 years? It's quite a different paradigm, yes.
  - godot 6y ago
    Before the age of React, when I used to work on decent-sized web sites' frontend, there would typically be maybe a handful of external dependencies; usually just jquery; and later on perhaps a few other powered-by-jquery utility that gives you maybe a carousel or other UI elements. Most of the rest of the JS code is written in-house. Working with node backend in the past few years, most of my backend services typically list a dozen dependencies or so in package.json, and those in turn have a bunch of other dependencies of their own. Among these there's probably lodash, some schema validator (ajv/joi/etc.), maybe an xml parsing/building lib, some unit testing framework, db query builder, and so on. I'm not saying this to be pro-node and attack deno or anything; I just feel like the statement of "websites/browsers have been doing this forever" isn't exactly an apples to apples comparison.
  - chrismorgan 6y ago
    A major difference: transitive dependencies. In the old days, jquery.foo.bar.js would say “make sure you’ve loaded jquery.js and jquery.foo.js first”, and it would be up to you to decide which versions of them to use. Under Deno, modules will declare their exact dependencies and I suppose you the caller can’t control them. Or else they could devolve into some form of dependency injection. This could lead to many copies of a library being loaded and included, rather than just one via deduplication as other packaging systems tend to do. (The article talks about the potential need to remap dependencies, which could allow you to resolve this sort of duplication manually, but says that the current implementation should probably be avoided.)
swagonomixxx 6y ago
Can someone explain to me what problem that Deno and Node are trying to solve? Is JavaScript really such an amazing language that we need to use it for backend applications now? What niche is it filling that is unfilled by other, more sanely designed programming languages? I'm not trying to be obtuse or anything, I'm just really curious as to why anyone would use Deno (or Node for that matter) for a project when I can think of at least 4 alternatives that are more sane (Go, Python, Rust, Java, and many more out there, just that these are the ones I'm most comfortable with).
- chrisco255 6y ago
  Node.js has been used in production for over a decade. Some of the most popular applications of the past decade have been built on Node and in 2020, JavaScript is the most popular programming language.
- franciscop 6y ago
  This seems like trolling more than a genuine question, but I'll answer in case it is genuine. It makes it easier for fullstack developers since it's a single language both in the front-end and back-end. You only need to learn once how `JSON.parse()`, `atob`, classes/prototypes, etc. work, and not worry about language inconsistencies making errors. It is decently efficient (not the best, not the worst), fairly readable (I'd say on the upper side). The three main disadvantages IMHO are: - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages - Node.js standard library is optimizing for flexibility instead of conciseness or completeness, so there's quite a bit of manual gruntwork involved (not the worst of those mentioned though). - Right now the ecosystem is in a major migration from `require()` to `import`. The last large migration like this was from Callbacks to Promises, and IMHO it went very well. As someone who is very comfortable with Javascript, and was comfortable with PHP and Python back in the day, I would not trade Node.js for any of those. I am thinking most of the time about what I want to achieve in a coherent way, and not fumbling with pointers.
  - mekster 6y ago
    > - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages Grasping isn't the hard part, it's just about placing callback functions on executed functions that allows callbacks. What's so bad is that it is async by default and now you need million "await" and "async" keywords all over the place. I wish it would be sync by default and for those rare cases where you really want it async, you would add a keyword.
jppope 6y ago
Its very interesting to me the level of skepticism that is being shown towards Deno. Whether or not you agree with the approach, you have to agree with the underlying problems that Deno is trying to solve. Furthermore I agree with the article in that there is a paradigm shift here, which should be given a chance. I for one am happy about the url imports for a variety of reasons, but top on my list is that it will (in theory) reduce the total amount of code people are using from other sources, and (in theory) will make developers more aware of what they do choose to import. All of this should reduce bloat and award open source maintainers that solve novel problems in a clear & concise way.
- emerongi 6y ago
  There are better ways to reduce bloat. Gitlab can do web asset analysis and throw warning signs when your JS file goes over a certain size. Of course, in server-side applications the use-case would be different, but the idea remains the same: do not depend on developers doing the right thing every single day, depend on an automated system if something like this is crucial to you. The URL import completely throws away all the goodies that great package managers have. Being able to manage sub-dependency versions is a big one. I do not understand how people are OK with throwing those away. Either they have never encountered issues that stem from dependencies or they just don't care. Deno could technically add layers on top that make dependency management easier, but then we are back to NPM.
  - deleted 6y ago
    [deleted]
- fastball 6y ago
  It's very interesting to me the level of enthusiasm being shown towards Deno. It is clearly being embraced more than it has shown its worth.
- jfkebwjsbx 6y ago
  > Whether or not you agree with the approach, you have to agree with the underlying problems that Deno is trying to solve. Perhaps, but that does not mean Deno is the solution. > there is a paradigm shift here, which should be given a chance. Why? If I come up with a novel approach for something, I am the one that has to show it works. > I for one am happy about the url imports for a variety of reasons, but top on my list is that it will (in theory) reduce the total amount of code people are using from other sources I'd say it is the other way around. It encourages an even crazier approach to dependencies that the NPM mess already is.
AbuAssar 6y ago
The node_modules folder with its tenths of thousands of files is killing my ssd! as it is present in every node project I have, and consumes a gigantic number of io operations. Thus I’m very glad that deno didn’t continue this tradition.
- Epskampie 6y ago
  Replace ‘node_modules’ with ‘deno cache’ and presto! you’re in the future.
  - arcatek 6y ago
    Yarn already removes the need for node_modules without requiring to change interpreter and APIs, though.
  - AbuAssar 6y ago
    Not true deno cache contains only the js files, and each one of them includes all its dependancies in the same file. OTOH node modules contains every package in the dependency tree, and each package has many files not related to the required js file.
- mekster 6y ago
  You might as well live without GUI as those involve "gigantic" amount of IO as well. Why are people being so sensitive with hardware resource? Like how Electron is killing your machine...
  - AbuAssar 6y ago
    ssd has limited number of write operations, while node_modules writes many many files to the disk. And as mentioned in the article you repeatedly remove and recreate it to fix “problems”
    - lolc 6y ago
      Even with write amplification a node_modules is not typically going to cause more than a few gigabytes write load. So with max TBW being somewhere in the hundreds of terabytes for current SSD, we're looking at hundreds of thousand node_module rewrites before the drive gives. Unless you're rewriting your node_modules every other minute on an old SSD I recommend finding something else to worry about.
keymone 6y ago
The holy grail of package management is absence of packages and versions, but distribution via signature-addressable code. In the end it’s all just functions that take arguments and return values. They should be the minimal unit of distribution. Potentially even with precompiled bytecode signed by some trusted compilation provider.
- saagarjha 6y ago
  You still need to keep track of things that are mutually incompatible.
  - keymone 6y ago
    Not really, because you ship every required version of every function. Functions aren’t incompatible with functions they don’t use.
- cousin_it 6y ago
  It's always fun to solve half of a problem perfectly and ignore the other half. But then you wonder why it doesn't take the world by storm. (Or sometimes it does, if you were pushy enough, and everyone has to live with your half-solution.) The problem is not only about units of distribution, but also about units of interoperability. The unit should be a group of functions that share common types, naming conventions and design decisions, and have no weird edge cases when used together, unlike some mishmash cobbled together from the internet. In other words, a library. It's like Coase's "Nature of the firm": libraries exist to lower interoperability costs internally, same as firms exist to lower transaction costs internally. The right size and version policy for libraries is a non-trivial question. I think the npm culture has settled on the wrong answer to that question, and that's why we end up with these complicated dependency trees.
  - keymone 6y ago
    You only think it needs to be this cohesive thing with types and global definitions and conventions because that’s the current way to approach software development. There is more than one way to do it. In your code a library is completely ephemeral concept, it is only made concrete due to the fact that you have a reference to it in your package manager’s file. In your code however, that library is defined by functions you import and use. Do what stops you stripping the rest away? And if stripping is fine, what’s wrong with turning that upside down and just not having a concrete library as a unit of distribution? That set of functions can be built out of single repository and share a component in some unique reference scheme, but any subset of it is no less functional - each function still has a spec of what other functions it needs to do it’s job and those requirements are satisfied by your build system and everybody is happy. As for types, in vast majority of circumstances you don’t need anything beyond what’s described in EDN spec, which is basically json but more sensible. And if you do need more types - you just require functions that produce and manipulate them and you refer to those types using that same uniquq reference scheme to describe your function signatures.
forty 6y ago
If they wanted to fix something on dependency management, they could have started by adding a way to sign the code/packages. Indeed browsers don't allow to sign pages, which means anyone from the hosting provider to the CDN to the mitm corporate proxy can inject any code they want. It sucks and I'm not sure why "Deno is a browser for code" seems to be a good thing.... Hopefully something like google signed http exchange will fix that in the future for browsers at least.
- ccmcarey 6y ago
  Unless I'm missing what you're referring to, that's not true at all - HTTPS is secure and uses certificates to sign and encrypt traffic.
  - kbenson 6y ago
    I think they are referring to signed content, not singed transport. That is, this blob of content/code I downloaded is signed and I have more trust in it than in some other piece of content/code that's from a server meant to house hundreds or thousands of different people, much less modules. You can trust that the developer meant to release that, and it's not some hack of the system, and you can also require that the code comes from a vetting third party that reviews all modules and updates and signs it itself (i.e. what Linux distro package managers do).
  - emerongi 6y ago
    I think OP is arguing: - Host can change what is in a package at any time. In case Deno calculates a hash on your machine (e.g. package-lock.json), it's not as bad, but still without a signed package you can't be sure that it was the author that released the code in the first place. - Host <-> CDN usually happens over HTTP. Often it is the CDN where HTTPS is terminated. Technically the CDN can deliver whatever code to you. - Corporate HTTPS proxies exist. With a proxy like this, it can also replace the code with whatever it likes.
    - brabel 6y ago
      > In case Deno calculates a hash on your machine (e.g. package-lock.json), it's not as bad, but still without a signed package you can't be sure that it was the author that released the code in the first place. If you trust the URL is in a (sub)domain controlled by the author and it's a HTTPS URL, that's as much guarantee as a signature.
forty 6y ago
The issue I have with Deno is not only comparing to NodeJS. If you might use Deno it means you are open to switching platform and even language of you were not going TS already. And if you are at this point, you might as well choose any plateforms, for example one that use a better (with stronger types) programming language and a bigger ecosystem (scala, swift, rust, F#, java, ocaml, kotlin... At this point I feel nearly any other languages fit this description ^^). I have been doing Typescript for a while now, it's probably as good as it could be doing what it does (being a JS add on), but if you don't have this constraint, there are many better options.
- ex3ndr 6y ago
  Please, scala could be so different that you can spent years learning it and still don't understand a lot of things. Swift is ok, but ARC is a nightmare. Good for mobile though. Rust is really for C++ guys for specific use cases. F#/Ocaml is cool languages, but good luck hiring fast if you need to. Kotlin probably best, but in fact it works with decent performance only on JVM. Native is still 15x times slower than JS. TS is a first class language and have bigger ecosystem anyway than, say, F#. etc etc
  - chrischen 6y ago
    I'd like to add that the ecosystem around TS/JS is huge, even allowing you to do interop with both F# and Ocaml on both frontend and backend code.
  - saagarjha 6y ago
    I’m going to skip over the other stuff, but > Native is still 15x times slower than JS. Surely you meant the other way around?
    - cercatrova 6y ago
      https://discuss.kotlinlang.org/t/kotlin-native-performance/17823 https://discuss.kotlinlang.org/t/kotlin-native-performance/1... Seems Kotlin native can be 100x slower than its JVM version. It's still under development so this can of course change.
marcus_holmes 6y ago
I still think that sandboxing dependencies is the wrong answer to this problem. (first - the problem is trusting dependencies. How to spot malicious code in a dependency, and stop an evil upstream maintainer from doing bad things to your site) This solution slows down the system at run-time (and also never quite solves the problem - sandboxes are pretty leaky. The history of browser extensions trying to do the same thing is a good example). I'm not really sure what the solution is. I have some ideas, but they're mostly about changing the culture around coding, rather than technical.
- lolc 6y ago
  Having sandbox restrictions available allows deeper defence. When it comes to running other people's code, VM restrictions provide a solid layer of protection. At work we're transitioning our NPM scripts to run in containers. This is very cumbersome. But the extra layer protects dev homedirs from rando NPM authors.
pjmlp 6y ago
The first time I dealt with dependencies written directly in code was with Groovy. It wasn't a good idea back then, it wasn't a good idea in Go and it isn't definitly a good idea in Deno.
- vlaaad 6y ago
  Care to explain why?
  - pjmlp 6y ago
    Because it ties the source code to the origin of the dependencies, forces code rewrites that don't scale across all dependencies and aren't enterprise friendly for using internal IT vetoed repositories. Just because a dependency changed location I should not be obliged to touch a single character of the source code.
    - brabel 6y ago
      In the case of Groovy that OP mentioned, that's wrong. This is what it looks like in Groovy[1]: @Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE') import org.springframework.jdbc.core.JdbcTemplate This provides the dependency's coordinates... but not where it comes from. You can define where it comes from by configuring Repositories (normally done by modifying the M2 settings file). This is how Java has always done it in Maven and Gradle, even Ant long time ago. And this works really well! Never seen anyone complaining about how that works. [1] http://docs.groovy-lang.org/latest/html/documentation/grape.html http://docs.groovy-lang.org/latest/html/documentation/grape....
      - pjmlp 6y ago
        I am the OP and you forgot this little detail, @GrabResolver(name='restlet', root='http://maven.restlet.org/')
        brabel 6y ago
cercatrova 6y ago
Interesting, so by making dependencies in the code itself, which is more obtuse than using node modules, we might see fewer overall packages being used by developers, and more implementations from scratch. No more gigabyte sized node modules! I'm looking forward to this.
- searchableguy 6y ago
  Right! https://deno.land/x/is_url https://deno.land/x/is_url https://deno.land/x/blox https://deno.land/x/blox https://deno.land/x/deno_flatten https://deno.land/x/deno_flatten https://deno.land/x/ende https://deno.land/x/ende https://deno.land/x/humanize_url https://deno.land/x/humanize_url There are many others. I don't know why people aren't looking into std (which provides most of the functionality) or using regex where it doesn't make sense given deno is a browser.
  - satvikpendem 6y ago
    Well hopefully people find it too annoying to use deno modules and we get some sanity in development.
sktrdie 6y ago
All these "features" of Deno are super cool, but why reimplement a runtime from scratch :( Can we not benefit in Node from what I essentially see as "package.json not mandatory" - which I think is already achievable with ES Modules - and "better permissions model"? Maybe this can be seen as the effort from several years ago where a project "io.js" branched out of Node as trying to implement certain things the community didn't like. Then after a few years they were implemented into Node and io.js "died off". Although io.js had always the intent of being compatible with Node, so that definitely changes things.
- petercooper 6y ago
  Some of what Deno does can be done in Node or people are trying to implement it (I've seen some proofs of concept around the way modules are included). However, it seems that being able to write the runtime in Rust has been a big deal here as it dramatically changes how the runtime is distributed and the developer experience of writing extensions for it versus Node.
  - sktrdie 6y ago
    How is choosing between Rust and C++ as the language in which the thing is written in, an important thing to the users who only care about the JS/TS interface?
    - mst 6y ago
      Because, in the long run, rust is a much better language for writing this in, and will enable faster addition of features for the JS/TS interface and more certainty that the security level stuff is actually secure.
macca321 6y ago
Seems odd that they don't support an equivalent of the integrity attribute.
sholladay 6y ago
To the people who are skeptical of Deno, I would urge you to have patience and try it out. Deno is a young tool and it will take time to develop the features that you take for granted in other systems. But Deno gets a lot of things right. I already love using it day to day. I remember using Node when it was this age and thinking it was the future, too. And it was. But as with Deno now, there were problems. In fact, Node was far worse in many ways. npm was extremely unstable back then, for example, which often made it impossible to use. Deno doesn't have that problem. Node had to create libraries from scratch and invent a ton of non-standard things along the way to do it. Deno is built on web standards but can also leverage many of the existing Node libraries by using std/node (the Node compatibility layer) or with jspm.io, for example. Yes, there's the occasional quirk or missing library, but it's already easy to be productive with Deno and it's a lot of fun.
- tannhaeuser 6y ago
  > Node had to create libraries from scratch and invent a ton of non-standard things along the way to do it. Deno is built on web standards but can also leverage many of the existing Node libraries by using std/node (the Node compatibility layer) or with jspm.io, for example Node.js is based on CommonJS [1] which defines the require() semantics for CommonJS/node.js modules as well as core libs/APIs such as JSGI (for express.js or node core http middleware) and others. When node.js was new, there were many JavaScript app server projects such as helma, v8cgi/TeaJS, and others, and CommonJS was very much a community effort. [1]: http://wiki.commonjs.org/wiki/CommonJS http://wiki.commonjs.org/wiki/CommonJS
  - specialist 6y ago
    The inability to import (requires) modules using relative paths drove me nuts while using nodejs. I hope deno fixes that.
einpoklum 6y ago
The post sounds rather Javascript-specific, or NPM-specific. How well does that apply to other languages? Especially compiled ones?
soapdog 6y ago
Just for the kicks, I tried using deno for a task at my day job. We had a need to extract records from a database into a textual format to be processed by other tools later. This is the typical task for a throwaway script which can be written in basically any scripting language. There is nothing in the task that called out for deno but I wanted to try it out and so I did. I basically worked on the script iteratively, doing small changes, running it, checking the output, fixing things and running again. No bundler, no complex NPM tasks. Just a simple spaghetti JS and a single binary engine to run it. It was a very refreshing experience. Using URL imports was pretty nice, I really like working like that since my preferred JS environment is not NodeJS but the browser. I can see myself transitioning all those small tools and throwaway scripts I'd do in NodeJS to Deno. People relying on NodeJS for servers and tooling for their client-side webapps might need to wait a bit longer, but for doing small tasks and scripts, I think it is quite ready and better than NodeJS IMHO. These are also good projects to give you a feel for the new runtime.
- jfkebwjsbx 6y ago
  For small scripts there are many languages out there which are better, with a proper standard library and pre-installed runtimes in virtually every machine. Why would someone want to use a new language and a new runtime in production scripts is beyond my understanding. Just write Python for those. Even Perl, awk or sh would be better options, and that is saying something...
  - searchableguy 6y ago
    Well I can think of few. For one, if you are writing a script with external dependencies, it's more work than deno to distribute them. For python, you would need pip. Can you install any script from arbitrary urls using pip? I am not sure but I don't think you can. You also have to declare your deps for pip to figure out. With deno, it's just deno run -A url to script since dependencies are declared in the code with their respective url or file location.
    - jfkebwjsbx 6y ago
julvo 6y ago
The two most frequent arguments against using URLs instead of npm packages seem to be: 1) Security: What if someone changes the code behind a URL? 2) Hard-coded versions in application code I don't think these arguments are valid. For 1) you can always limit the URLs you use to hosts like jsDelivr or unpkg and reference npm packages directly. In this case instead of trusting only npm to send you the code you requested, you're now trusting the CDN as well. Potentially even better could be to import scripts from Github directly. For 2) a simple solution could be to have a deps.ts file for your project where you import from single-version URLs and export the dependency version-unaware. Now your versions are not scattered throughout your application code. To me URLs seem like a nice (because compact and universal) interface for dependencies which allows decoupling your package management from your runtime.
- jfkebwjsbx 6y ago
  So, in order to solve 1) and 2), we should return to what every other language does? That sounds like a design mistake... What do you mean by "URLs are compact"? How can a URL be compact compared to the same URL in some sort of dependencies file? Unless you use the dependency once, of course, which is rare. URLs and explicit versions in the import also encourage you to use several versions of the same dependency in your code, which is a very bad idea. NPM’s model of referencing packages from central repositories is bad for many reasons proven over the years. But referencing GitHub scripts and arbitrary URLs is even worse.
  - julvo 6y ago
    URLs are compact as in a single string they specify everything you need to locate and use the dependency and you don't need any context, like a specific dependency manager (incl some sort of dependency file). I guess I mean compact as in self-contained, not necessarily short.
    - jfkebwjsbx 6y ago
      That’s fair and I’d agree it could be a useful property for scripts and even small apps if all code was trusted and all networks had perfectly availability. Sadly, that is not the case, which is why I don’t see the advantage of going "the browser way" for local scripts.
vanderZwan 6y ago
Clear article, I honestly don't have much to add to the main thesis of it, other than that I'm very curious to see how well the arguments will hold up when faced with "real world" usage, and how Deno will evolve. But if I may indulge in a bit of bike-shedding on the side, does anyone else think that the repeated URLs in the example dependency tree are a bit noisy and hide the deeper structure of the dependencies? https://deno.land/x/oak/examples/server.ts ├── https://deno.land/std@0.53.0/fmt/colors.ts └─┬ https://deno.land/x/oak/mod.ts ├─┬ https://deno.land/x/oak/application.ts │ ├─┬ https://deno.land/x/oak/context.ts │ │ ├── https://deno.land/x/oak/cookies.ts │ │ ├─┬ https://deno.land/x/oak/httpError.ts │ │ │ └─┬ https://deno.land/x/oak/deps.ts │ │ │ ├── https://deno.land/std@0.53.0/hash/sha256.ts │ │ │ ├─┬ https://deno.land/std@0.53.0/http/server.ts │ │ │ │ ├── https://deno.land/std@0.53.0/encoding/utf8.ts │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/bufio.ts │ │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/util.ts I'm not entirely sure what would be the ideal alternative presentation though. Perhaps something along the lines of one of these two mock-ups I just edited by hand: https://deno.land/ └─┬ x/oak/examples/server.ts ├── std@0.53.0/fmt/colors.ts └─┬ x/oak/mod.ts ├─┬ x/oak/application.ts │ ├─┬ x/oak/context.ts │ │ ├── x/oak/cookies.ts │ │ ├─┬ x/oak/httpError.ts │ │ │ └─┬ x/oak/deps.ts │ │ │ ├── std@0.53.0/hash/sha256.ts │ │ │ ├─┬ std@0.53.0/http/server.ts │ │ │ │ ├── std@0.53.0/encoding/utf8.ts │ │ │ │ ├─┬ std@0.53.0/io/bufio.ts │ │ │ │ │ ├─┬ std@0.53.0/io/util.ts https://deno.land/x/oak/examples/server.ts ├── https://deno.land/std@0.53.0/fmt/colors.ts └── https://deno.land/x/oak/ └─┬ mod.ts ├─┬ application.ts │ ├─┬ context.ts │ │ ├── cookies.ts │ │ ├─┬ httpError.ts │ │ │ └─┬ deps.ts │ │ │ ├── https://deno.land/std@0.53.0/ │ │ │ │ ├── hash/sha256.ts │ │ │ │ └─┬ http/server.ts │ │ │ │ ├── encoding/utf8.ts │ │ │ │ ├─┬ io/bufio.ts │ │ │ │ │ ├─┬ io/util.ts I'm sure there are good arguments to be made against both of these options as well - plus I just came up with this on the spot, I don't even know which "rules" would generate such a tree.
talkingtab 6y ago
The npm registry is like a rickety bridge across a chasm. Every day I cross that bridge because of how much time and work it saves me, but I am well aware that the bridge might fall, especially with Microsoft now in charge. Claiming that I don't need a bridge does not help me. Claiming that Deno is agnostic about bridges is fine. If someone is looking for a startup idea, here is a perfect opportunity to build a better bridge - one that works with Deno.
jolux 6y ago
I’m still not sure how this addresses Laurie Voss’s point about left-pad. Does the caching and lock file happen by default?
zubairq 6y ago
Deno is awesome. We had a similar idea at Yazz Pilot and are currently building out the ability to import a subset of Javascript code from a URL. Currently it only supports code of the form: pilot https://raw.githubusercontent.com/zubairq/pilot/master/start.js https://raw.githubusercontent.com/zubairq/pilot/master/start...
diffrinse 6y ago
Feel like it would've been useful to require a manifest.json or some such that spec'd required permissions right next to the deno package on the FS, in the web server web root. This is not different from manifests for Web Extensions. Then anyone could write their own CLI to download and cache packages but have their own "excluded permissions" list that throws/rejects packages that overreach or could potentially overreach. Now package writers have a feedback metric for getting as granular as possible with that access their package needs. Even better, anyone could build server infrastructure that does not the client-side validation bit for package consumers with their own attendant CLI tool. It looks to me Deno opens the possibility of multiple NPMs, which is a good thing over the de facto monopoly NPM exerts today.
dzsekijo 6y ago
For example https://deno.land/x/ https://deno.land/x/ is effectively nothing but a URL redirect server, where it rewrites URLs to include a git commit-ish reference in the redirected URL. So https://deno.land/x/oak@v4.0.0/mod.ts https://deno.land/x/oak@v4.0.0/mod.ts becomes https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.ts https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.t..., which GitHub serves up a nice versioned module. Thus http://deno.land/x/ http://deno.land/x/ is the de facto central registry. I'm yet to see how it makes a difference whether the logic of resolving a package name to a concrete version of the package is baked into command line tooling or a web service.

276 points by beefman 6y ago

> The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. Guessing it uses containerization or virtualization, hopefully with no gaps in security.

cookrn 6y ago
I don’t know that it uses either of those tools as the built-in approach. It could have changed, but last I read, it used V8’s built-in Isolate concept to provide the sandbox and that when an Isolate is created, it is only provided the underlying system access specified by CLI flags or other options e.g. Filesystem, Network, etc...
- lioeters 6y ago
  According to its architecture description ¹, there are no containers or virtualization involved in Deno. I found deno::CoreIsolate in the source ². Userland process isolation seem to be provided by V8 Isolate. The execution and security model remind me of recent trend in FaaS, in particular running WebWorkers (or similar), WASM, etc. Found a fascinating presentation about how V8 is used at CloudFlare ³. "..using V8 isolates instead of containers or VMs, achieving 10x-100x faster cold starts and lower memory footprints.." --- ¹ https://deno.land/manual/contributing/architecture#schematic-diagram https://deno.land/manual/contributing/architecture#schematic... ² https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd8a95419405d6bfa3dd/core/core_isolate.rs#L77 https://github.com/denoland/deno/blob/2610ceac20bc644c0b58bd... ³ Fine-Grained Sandboxing with V8 Isolates - https://www.infoq.com/presentations/cloudflare-v8/ https://www.infoq.com/presentations/cloudflare-v8/
- gutino 6y ago
  V8 is a sanbox by default, it does not expose any I/O functions. not even to the stadart output.
tptacek 6y ago
It's running Javascript, not native code. You virtualize (and containerize, if you believe that's a meaningful security boundary) to handle execution of arbitrary native code --- or of runtimes, like Node.js, that proxy to arbitrary native code. The Deno runtime deliberately doesn't do this.
- colejohnson66 6y ago
  But couldn’t the code you download easily just execute `rm -rf / --no-preserve-root`? The problem isn’t executing code from a random URL (which NPM still has); it’s that even though there’s a sandbox, there’s still ways out of it.
  - earthboundkid 6y ago
    Not in Deno. To run that, you’d need to shell out, which Deno won’t let you do without explicitly granted permission at the CLI.
    - tptacek 6y ago
      You can in Node, because Node bridges the whole platform standard library by default. Deno does the opposite: you have to opt programs into the platform capabilities you want to give them.
    - gfxgirl 6y ago
      Which you will nearly always give permission to do anything useful.
  - jdminhbg 6y ago
    Others have noted Deno has good protections around this, but I would add that it has those because running a package from NPM is in and of itself just executing code from a random URL, and that has caused plenty of problems in the past.
maxmcd 6y ago
https://github.com/denoland/deno/blob/9090023c33de7b64ae41425db71c9ab4d5b1237f/docs/getting_started/permissions.md https://github.com/denoland/deno/blob/9090023c33de7b64ae4142... Deno runs js in v8 and all syscalls go through the rust runtime. The limitations are pretty coarse (but i'd say a great start).

orta 6y ago

I think this is a good article, and worth the time to give it a read. When Deno was first announced I was not sold on this aspect of the system. Over time though, and after having wrote a barely-above-trivial app in Deno. I've started to come to the conclusion that Deno's form of dependency management is a fresh perspective which ties closer to how browsers work and is a welcome simplification. The article covers a few ways that you can get production/reproducible builds out of the box which is usually people's first worry.

jppope 6y ago
agreed

earthboundkid 6y ago

Odd that the article doesn’t mention Go. Deno works like Go. It’s slightly different in that Go added a system for version rewrites recently (“modules”), but other than that it’s the same, and if importmaps ever happen, it will be the exact same. Also Deno has a command line fallback for its version of GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. But other than cosmetic differences, it’s pretty much identical to Go.

maxmcd 6y ago
I've been skimming the arguments so I might have missed something big, but isn't the key distinction that Deno can take anything from a URL? Go's "go get" is backed by version control systems, but you could freely point your deno at "http://dangerous.com/evil.ts" http://dangerous.com/evil.ts". I thought the concern was about the potentially problematic flexibility.
- earthboundkid 6y ago
  Go has a system for telling where to fetch based on the URL response. You can basically send anything if you are evil, but Go modules keep a hash of seen content (what Deno calls a lockfile), so you’d notice that it changed.
- 14u2c 6y ago
  Isn't that the advantage though, that you can do exactly that without concern. > deno run --allow-write=~/only-evil-here http://dangerous.com/evil.ts http://dangerous.com/evil.ts
parhamn 6y ago
> GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. This gave me a laugh but it’s not fair! I’d guess most of the GOPATH outcry was the annoyance around managing automated and other non-dev environments.
- 6y ago

oddthink 6y ago

This may be inviting downvotes, but I still don't understand the use-case of Deno. Why would I use this over something like Python? In Python, I find I can do most things I want with the standard library plus a handful of well-known packages, so even just downloading the tarballs and installing manually isn't all that onerous. Why do I want a "browser for code"? I may just be out-of-touch, as a purely backend/machine-learning/quality engineer. Clearly, this is a real need in the front-end / JavaScript space, but coming from the outside I just don't quite understand yet the value proposition here. Can anyone explain?

root_axis 6y ago
if you have everything you need in python then you're not really the target audience. deno is an answer to the current state of the npm ecosystem. Not that you shouldn't switch to deno from python, but you should only do that if you already had a reason why you wanted to switch to node from python.
paxys 6y ago
Your question really is "why use server-side JS over Python" and that doesn't have a real answer, just never-ending arguments.
- mst 6y ago
  Let's paint it blue!
shriek 6y ago
> Clearly, this is a real need in the front-end / JavaScript space I think you answered your own question there. If you already know JS/TS and want to dive into server code then this is more approachable than learning a brand new language.
ordinaryradical 6y ago
>Why would I use this over something like Python? That's more a js vs python question than a Deno question so I don't think you'll find many answers here as we'd veer off-topic. >I find I can do most things I want with the standard library A standard library exists for Deno as well. Code from any URL is not an argument against having a standard library. The distinction being made is whether or not package management should be brittle and baked into the programming model to accept only one source of truth vs. any. Any source of truth has the advantage of letting better solutions evolve and reveal themselves over time, which is great for longevity, standards, etc. etc. > Why do I want a "browser for code"? My understanding is that this a lot to do with reproducing how front-end code behave "in the wild." If you have a full browser, you aren't tricking your programming model into thinking it's being run in a browser. I think this has tooling advantages in the short term (i.e. simplicity) and more subtle ones in the long term.

xixixao 6y ago

2 reasons why this could be a faulty approach: 1) Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This naturally invites a single central repository over the decentralization of the web. 2) Very few people publish their own websites. Why? It's complicated, costly. This is why Facebook and Twitter fair so well. So even the decentralized web eventually diverges onto a centralized platform that solves the hosting problem. Why reintroduce the problem when there is already a fairly un-problematic central registry? If the security model is the real winner, I don't see why it could not be back-ported to Node - it likely will be if Deno takes off in any way.

jclulow 6y ago
I don't have an opinion on Deno per se, but I quibble with this part of your point: > Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This implies that there is in fact one good way to do most things, but in practice different people want different trade-offs and forcing them into a single codebase isn't possible when the options are mutually exclusive. You can't have a library that is simultaneously strict about types (panics if you pass a string instead of a number, say) and forgiving about types (automatically coerces strings to integers or vice versa).

paxys 6y ago

The key paragraph: > The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. You, the person invoking the code, get to tell that code what it can and can’t do, externally. Also, like a browser, code can ask you permission to do things, which you can choose to grant or deny. The big problem with Deno is that permissions, once granted, apply to every imported URL. You cannot ask it to let one script access the file system, another access network and the rest of them run fully sandboxed. This makes it so that you either only import scripts you already fully trust (making the permission system useless) or don't allow any access (making the ecosystem useless).

chii 6y ago
> ask it to let one script access the file system, another access network and the rest of them run fully sandboxed. this is actually quite a difficult problem to solve. You're balancing the security needs with usability. Browsers have an advantage on this aspect, because they can make the assumption that the webpage does not require filesystem access. i think fully sandboxed OS-esque security model is the only way this can work. Like on android, where each app sees only their own filesystem, and app-to-app interaction is done via a permission based system that the user has to approve.
- bryanrasmussen 6y ago
  They could have maybe looked at E for some inspiration on how to solve the problem http://erights.org/ http://erights.org/
- aabbcc1241 6y ago
  On android the apps has access to shared folders. For example my music player can scan and read files under /mnt/sdcard/Android/data/com.dropbox.android/files/ It maybe more isolated if it follows the nix file system model?
freeopinion 6y ago

gfxgirl 6y ago

Deno seems like the next mongo db fiasco waiting to happen. Insecure by default. The fact that it doesn't grant permissions by default is irrelevant, servers need permissions to function (access databases, access files, access the network, etc...). The incentives are all wrong. If I MITM a website at best I gain access to the data of the few users that pass through my part of the net. If I MITM something Deno is using I get access to the server. That's orders of magnitude more data I get access too and therefore the incentive to MITM (or other) is much much MUCH higher.

chrisco255 6y ago
I agree, they should force cached, sandboxed fetching by default and have people opt in to dynamic fetching.

draw_down 6y ago

I think this is pretty good. I like the use of URLs as identifiers for your dependencies, just because it’s so unambiguous. I also like re-exporting deps manually. My only real point of discomfort is how the runtime seems to be a bit too closely tied to the actual download and transport of these files/URLs. Like, importing from https implying all further imports are from https is nice, I guess, but is really stretching the browser metaphor imo. I guess that is really my main point of contention, I agree with the security model but I don’t agree that websites are particularly analogous to code dependencies.

gigel82 6y ago

You hardcode the dependency version in the actual URL string in JavaScript code? How in the world is that manageable? I run `npm update` once a week and it brings down a dozen or so updates (occasionally `npm outdated` as well with manual testing). I bet we'll have a bunch of competing standards for "dependency management" in deno coming online really soon, because there's an obvious need for that. Also, are dynamic dependencies a thing? Can I run some code to decide (at runtime) whether I import this.package or that.package? Holy hell... with test coverage the way it is in most projects, that's going to blow up really fast.

PudgePacket 6y ago
> You hardcode the dependency version in the actual URL Websites have been doing this for .. 20 years? It's quite a different paradigm, yes.
- godot 6y ago
  Before the age of React, when I used to work on decent-sized web sites' frontend, there would typically be maybe a handful of external dependencies; usually just jquery; and later on perhaps a few other powered-by-jquery utility that gives you maybe a carousel or other UI elements. Most of the rest of the JS code is written in-house. Working with node backend in the past few years, most of my backend services typically list a dozen dependencies or so in package.json, and those in turn have a bunch of other dependencies of their own. Among these there's probably lodash, some schema validator (ajv/joi/etc.), maybe an xml parsing/building lib, some unit testing framework, db query builder, and so on. I'm not saying this to be pro-node and attack deno or anything; I just feel like the statement of "websites/browsers have been doing this forever" isn't exactly an apples to apples comparison.
- chrismorgan 6y ago
  A major difference: transitive dependencies. In the old days, jquery.foo.bar.js would say “make sure you’ve loaded jquery.js and jquery.foo.js first”, and it would be up to you to decide which versions of them to use. Under Deno, modules will declare their exact dependencies and I suppose you the caller can’t control them. Or else they could devolve into some form of dependency injection. This could lead to many copies of a library being loaded and included, rather than just one via deduplication as other packaging systems tend to do. (The article talks about the potential need to remap dependencies, which could allow you to resolve this sort of duplication manually, but says that the current implementation should probably be avoided.)

swagonomixxx 6y ago

Can someone explain to me what problem that Deno and Node are trying to solve? Is JavaScript really such an amazing language that we need to use it for backend applications now? What niche is it filling that is unfilled by other, more sanely designed programming languages? I'm not trying to be obtuse or anything, I'm just really curious as to why anyone would use Deno (or Node for that matter) for a project when I can think of at least 4 alternatives that are more sane (Go, Python, Rust, Java, and many more out there, just that these are the ones I'm most comfortable with).

chrisco255 6y ago
Node.js has been used in production for over a decade. Some of the most popular applications of the past decade have been built on Node and in 2020, JavaScript is the most popular programming language.
franciscop 6y ago
This seems like trolling more than a genuine question, but I'll answer in case it is genuine. It makes it easier for fullstack developers since it's a single language both in the front-end and back-end. You only need to learn once how `JSON.parse()`, `atob`, classes/prototypes, etc. work, and not worry about language inconsistencies making errors. It is decently efficient (not the best, not the worst), fairly readable (I'd say on the upper side). The three main disadvantages IMHO are: - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages - Node.js standard library is optimizing for flexibility instead of conciseness or completeness, so there's quite a bit of manual gruntwork involved (not the worst of those mentioned though). - Right now the ecosystem is in a major migration from `require()` to `import`. The last large migration like this was from Callbacks to Promises, and IMHO it went very well. As someone who is very comfortable with Javascript, and was comfortable with PHP and Python back in the day, I would not trade Node.js for any of those. I am thinking most of the time about what I want to achieve in a coherent way, and not fumbling with pointers.
- mekster 6y ago
  > - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages Grasping isn't the hard part, it's just about placing callback functions on executed functions that allows callbacks. What's so bad is that it is async by default and now you need million "await" and "async" keywords all over the place. I wish it would be sync by default and for those rare cases where you really want it async, you would add a keyword.

jppope 6y ago

Its very interesting to me the level of skepticism that is being shown towards Deno. Whether or not you agree with the approach, you have to agree with the underlying problems that Deno is trying to solve. Furthermore I agree with the article in that there is a paradigm shift here, which should be given a chance. I for one am happy about the url imports for a variety of reasons, but top on my list is that it will (in theory) reduce the total amount of code people are using from other sources, and (in theory) will make developers more aware of what they do choose to import. All of this should reduce bloat and award open source maintainers that solve novel problems in a clear & concise way.

emerongi 6y ago
There are better ways to reduce bloat. Gitlab can do web asset analysis and throw warning signs when your JS file goes over a certain size. Of course, in server-side applications the use-case would be different, but the idea remains the same: do not depend on developers doing the right thing every single day, depend on an automated system if something like this is crucial to you. The URL import completely throws away all the goodies that great package managers have. Being able to manage sub-dependency versions is a big one. I do not understand how people are OK with throwing those away. Either they have never encountered issues that stem from dependencies or they just don't care. Deno could technically add layers on top that make dependency management easier, but then we are back to NPM.
- deleted 6y ago
  [deleted]
fastball 6y ago
It's very interesting to me the level of enthusiasm being shown towards Deno. It is clearly being embraced more than it has shown its worth.
jfkebwjsbx 6y ago
> Whether or not you agree with the approach, you have to agree with the underlying problems that Deno is trying to solve. Perhaps, but that does not mean Deno is the solution. > there is a paradigm shift here, which should be given a chance. Why? If I come up with a novel approach for something, I am the one that has to show it works. > I for one am happy about the url imports for a variety of reasons, but top on my list is that it will (in theory) reduce the total amount of code people are using from other sources I'd say it is the other way around. It encourages an even crazier approach to dependencies that the NPM mess already is.

AbuAssar 6y ago

The node_modules folder with its tenths of thousands of files is killing my ssd! as it is present in every node project I have, and consumes a gigantic number of io operations. Thus I’m very glad that deno didn’t continue this tradition.

Epskampie 6y ago
Replace ‘node_modules’ with ‘deno cache’ and presto! you’re in the future.
- arcatek 6y ago
  Yarn already removes the need for node_modules without requiring to change interpreter and APIs, though.
- AbuAssar 6y ago
  Not true deno cache contains only the js files, and each one of them includes all its dependancies in the same file. OTOH node modules contains every package in the dependency tree, and each package has many files not related to the required js file.
mekster 6y ago
You might as well live without GUI as those involve "gigantic" amount of IO as well. Why are people being so sensitive with hardware resource? Like how Electron is killing your machine...
- AbuAssar 6y ago
  ssd has limited number of write operations, while node_modules writes many many files to the disk. And as mentioned in the article you repeatedly remove and recreate it to fix “problems”
  - lolc 6y ago
    Even with write amplification a node_modules is not typically going to cause more than a few gigabytes write load. So with max TBW being somewhere in the hundreds of terabytes for current SSD, we're looking at hundreds of thousand node_module rewrites before the drive gives. Unless you're rewriting your node_modules every other minute on an old SSD I recommend finding something else to worry about.

keymone 6y ago

The holy grail of package management is absence of packages and versions, but distribution via signature-addressable code. In the end it’s all just functions that take arguments and return values. They should be the minimal unit of distribution. Potentially even with precompiled bytecode signed by some trusted compilation provider.

saagarjha 6y ago
You still need to keep track of things that are mutually incompatible.
- keymone 6y ago
  Not really, because you ship every required version of every function. Functions aren’t incompatible with functions they don’t use.
cousin_it 6y ago
It's always fun to solve half of a problem perfectly and ignore the other half. But then you wonder why it doesn't take the world by storm. (Or sometimes it does, if you were pushy enough, and everyone has to live with your half-solution.) The problem is not only about units of distribution, but also about units of interoperability. The unit should be a group of functions that share common types, naming conventions and design decisions, and have no weird edge cases when used together, unlike some mishmash cobbled together from the internet. In other words, a library. It's like Coase's "Nature of the firm": libraries exist to lower interoperability costs internally, same as firms exist to lower transaction costs internally. The right size and version policy for libraries is a non-trivial question. I think the npm culture has settled on the wrong answer to that question, and that's why we end up with these complicated dependency trees.
- keymone 6y ago
  You only think it needs to be this cohesive thing with types and global definitions and conventions because that’s the current way to approach software development. There is more than one way to do it. In your code a library is completely ephemeral concept, it is only made concrete due to the fact that you have a reference to it in your package manager’s file. In your code however, that library is defined by functions you import and use. Do what stops you stripping the rest away? And if stripping is fine, what’s wrong with turning that upside down and just not having a concrete library as a unit of distribution? That set of functions can be built out of single repository and share a component in some unique reference scheme, but any subset of it is no less functional - each function still has a spec of what other functions it needs to do it’s job and those requirements are satisfied by your build system and everybody is happy. As for types, in vast majority of circumstances you don’t need anything beyond what’s described in EDN spec, which is basically json but more sensible. And if you do need more types - you just require functions that produce and manipulate them and you refer to those types using that same uniquq reference scheme to describe your function signatures.

forty 6y ago

If they wanted to fix something on dependency management, they could have started by adding a way to sign the code/packages. Indeed browsers don't allow to sign pages, which means anyone from the hosting provider to the CDN to the mitm corporate proxy can inject any code they want. It sucks and I'm not sure why "Deno is a browser for code" seems to be a good thing.... Hopefully something like google signed http exchange will fix that in the future for browsers at least.

ccmcarey 6y ago
Unless I'm missing what you're referring to, that's not true at all - HTTPS is secure and uses certificates to sign and encrypt traffic.
- kbenson 6y ago
  I think they are referring to signed content, not singed transport. That is, this blob of content/code I downloaded is signed and I have more trust in it than in some other piece of content/code that's from a server meant to house hundreds or thousands of different people, much less modules. You can trust that the developer meant to release that, and it's not some hack of the system, and you can also require that the code comes from a vetting third party that reviews all modules and updates and signs it itself (i.e. what Linux distro package managers do).
- emerongi 6y ago
  I think OP is arguing: - Host can change what is in a package at any time. In case Deno calculates a hash on your machine (e.g. package-lock.json), it's not as bad, but still without a signed package you can't be sure that it was the author that released the code in the first place. - Host <-> CDN usually happens over HTTP. Often it is the CDN where HTTPS is terminated. Technically the CDN can deliver whatever code to you. - Corporate HTTPS proxies exist. With a proxy like this, it can also replace the code with whatever it likes.
  - brabel 6y ago
    > In case Deno calculates a hash on your machine (e.g. package-lock.json), it's not as bad, but still without a signed package you can't be sure that it was the author that released the code in the first place. If you trust the URL is in a (sub)domain controlled by the author and it's a HTTPS URL, that's as much guarantee as a signature.

forty 6y ago

The issue I have with Deno is not only comparing to NodeJS. If you might use Deno it means you are open to switching platform and even language of you were not going TS already. And if you are at this point, you might as well choose any plateforms, for example one that use a better (with stronger types) programming language and a bigger ecosystem (scala, swift, rust, F#, java, ocaml, kotlin... At this point I feel nearly any other languages fit this description ^^). I have been doing Typescript for a while now, it's probably as good as it could be doing what it does (being a JS add on), but if you don't have this constraint, there are many better options.

ex3ndr 6y ago
Please, scala could be so different that you can spent years learning it and still don't understand a lot of things. Swift is ok, but ARC is a nightmare. Good for mobile though. Rust is really for C++ guys for specific use cases. F#/Ocaml is cool languages, but good luck hiring fast if you need to. Kotlin probably best, but in fact it works with decent performance only on JVM. Native is still 15x times slower than JS. TS is a first class language and have bigger ecosystem anyway than, say, F#. etc etc
- chrischen 6y ago
  I'd like to add that the ecosystem around TS/JS is huge, even allowing you to do interop with both F# and Ocaml on both frontend and backend code.
- saagarjha 6y ago
  I’m going to skip over the other stuff, but > Native is still 15x times slower than JS. Surely you meant the other way around?
  - cercatrova 6y ago
    https://discuss.kotlinlang.org/t/kotlin-native-performance/17823 https://discuss.kotlinlang.org/t/kotlin-native-performance/1... Seems Kotlin native can be 100x slower than its JVM version. It's still under development so this can of course change.

marcus_holmes 6y ago

I still think that sandboxing dependencies is the wrong answer to this problem. (first - the problem is trusting dependencies. How to spot malicious code in a dependency, and stop an evil upstream maintainer from doing bad things to your site) This solution slows down the system at run-time (and also never quite solves the problem - sandboxes are pretty leaky. The history of browser extensions trying to do the same thing is a good example). I'm not really sure what the solution is. I have some ideas, but they're mostly about changing the culture around coding, rather than technical.

lolc 6y ago
Having sandbox restrictions available allows deeper defence. When it comes to running other people's code, VM restrictions provide a solid layer of protection. At work we're transitioning our NPM scripts to run in containers. This is very cumbersome. But the extra layer protects dev homedirs from rando NPM authors.

pjmlp 6y ago

The first time I dealt with dependencies written directly in code was with Groovy. It wasn't a good idea back then, it wasn't a good idea in Go and it isn't definitly a good idea in Deno.

vlaaad 6y ago
Care to explain why?
- pjmlp 6y ago
  Because it ties the source code to the origin of the dependencies, forces code rewrites that don't scale across all dependencies and aren't enterprise friendly for using internal IT vetoed repositories. Just because a dependency changed location I should not be obliged to touch a single character of the source code.
  - brabel 6y ago
    In the case of Groovy that OP mentioned, that's wrong. This is what it looks like in Groovy[1]: @Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE') import org.springframework.jdbc.core.JdbcTemplate This provides the dependency's coordinates... but not where it comes from. You can define where it comes from by configuring Repositories (normally done by modifying the M2 settings file). This is how Java has always done it in Maven and Gradle, even Ant long time ago. And this works really well! Never seen anyone complaining about how that works. [1] http://docs.groovy-lang.org/latest/html/documentation/grape.html http://docs.groovy-lang.org/latest/html/documentation/grape....
    - pjmlp 6y ago
      I am the OP and you forgot this little detail, @GrabResolver(name='restlet', root='http://maven.restlet.org/')
      - brabel 6y ago

cercatrova 6y ago

Interesting, so by making dependencies in the code itself, which is more obtuse than using node modules, we might see fewer overall packages being used by developers, and more implementations from scratch. No more gigabyte sized node modules! I'm looking forward to this.

searchableguy 6y ago
Right! https://deno.land/x/is_url https://deno.land/x/is_url https://deno.land/x/blox https://deno.land/x/blox https://deno.land/x/deno_flatten https://deno.land/x/deno_flatten https://deno.land/x/ende https://deno.land/x/ende https://deno.land/x/humanize_url https://deno.land/x/humanize_url There are many others. I don't know why people aren't looking into std (which provides most of the functionality) or using regex where it doesn't make sense given deno is a browser.
- satvikpendem 6y ago
  Well hopefully people find it too annoying to use deno modules and we get some sanity in development.

sktrdie 6y ago

All these "features" of Deno are super cool, but why reimplement a runtime from scratch :( Can we not benefit in Node from what I essentially see as "package.json not mandatory" - which I think is already achievable with ES Modules - and "better permissions model"? Maybe this can be seen as the effort from several years ago where a project "io.js" branched out of Node as trying to implement certain things the community didn't like. Then after a few years they were implemented into Node and io.js "died off". Although io.js had always the intent of being compatible with Node, so that definitely changes things.

petercooper 6y ago
Some of what Deno does can be done in Node or people are trying to implement it (I've seen some proofs of concept around the way modules are included). However, it seems that being able to write the runtime in Rust has been a big deal here as it dramatically changes how the runtime is distributed and the developer experience of writing extensions for it versus Node.
- sktrdie 6y ago
  How is choosing between Rust and C++ as the language in which the thing is written in, an important thing to the users who only care about the JS/TS interface?
  - mst 6y ago
    Because, in the long run, rust is a much better language for writing this in, and will enable faster addition of features for the JS/TS interface and more certainty that the security level stuff is actually secure.

macca321 6y ago

Seems odd that they don't support an equivalent of the integrity attribute.

sholladay 6y ago

To the people who are skeptical of Deno, I would urge you to have patience and try it out. Deno is a young tool and it will take time to develop the features that you take for granted in other systems. But Deno gets a lot of things right. I already love using it day to day. I remember using Node when it was this age and thinking it was the future, too. And it was. But as with Deno now, there were problems. In fact, Node was far worse in many ways. npm was extremely unstable back then, for example, which often made it impossible to use. Deno doesn't have that problem. Node had to create libraries from scratch and invent a ton of non-standard things along the way to do it. Deno is built on web standards but can also leverage many of the existing Node libraries by using std/node (the Node compatibility layer) or with jspm.io, for example. Yes, there's the occasional quirk or missing library, but it's already easy to be productive with Deno and it's a lot of fun.

tannhaeuser 6y ago
> Node had to create libraries from scratch and invent a ton of non-standard things along the way to do it. Deno is built on web standards but can also leverage many of the existing Node libraries by using std/node (the Node compatibility layer) or with jspm.io, for example Node.js is based on CommonJS [1] which defines the require() semantics for CommonJS/node.js modules as well as core libs/APIs such as JSGI (for express.js or node core http middleware) and others. When node.js was new, there were many JavaScript app server projects such as helma, v8cgi/TeaJS, and others, and CommonJS was very much a community effort. [1]: http://wiki.commonjs.org/wiki/CommonJS http://wiki.commonjs.org/wiki/CommonJS
- specialist 6y ago
  The inability to import (requires) modules using relative paths drove me nuts while using nodejs. I hope deno fixes that.

einpoklum 6y ago

The post sounds rather Javascript-specific, or NPM-specific. How well does that apply to other languages? Especially compiled ones?

soapdog 6y ago

Just for the kicks, I tried using deno for a task at my day job. We had a need to extract records from a database into a textual format to be processed by other tools later. This is the typical task for a throwaway script which can be written in basically any scripting language. There is nothing in the task that called out for deno but I wanted to try it out and so I did. I basically worked on the script iteratively, doing small changes, running it, checking the output, fixing things and running again. No bundler, no complex NPM tasks. Just a simple spaghetti JS and a single binary engine to run it. It was a very refreshing experience. Using URL imports was pretty nice, I really like working like that since my preferred JS environment is not NodeJS but the browser. I can see myself transitioning all those small tools and throwaway scripts I'd do in NodeJS to Deno. People relying on NodeJS for servers and tooling for their client-side webapps might need to wait a bit longer, but for doing small tasks and scripts, I think it is quite ready and better than NodeJS IMHO. These are also good projects to give you a feel for the new runtime.

jfkebwjsbx 6y ago
For small scripts there are many languages out there which are better, with a proper standard library and pre-installed runtimes in virtually every machine. Why would someone want to use a new language and a new runtime in production scripts is beyond my understanding. Just write Python for those. Even Perl, awk or sh would be better options, and that is saying something...
- searchableguy 6y ago
  Well I can think of few. For one, if you are writing a script with external dependencies, it's more work than deno to distribute them. For python, you would need pip. Can you install any script from arbitrary urls using pip? I am not sure but I don't think you can. You also have to declare your deps for pip to figure out. With deno, it's just deno run -A url to script since dependencies are declared in the code with their respective url or file location.
  - jfkebwjsbx 6y ago

julvo 6y ago

The two most frequent arguments against using URLs instead of npm packages seem to be: 1) Security: What if someone changes the code behind a URL? 2) Hard-coded versions in application code I don't think these arguments are valid. For 1) you can always limit the URLs you use to hosts like jsDelivr or unpkg and reference npm packages directly. In this case instead of trusting only npm to send you the code you requested, you're now trusting the CDN as well. Potentially even better could be to import scripts from Github directly. For 2) a simple solution could be to have a deps.ts file for your project where you import from single-version URLs and export the dependency version-unaware. Now your versions are not scattered throughout your application code. To me URLs seem like a nice (because compact and universal) interface for dependencies which allows decoupling your package management from your runtime.

jfkebwjsbx 6y ago
So, in order to solve 1) and 2), we should return to what every other language does? That sounds like a design mistake... What do you mean by "URLs are compact"? How can a URL be compact compared to the same URL in some sort of dependencies file? Unless you use the dependency once, of course, which is rare. URLs and explicit versions in the import also encourage you to use several versions of the same dependency in your code, which is a very bad idea. NPM’s model of referencing packages from central repositories is bad for many reasons proven over the years. But referencing GitHub scripts and arbitrary URLs is even worse.
- julvo 6y ago
  URLs are compact as in a single string they specify everything you need to locate and use the dependency and you don't need any context, like a specific dependency manager (incl some sort of dependency file). I guess I mean compact as in self-contained, not necessarily short.
  - jfkebwjsbx 6y ago
    That’s fair and I’d agree it could be a useful property for scripts and even small apps if all code was trusted and all networks had perfectly availability. Sadly, that is not the case, which is why I don’t see the advantage of going "the browser way" for local scripts.

vanderZwan 6y ago

Clear article, I honestly don't have much to add to the main thesis of it, other than that I'm very curious to see how well the arguments will hold up when faced with "real world" usage, and how Deno will evolve. But if I may indulge in a bit of bike-shedding on the side, does anyone else think that the repeated URLs in the example dependency tree are a bit noisy and hide the deeper structure of the dependencies? https://deno.land/x/oak/examples/server.ts ├── https://deno.land/std@0.53.0/fmt/colors.ts └─┬ https://deno.land/x/oak/mod.ts ├─┬ https://deno.land/x/oak/application.ts │ ├─┬ https://deno.land/x/oak/context.ts │ │ ├── https://deno.land/x/oak/cookies.ts │ │ ├─┬ https://deno.land/x/oak/httpError.ts │ │ │ └─┬ https://deno.land/x/oak/deps.ts │ │ │ ├── https://deno.land/std@0.53.0/hash/sha256.ts │ │ │ ├─┬ https://deno.land/std@0.53.0/http/server.ts │ │ │ │ ├── https://deno.land/std@0.53.0/encoding/utf8.ts │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/bufio.ts │ │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/util.ts I'm not entirely sure what would be the ideal alternative presentation though. Perhaps something along the lines of one of these two mock-ups I just edited by hand: https://deno.land/ └─┬ x/oak/examples/server.ts ├── std@0.53.0/fmt/colors.ts └─┬ x/oak/mod.ts ├─┬ x/oak/application.ts │ ├─┬ x/oak/context.ts │ │ ├── x/oak/cookies.ts │ │ ├─┬ x/oak/httpError.ts │ │ │ └─┬ x/oak/deps.ts │ │ │ ├── std@0.53.0/hash/sha256.ts │ │ │ ├─┬ std@0.53.0/http/server.ts │ │ │ │ ├── std@0.53.0/encoding/utf8.ts │ │ │ │ ├─┬ std@0.53.0/io/bufio.ts │ │ │ │ │ ├─┬ std@0.53.0/io/util.ts https://deno.land/x/oak/examples/server.ts ├── https://deno.land/std@0.53.0/fmt/colors.ts └── https://deno.land/x/oak/ └─┬ mod.ts ├─┬ application.ts │ ├─┬ context.ts │ │ ├── cookies.ts │ │ ├─┬ httpError.ts │ │ │ └─┬ deps.ts │ │ │ ├── https://deno.land/std@0.53.0/ │ │ │ │ ├── hash/sha256.ts │ │ │ │ └─┬ http/server.ts │ │ │ │ ├── encoding/utf8.ts │ │ │ │ ├─┬ io/bufio.ts │ │ │ │ │ ├─┬ io/util.ts I'm sure there are good arguments to be made against both of these options as well - plus I just came up with this on the spot, I don't even know which "rules" would generate such a tree.

talkingtab 6y ago

The npm registry is like a rickety bridge across a chasm. Every day I cross that bridge because of how much time and work it saves me, but I am well aware that the bridge might fall, especially with Microsoft now in charge. Claiming that I don't need a bridge does not help me. Claiming that Deno is agnostic about bridges is fine. If someone is looking for a startup idea, here is a perfect opportunity to build a better bridge - one that works with Deno.

jolux 6y ago

I’m still not sure how this addresses Laurie Voss’s point about left-pad. Does the caching and lock file happen by default?

zubairq 6y ago

Deno is awesome. We had a similar idea at Yazz Pilot and are currently building out the ability to import a subset of Javascript code from a URL. Currently it only supports code of the form: pilot https://raw.githubusercontent.com/zubairq/pilot/master/start.js https://raw.githubusercontent.com/zubairq/pilot/master/start...

diffrinse 6y ago

Feel like it would've been useful to require a manifest.json or some such that spec'd required permissions right next to the deno package on the FS, in the web server web root. This is not different from manifests for Web Extensions. Then anyone could write their own CLI to download and cache packages but have their own "excluded permissions" list that throws/rejects packages that overreach or could potentially overreach. Now package writers have a feedback metric for getting as granular as possible with that access their package needs. Even better, anyone could build server infrastructure that does not the client-side validation bit for package consumers with their own attendant CLI tool. It looks to me Deno opens the possibility of multiple NPMs, which is a good thing over the de facto monopoly NPM exerts today.

dzsekijo 6y ago

For example https://deno.land/x/ https://deno.land/x/ is effectively nothing but a URL redirect server, where it rewrites URLs to include a git commit-ish reference in the redirected URL. So https://deno.land/x/oak@v4.0.0/mod.ts https://deno.land/x/oak@v4.0.0/mod.ts becomes https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.ts https://raw.githubusercontent.com/oakserver/oak/v4.0.0/mod.t..., which GitHub serves up a nice versioned module. Thus http://deno.land/x/ http://deno.land/x/ is the de facto central registry. I'm yet to see how it makes a difference whether the logic of resolving a package name to a concrete version of the package is baked into command line tooling or a web service.