16 ms·

Big changes ahead for Deno

443 points by 0xedb 4y ago

radiojasper 4y ago
That Bun pressure though!
valtism 4y ago
Wow, very interested in an npm compatible Deno! I think that will remove a huge barrier to entry for Deno and could mark a huge shift towards usage in production. I'm very interested in how packages will manage runtime support in the future. Right now we are seeing an explosion of JavaScript runtimes from Cloudflare Workers to Bun, all with sightly different APIs. I wonder if there will be an easy way to get cross-runtime support without it being much extra work for library authors. Right now, there has already been conflict with some packages being browser-only and some being node-only. I feel like there needs to be a better solution than the one we have now.
- adamddev1 4y ago
  Yes the lack of npm compatibility was the only thing keeping me back from Deno. I really like they way they're going to do it. `import express from "npm:express@5";`
- ricardobeat 4y ago
  Both Deno and Bun are adopting APIs that are close to existing web standards, so Node is becoming the odd one out.
  - montroser 4y ago
    There are _lots_ and _lots_ of JavaScript runtimes out there: https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
    - ricardobeat 4y ago
      I'm very familiar with the space. The majority of these have never reached production status or any meaningful usage, the few active ones are very niche products - Duktape, Espruino, Quickjs, etc, you'll be hard pressed to find someone running a web server, gui or cli app on them. Hermes might show up in the engine radar due to how prevalent RN is, but other than that, you can bet 99% of projects run Node.js or Deno now. As long as these are actual standards, all the other runtimes also get a fair shot at implementing them. I think it's a move in the right direction.
- deckard1 4y ago
  > browser-only and some being node-only. Browser, node (OS-level), or serverless worker, these are all fundamentally different roles and need different API requirements. Node and serverless don't have a DOM. Serverless can't have unfettered access to the host OS. Node should be as capable as any host language (Python, Ruby, C, etc.) with an API equally powerful. The browser obviously needs a more limited sandbox. There is a parallel universe out there, where Sun had success with Java in the browser, the JVM evolved to better support distribution and HTTP standards as well as replaced the need for WASM. And we all lived in a happy world with Java on the server and Java in the browser and everything is cross-platform and Just Works(tm). Cats and dogs also live together in harmony in this world. We had big dreams in the '90s.
up6w6 4y ago
> We know there's been a lot of chatter recently about runtime speed. For reference: https://news.ycombinator.com/item?id=32457587 https://news.ycombinator.com/item?id=32457587 Btw, I like where it's going but I find it quite sad that there is no official linux ARM64 support yet - which means I can't try to use it on AWS lambda for example.
- bbqbbqbbq 4y ago
- viraptor 4y ago
  AWS lambdas are available in Intel flavour. You don't need arm support for them.
  - philliphaydon 4y ago
    By default they are x86 unless you specify ARM. I find the parent comment a bit confusing. Unless he wants the graviton 2 pricing and perf benefits. Which I 100% support!!! Love graviton!
- crowlKats 4y ago
  ARM64 builds are something that has been getting investigated. The biggest problem is that github doesnt provide any ARM64 runners, so workarounds around that are necessary
qwertyuiop_ 4y ago
Looks like Deno took notice of Bun https://bun.sh/ https://bun.sh/
hjanssen 4y ago
Not sure if Bun has had an influence on this, these features must have been in development for a long time, but the timing surely is impeccable. npm compatibility is huge for Deno. It is basically the one major drawback to Deno, which gets hopefully fixed with this feature. It also looks like this compatibility layer is implemented transparently in the existing module management, which is a big bonus. Nobody wants to deal with node_modules anymore when working with Deno for an extended period, just love to see this.
- Zachsa999 4y ago
  I imagine yes, bun put pressure on to launch node package compatibility. Any thoughts on speed reliability concerns comparing the two?
- 12many 4y ago
  If you deep dive into bun, it only has the gained performance for certain features and cant really even be compared to deno or node at the moment because it lacks so many other features that would better showcase its speed.
  - treyhuffine 4y ago
    Here's a good summary that details your point on what Bun does well and where it lacks - https://levelup.gitconnected.com/is-bun-js-the-node-js-killer-ffeb0f89196a https://levelup.gitconnected.com/is-bun-js-the-node-js-kille...
    - OJFord 4y ago
      Hm, that claims SQLite is 'never' used for web backends; Bun says it's motivated for use 'at the edge' - first thing I thought of when I read that was Fly.io/Litestream: https://fly.io/blog/all-in-on-sqlite-litestream/ https://fly.io/blog/all-in-on-sqlite-litestream/ (No idea if there's any relationship between the projects, just makes me think that article's a bit dismissive.)
  - gureddio 4y ago
resoluteteeth 4y ago
NPM compatibility is probably the most important thing currently holding up people from adopting deno so this is pretty significant
nitsky 4y ago
Will Deno’s approach to NPM compatibility support peer dependencies? https://nodejs.org/en/blog/npm/peer-dependencies/ https://nodejs.org/en/blog/npm/peer-dependencies/ Furthermore, will it support unifying transitive dependency versions to minimize bundle sizes?
- lucacasonato 4y ago
  Yes, this will be supported.
  - nitsky 4y ago
    Hi Luca, can you provide a bit of detail on how this will be accomplished? Will Deno be analyzing an entire project’s npm imports simultaneously, rather than individually?
    - dsherret 4y ago
      Deno already analyzes the entire module graph before the application starts up, so we extract out the npm specifiers ahead of time, do the npm dependency analysis, cache any packages as needed, then start execution.
      - nitsky 4y ago
        Thanks. Any plans for supporting monorepos of first party NPM packages that teams already have?
        dsherret 4y ago
        We'll have custom registry support. For local npm packages, that would be nice to have, but probably something that will be implemented later. It could actually be done in a hacky way with the existing implementation of this we have, but it would be better to have something specifically designed for this.
stall84 4y ago
awwwwhhhh snap! this can really open the runtime up
- sph 4y ago
  Finally. This kind of freedom of choice was sorely missing in the JavaScript world. Not only I will be able to choose package manager, frontend flavour, backend flavour, build system, unit testing framework, now I will be able to choose which runtime to pick as well. I can't wait to see how productive my team will be when this ships.
  - swyx 4y ago
    what a first world problem to complain about too much choice.
    - sph 4y ago
      You can reduce most tech discussion on this forum to a first world problem, so that's not very constructive either.
mattlondon 4y ago
This is pleasing to see - no node_modules, no npm install. Just a special import format. They are not clear if you need to have npm installed or not for this to work. I sincerely hope not - if it requires a locally-installed npm then they've shat the bed I think... that would be a major turn-off for me. Can't say I've ever been concerned by the performance of Deno, but looking forward to seeing this playout anyway since faster is always nice to have.
- lucacasonato 4y ago
  You will not need node or npm installed.
- dmitriid 4y ago
  > This is pleasing to see - no node_modules, no npm install. Just a special import format. You will still have both of those when deno resolves all dependencies and downloads them all. It will just be hidden from you by "magic".
chrismorgan 4y ago
As a non-user of Deno, I’m curious, how do people tend to manage dependency version centralisation in Deno? I suppose this will apply to existing Deno as well as npm imports. I can just see you ending up having to change “import express from "npm:express@5";” from 5 to 6 in lots of places when the next major version comes out. When contemplating how I might do it, I came up with centralised reexport, a file deps.ts containing: export express from "npm:express@5"; This would basically stand in for the dependencies object in package.json. So then I looked up the docs and found https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere https://deno.land/manual/linking_to_external_code#it-seems-u... and was amused to find the same solution, even down to the file name “deps.ts”! Is this how people tend to work with Deno? I see it also supports import maps, https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map..., which could readily solve the problem too. Do people use that?
- yesbabyyes 4y ago
  I've only built a few toy apps with Deno. I use import maps and consider them the canonical solution.
- crowlKats 4y ago
  deps.ts is currently the most common way, however new projects like fresh use import maps. the problem with importmaps is they are not composable, as such, using an importmap for a library is usually bad as said importmap is not picked up and used, so the end-user would have to add their own importmap with entries compatible for the library (this is what fresh does: it generates an importmap with entries it needs). due to this problem, deps.ts is the most common solution, however I do hope that composability issue with importmaps will change.
  - conaclos 4y ago
    It could be nice to have import-maps composability. However, I don't think it is planned because browsers' import-maps are not composable. I dislike the deps.ts concept. It is one of the main reason I did not switch to Deno yet.
paulgb 4y ago
> import express from "npm:express@5"; I'm excited to see this, and I'm sure they'll work this out, but I sure hope I don't have to keep dependency versions in sync across all of my import statements. I don't have much love for package.json and node_modules, but it is nice to have one source-of-truth for all the dependencies of a project.
- dsego 4y ago
  https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere https://deno.land/manual/linking_to_external_code#it-seems-u...
  - dmitriid 4y ago
    This is package.json with extra steps. And yet, people using Deno are so against package management.
    - itslennysfault 4y ago
      Seriously, no idea why anyone things this is a better option. Seems like more work, and if two packages export things with the same name you have to use aliases. Also, seems like this could get REALLY messy on large projects. I LOVE TypeScript, and was so excited about Deno when I first saw it, but the lack of package.json "feature" is a huge turn off for me. I sometimes feel like I'm the only person that has no problem with package.json. I think it works great.
      - Arnavion 4y ago
        Haven't used deno but I assume the standard `export * as asserts from "https://deno.land/std@0.152.0/testing/asserts.ts https://deno.land/std@0.152.0/testing/asserts.ts";` will work, which is the same effort as a package.json and does not create any identifier conflicts.
        dmitriid 4y ago
ricardobeat 4y ago
I hope we figure out a better way to deal with the mountain of dead (and just plain bad) packages on NPM. Not carrying this legacy always sounded like a plus to me, but I haven't used Deno in production yet. It's also interesting to note how the tone changes after receiving funding. May just be a coincidence, but this looks like a reactionary jab back at Bun, which is barely out of the gate.
- benatkin 4y ago
  The first individual investor in the funding announcement is Nat Friedman, who defended ICE while at GitHub. I was one of many who signed the petition and cancelled my GitHub Pro account. Node is still a community project, since the creation of the Node.js Foundation. I feel like switching to Deno would be going backwards. https://www.theverge.com/2019/10/9/20906213/github-ice-microsoft-software-email-contract-immigration-nonprofit-donation https://www.theverge.com/2019/10/9/20906213/github-ice-micro...
  - andrew_ 4y ago
    This seems unrelated to the parent and a bit of soapboxing.
    - zemo 4y ago
      can't say that I agree, it's in response to this: > It's also interesting to note how the tone changes after receiving funding. seems on-topic to me.
- qbasic_forever 4y ago
  Deno has had a node compatibility flag for a while now, and quite a few node packages have worked flawlessly. For anyone who has been using deno for some time this is not a big surprise to see smoother npm import support. I think all the people saying this is such a giant, game-changing big deal or that deno has changed, blah blah haven't actually been using it...
timmg 4y ago
This might sound odd, but: one thing I've wanted to do is use the Typescript compiler without using NPM. (I'm not smart enough to know why I hate NPM. I just want a tool that compiles TS.) It almost sounds like I could write a self-contained deno command-line "app" that does this. Does that seem right (for those that know better)?
- ricardobeat 4y ago
  What you're looking for is ESBuild: https://esbuild.github.io/ https://esbuild.github.io/ TS "compilers" basically strip out the type annotations, they don't care about the validity of the types, so you'll be missing out on the main reason to be using TypeScript.
  - tomxor 4y ago
    esbuild is so awesome... my steps towards web dev sanity are 1. Switch everything to esbuild, remove 10k dependency security nightmare, bloatfest and slugishness of pretty much every other node based build system / bundler. 2. Switch to deno. Haven't quite got to deno yet, but #1 was liberating. esbuild also has some preliminary deno support, but not sure how stable it is. The main thing I like about esbuild is that I feel like I wont ever have to "migrate" build system again (and I have to deal with an unusually high number of repos so this is a big deal), not much in my repos have anything esbuild specific, migrating was more a matter of removing build system specific smells from repos, it's all just a js and css bundle now. i.e there could be something better than esbuild in the future, and switching to that should in theory be effortless. This has never been true for all of the NPM build systems prior, (I was there at the beginning with grunt).
    - vbezhenar 4y ago
      Why do you want to switch to deno? I still don't understand what's the reason to use it over node.
      - conaclos 4y ago
alvis 4y ago
I wish there is more clarity about package dependency will be resolved from Deno? Supporting npm is one big step forward, but without a package-lock.json that locks all child dependencies, it’d be a nightmare using the new compatibility in production
- AgentME 4y ago
  Deno optionally supports lock files, though its current lock files are just for asserting that specific URLs have specific hashes rather than controlling where/which dependencies are found. Maybe its lock files will be extended for handling this.
andrewmcwatters 4y ago
It would be nice if they included a compat flag for importing without this special syntax. As it stands, there is no clear drop-in replacement path for Deno, and as a result, I have no interest in using it. I'm not rewriting my work so someone can have fun playing with VC money and abandon mature software.
- bartlomieju 4y ago
  "compat" mode has been supported for some months now: https://deno.land/manual/node/compatibility_mode https://deno.land/manual/node/compatibility_mode
pier25 4y ago
People ITT mention Bun but I'm sure performance was always in the mind of Ryan et al. They were probably too busy with other stuff though.
andrew_ 4y ago
> We've been working on some updates that will allow Deno to easily import npm packages and make the vast majority of npm packages work in Deno within the next three months. This is really huge and will be a huge boost to the Deno ecosystem. On the other hand, I quite enjoyed that it wasn't jacked into NPM. There were reasonable alternatives like https://jspm.org/ https://jspm.org/. This is a big swing at Node and I'll be watching with maximum curiosity. As an aside, the only thing preventing me from adopting Deno as my daily driver has been the lack of AWS Lambda support (requiring a lambda layer, slowing down cold starts). Would be great if they could leverage connections and advocate for native AWS support.
- alvis 4y ago
  Well. While there's no official AWS Lambda runtime, you can always use a custom image to use deno as a lambda function. Here is just one from the community https://github.com/hayd/deno-lambda https://github.com/hayd/deno-lambda
  - andrew_ 4y ago
    As I had mentioned, it requires using a Lambda Layer. See: https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e1a7f34cf9e5f69a90479a/example-aws-cdk/cdk/example-aws-cdk-stack.ts#L19-L23 https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e... Using your own image (i.e. without using the base AWS image with the layer) you'd get even worse cold start times.
jerrygoyal 4y ago
> 80-90% of npm packages work in Deno within the next three months. curious what kind of npm packages won't be supported in Deno
- SahAssar 4y ago
  Probably ones that use N-API or the ones that compile native addons.
  - bartlomieju 4y ago
    N-API will be supported in future releases of Deno, we have a PR going that is close to completion.
wokwokwok 4y ago
> import express from "npm:express@5"; > There will be no node_modules folder, no npm install; the packages will be automatically downloaded in the Deno cache. My understanding of deno's package system (see https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere https://deno.land/manual/linking_to_external_code#it-seems-u...), is that basically, at compile time it will go and fetch external URLs and cache those files locally. So this change basically makes it so your import: > import { assert } from "https://deno.land/std@0.152.0/testing/asserts.ts https://deno.land/std@0.152.0/testing/asserts.ts"; Is magically generated from npm when you do this instead: > import { assert } from "npm:testing@2.0.1"; Ok cool. Whatever. ...surely this isn't the actual problem? There seem to be certain pretty fundamental problems: - not all npm packages are typescript - a package is not just an 'assert.ts' file, it's often an amalgamation (eg. using rollup) - a package often has many dependencies - a package may use the node API, that deno doesn't have (it has a more-or-less compatibility mode, see 'differences that cannot be overcome' -> https://deno.land/manual/node https://deno.land/manual/node) So bluntly, how on earth is this going to work? I mean, I'm a fan, the folk working on Deno are smart and motivated, and if it works, I'm more 'wow' than 'I don't believe it'... but I'm very surprised to see: > the vast majority of npm packages work in Deno within the next three months That seems... ambitious. I can't see how the approach is really sustainable, given that basically, it means 'anything node supports we have to support to'; doesn't that mean you're forever playing catchup and 'doesn't quite work'? How is vendoring going to work without a package lock file? Doesn't this just mean you've reimplemented npm and you'll forever be playing catchup to the various npm features that are required to make packages work?
- frenchman99 4y ago
  > not all npm packages are typescript All Javascript is Typescript isn't it?
  - georgyo 4y ago
    All typescript is JavaScript, not all JavaScript is typescript.
glutamate 4y ago
AsyncLocalStorage support (https://github.com/denoland/deno/issues/7010 https://github.com/denoland/deno/issues/7010; essentially thread local storage) pretty pretty please?
substation13 4y ago
If we really care about performance, then this split between the runtime and user code is not ideal. What we should be trying to do is bake the user code into the runtime and apply total program optimization. This can be done today with C, C++ and Rust. However, in principle JavaScript code could be transpiled to Zig and then baked into Deno.
- brrrrrm 4y ago
  JITs (as those found in V8, JSC, SpiderMonkey) can theoretically compile better code than static compilation approaches like C, C++, and Rust. It's because the runtime can collect information about what is being run and then generate code accordingly.
  - yencabulator 4y ago
    https://arxiv.org/abs/1602.00602 https://arxiv.org/abs/1602.00602 is a good exploration of why this just doesn't work out, and at best tends to lead to weird stuttering performance.
  - whatshisface 4y ago
    Static compilers can also sometimes do that, it's called profile-guided optimization.
  - emtel 4y ago
    This is true in some situations, but I think is mostly a just-so story told about JITed languages. Here's the problems: 1) Often, you have lots of code that only runs once (e.g. UI initialization), or runs rarely (click handlers). By the time the JIT has had an opportunity to observe this code and optimize it, it may be too late. 2) The dynamic nature of JS means that making your code JIT-friendly requires deep knowledge of what language features to avoid. 3) Performance isn't only driven by having the tightest possible machine code. Memory layout is often more important on modern processors. Indirection causes cache misses, and JS objects contain far more indirection than equivalent structs defined in C/C++/Rust. Further, in Javascript you can't really create cache-friendly collections of objects like vectors, BTreeMaps, etc.
brrrrrm 4y ago
> the next release of Deno will include a new HTTP server. It is the fastest JavaScript web server ever built. I feel unease reading untestable claims (with no numbers) about future releases. I'm made more uneasy by the fact that this is the second bullet point of the main tl;dr. It makes me wonder, what are the organizational incentives driving such a publication?
- rglover 4y ago
  Fealty.
lukevp 4y ago
Demo is awesome, and the npm compatibility is a game changer. Isn’t this the 3rd http server rewrite in less than a year though? They didn’t mention it being backwards compatible. I guess they needed to change the underlying server to support features in Fresh. This is one downside of the team making the core platform as well as many of the main components of the ecosystem… they can evolve the runtime to suit their vision even if it affects competitor’s implementations.
- bartlomieju 4y ago
  New server API is modelled after API available in "std/http/server.ts", so for most folks it should be a drop in replacement.
hardwaregeek 4y ago
This isn't entirely fair to Deno but it always amazes me how people start out with "we don't need packages! Just do direct imports" and eventually end up with "okay fine fine here's a package manager". Packages are great! Don't dismiss them just because in edgecases they're bad. In fairness, the two examples, Deno and Go, are successful projects, so maybe it's not a bad initial strategy.
- johannes1234321 4y ago
  Is deno successful? I (in my limited world) don't know anybody using it and don't see it mentioned in job descriptions etc. And to comparing to other languages: It's not like "ok, projects became to big we need better package management" or something, but to me reads more like "there's too little deno stuff and migration prevents people from going here, so let's try to embrace the other runtime's stuff so maybe more people can use our runtime without having to start from scratch"
  - IshKebab 4y ago
    I think there's quite a big gap between success and being more popular than NPM. Plus it's only a few years old. Job adverts are usually several years behind what companies actually use and companies are behind what hobbyists use. I'd say it is on a successful trajectory. The main issue with it was NPM compatibility so I think this is a very very wise move, even if it is pragmatic rather than ideal.
  - qbasic_forever 4y ago
    It's not even 5 years old, give it some time for people to pick it up and use it. Python was created in '91 but even by '96 it still wasn't widely used.
- speedgoose 4y ago
  The lack of packages in Golang is super annoying though. And I wonder about the mess it will be when something better than git will be popular.
stoicjumbotron 4y ago
Does something like patch-package: https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package exists for Deno? If yes/no how does it work/would work?
- AgentME 4y ago
  With normal Deno dependencies, you could use an import map to accomplish patches like this. Not sure if that currently is planned to work for npm sub-dependencies but it seems like a natural place for that to be implemented.
afavour 4y ago
I'm actually a little disappointed by NPM compatibility. Or at least conflicted. Deno has felt like an opportunity to reboot the server-side JS ecosystem into something far more sensible than it currently is. Not that anyone is to blame for what it is, really, but you learn lessons and move forward. Sometimes making breaking changes. This seems like an acceptance that moving on simply won't happen. The existing ecosystem is too big and too powerful to be ignored. If I were a particularly cynical person I'd also point to Deno taking on millions in VC funding - once you've done that you can't be content to create a perfect, gleaming sandbox. You have to bring in money.
- lukevp 4y ago
  I think this is the motivation behind requiring an npm: prefix. It is a way to virtue signal for devs who buy into the deno goals to push for migrating to non-“legacy” packages. If you see an npm: prefix in a deps.ts file you can consider it tech debt. And potentially set up a lint rule to enforce it in the future. If they had not put an explicit reference in the source (passed through the packages transparently or kept a server side list of packages on npm) then it wouldn’t be colocated with the source and the PR processes. I think this was a good move overall.
  - brundolf 4y ago
    It's not just a "virtue signal"; those packages will have to go through some special (and pretty aggressive) transpiling in order to work. This wasn't just flipping a switch from the Deno team
    - bartlomieju 4y ago
      That's not really what's happening behind the scenes. We are consuming sources as they are provided in npm using "compat layer" that is part of Deno's standard library. We had to provide special module resolution, but besides polyfill for built-in Node APIs, it works very similar to how Node consumes these packages.
      - 4y ago
maxpert 4y ago
So we've come full circle. From the talk of author on how "NPM was a big mistake", to "Nobody is adopting it, we will die without the NPM ecosystem". I was hoping that Deno will spin off into something that can be compiled due to type system hints into something more optimized than JS, but seems like I was just living in dystopian utopia.
- bbqbbqbbq 4y ago
- aliswe 4y ago
  you still sound quite dystopian!
AtNightWeCode 4y ago
> ...make 80-90% of npm packages work in Deno... Can this really be right? What is the number for Nodejs?
brundolf 4y ago
The NPM thing is a huuuuge deal. This has been by far the biggest thing holding Deno back, but it was tough because one of Deno's most exciting benefits was standardizing the module system and ditching NPM. It looks like they may have found a best-of-both-worlds solution for shoehorning NPM's massive ecosystem into Deno while it's still building out its own. Big changes indeed. That, and the emphasis on speed (esp quotes like "We aren't optimizing for a handful of edge cases, but for overall real world performance") makes me wonder if Bun is lighting a fire under them a bit. It's still a long way from catching up, but it's been closing the gap at a blistering pace and getting enormous amounts of hype. The more competition the better. Exciting times
999900000999 4y ago
>Deno to easily import npm packages and make 80-90% of npm packages work in Deno within the next three months. I get it, I understand it, but it is depressing to know that we're going to be dealing with horribly ridden legacy NPM code for the next 800 years. A lot of the code on NPM is just bad. And now we're going to keep this legacy of just, bad JavaScript . This is why I prefer dart and flutter for making mobile apps. Over react native.
- tomphoolery 4y ago
  There's a lot of code on NPM in general, and while there's definitely a lot of warts, there's a lot of good code on there as well. It makes no sense to write off an entire package ecosystem just because some of the packages are unmaintained or poorly written. Plenty of NPM packages are useful beyond the JS ecosystem, and I think until you get a better and more reliable system for distributing those packages, NPM is probably going to be here to stay, like it or not.
- oefrha 4y ago
  The Deno/npm incompatibility up till now means a good number of popular and semi-popular npm packages got a shoddy Deno port done by someone a year ago, then never updated again. That is to say, legacy code got even more legacy.
- qbasic_forever 4y ago
  Deno still has a great standard library, so there's much less need to pull in crufty little packages to do simple tasks. IMHO the npm support in deno is more for pulling in the big packages like wrappers around databases or services and such which haven't yet written or want to write a deno-specific version. Sure you can still pull in junk like left-pad, but you don't need to do that.
buzzwords 4y ago
I have a limited experience using NodeJs. My first interaction with Node was unpleasant. The whole npm world seemed very insecure and very wide wide west like, thinking back I can't remember why I felt that now. I know the article said some would like to get away from the npm. For those who still would like to use npm with Deno, I would love to know why. (I'm genuinely curious, not looking to start a flame war)
danschumann 4y ago
Deno + Coffeescript? I mean it runs Typescript natively, so why not my favorite flavor of javascript, too? https://github.com/jashkenas/coffeescript/issues/5150 https://github.com/jashkenas/coffeescript/issues/5150
AbraKdabra 4y ago
I've been using Deno in production at work for a while, and NPM compatibility is the one thing dragging me back to Node, some packages like Elasticsearch simply won't work in Deno, if they solve that I'll be throwing a party for all HN where we collectively remove Node from all my development workspaces.
junon 4y ago
And both Deno and Bun still rely on HTTPS imports which is a nonstarter. It's a security and availability minefield. I still don't understand why they have this feature and still consider themselves security focused.
SomeCallMeTim 4y ago
This chips away at one of the showstoppers for Deno for me, which is good. But while "the vast majority" of npm packages don't require a gyp build step for native addons, some of those modules are pretty important, and I see no indication in the announcement that they're also going to be implementing the Node C API or the gyp build process. Right now I'm working with a machine learning project, and XGBoost [0] is a direct Node.js extension [1] through the binary interface. So this does bring things a step closer to being generally usable, but there are still significant roadblocks. A WebAssembly build of XGBoost could work with Deno, but aside from some guy's unsupported side project/proof-of-concept for use in a browser, I'm not seeing an XGBoost WebAssembly build. And generally when deploying something like a machine learning model I'd rather use well-supported tools than to need to dive into the rabbit hole of maintaining my own. And yes, XGBoost will likely eventually have that kind of support for Deno, but then the next bleeding-edge project will come along and only support Node. Even assuming Deno eventually hits a tipping point in popularity where everyone wants to release Node _and_ Deno support in their bleeding-edge projects, there are still things that I miss from package.json that don't seem to exist in the Deno ecosystem. Things like the "scripts" block: A nice centralized place to find all of the things that need to be done to a project, plus auto-run script entries that can trigger when a project is installed. And inheritable, overridable dependency maps (see the yarn "resolutions" block). I'd love to jump into Deno, but I think there has been far too much "baby thrown out with the bathwater" to its design. It's the classic development problem of looking at a system and seeing a ton of complexity, but not really understanding that all of that complexity was there for a reason. Maybe when it re-evolves 80% of Node's and npm's features I'll be convinced to make the jump. I'm a huge TypeScript fan after all. But it still strikes me as a violation of "As simple as possible, but no simpler." [0] XGBoost is a _very_ promising approach to machine learning, training models much faster and with much more accuracy than traditional approaches. [1] https://github.com/nuanio/xgboost-node https://github.com/nuanio/xgboost-node
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
markhaslam 4y ago
> “… will allow Deno to easily import npm packages and make 80-90% of npm packages …” Do we know what will differentiate the 10-20% of packages that won’t work?
- keyboardclicker 4y ago
  I assume it's use of node-gyp, the native plugin system. https://github.com/nodejs/node-gyp https://github.com/nodejs/node-gyp

443 points by 0xedb 4y ago

That Bun pressure though!

Wow, very interested in an npm compatible Deno! I think that will remove a huge barrier to entry for Deno and could mark a huge shift towards usage in production. I'm very interested in how packages will manage runtime support in the future. Right now we are seeing an explosion of JavaScript runtimes from Cloudflare Workers to Bun, all with sightly different APIs. I wonder if there will be an easy way to get cross-runtime support without it being much extra work for library authors. Right now, there has already been conflict with some packages being browser-only and some being node-only. I feel like there needs to be a better solution than the one we have now.

adamddev1 4y ago
Yes the lack of npm compatibility was the only thing keeping me back from Deno. I really like they way they're going to do it. `import express from "npm:express@5";`
ricardobeat 4y ago
Both Deno and Bun are adopting APIs that are close to existing web standards, so Node is becoming the odd one out.
- montroser 4y ago
  There are _lots_ and _lots_ of JavaScript runtimes out there: https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
  - ricardobeat 4y ago
    I'm very familiar with the space. The majority of these have never reached production status or any meaningful usage, the few active ones are very niche products - Duktape, Espruino, Quickjs, etc, you'll be hard pressed to find someone running a web server, gui or cli app on them. Hermes might show up in the engine radar due to how prevalent RN is, but other than that, you can bet 99% of projects run Node.js or Deno now. As long as these are actual standards, all the other runtimes also get a fair shot at implementing them. I think it's a move in the right direction.
deckard1 4y ago
> browser-only and some being node-only. Browser, node (OS-level), or serverless worker, these are all fundamentally different roles and need different API requirements. Node and serverless don't have a DOM. Serverless can't have unfettered access to the host OS. Node should be as capable as any host language (Python, Ruby, C, etc.) with an API equally powerful. The browser obviously needs a more limited sandbox. There is a parallel universe out there, where Sun had success with Java in the browser, the JVM evolved to better support distribution and HTTP standards as well as replaced the need for WASM. And we all lived in a happy world with Java on the server and Java in the browser and everything is cross-platform and Just Works(tm). Cats and dogs also live together in harmony in this world. We had big dreams in the '90s.

up6w6 4y ago

> We know there's been a lot of chatter recently about runtime speed. For reference: https://news.ycombinator.com/item?id=32457587 https://news.ycombinator.com/item?id=32457587 Btw, I like where it's going but I find it quite sad that there is no official linux ARM64 support yet - which means I can't try to use it on AWS lambda for example.

bbqbbqbbq 4y ago
viraptor 4y ago
AWS lambdas are available in Intel flavour. You don't need arm support for them.
- philliphaydon 4y ago
  By default they are x86 unless you specify ARM. I find the parent comment a bit confusing. Unless he wants the graviton 2 pricing and perf benefits. Which I 100% support!!! Love graviton!
crowlKats 4y ago
ARM64 builds are something that has been getting investigated. The biggest problem is that github doesnt provide any ARM64 runners, so workarounds around that are necessary

qwertyuiop_ 4y ago

Looks like Deno took notice of Bun https://bun.sh/ https://bun.sh/

hjanssen 4y ago

Not sure if Bun has had an influence on this, these features must have been in development for a long time, but the timing surely is impeccable. npm compatibility is huge for Deno. It is basically the one major drawback to Deno, which gets hopefully fixed with this feature. It also looks like this compatibility layer is implemented transparently in the existing module management, which is a big bonus. Nobody wants to deal with node_modules anymore when working with Deno for an extended period, just love to see this.

Zachsa999 4y ago
I imagine yes, bun put pressure on to launch node package compatibility. Any thoughts on speed reliability concerns comparing the two?
12many 4y ago
If you deep dive into bun, it only has the gained performance for certain features and cant really even be compared to deno or node at the moment because it lacks so many other features that would better showcase its speed.
- treyhuffine 4y ago
  Here's a good summary that details your point on what Bun does well and where it lacks - https://levelup.gitconnected.com/is-bun-js-the-node-js-killer-ffeb0f89196a https://levelup.gitconnected.com/is-bun-js-the-node-js-kille...
  - OJFord 4y ago
    Hm, that claims SQLite is 'never' used for web backends; Bun says it's motivated for use 'at the edge' - first thing I thought of when I read that was Fly.io/Litestream: https://fly.io/blog/all-in-on-sqlite-litestream/ https://fly.io/blog/all-in-on-sqlite-litestream/ (No idea if there's any relationship between the projects, just makes me think that article's a bit dismissive.)
- gureddio 4y ago

resoluteteeth 4y ago

NPM compatibility is probably the most important thing currently holding up people from adopting deno so this is pretty significant

nitsky 4y ago

Will Deno’s approach to NPM compatibility support peer dependencies? https://nodejs.org/en/blog/npm/peer-dependencies/ https://nodejs.org/en/blog/npm/peer-dependencies/ Furthermore, will it support unifying transitive dependency versions to minimize bundle sizes?

lucacasonato 4y ago
Yes, this will be supported.
- nitsky 4y ago
  Hi Luca, can you provide a bit of detail on how this will be accomplished? Will Deno be analyzing an entire project’s npm imports simultaneously, rather than individually?
  - dsherret 4y ago
    Deno already analyzes the entire module graph before the application starts up, so we extract out the npm specifiers ahead of time, do the npm dependency analysis, cache any packages as needed, then start execution.
    - nitsky 4y ago
      Thanks. Any plans for supporting monorepos of first party NPM packages that teams already have?
      - dsherret 4y ago
        We'll have custom registry support. For local npm packages, that would be nice to have, but probably something that will be implemented later. It could actually be done in a hacky way with the existing implementation of this we have, but it would be better to have something specifically designed for this.

stall84 4y ago

awwwwhhhh snap! this can really open the runtime up

sph 4y ago
Finally. This kind of freedom of choice was sorely missing in the JavaScript world. Not only I will be able to choose package manager, frontend flavour, backend flavour, build system, unit testing framework, now I will be able to choose which runtime to pick as well. I can't wait to see how productive my team will be when this ships.
- swyx 4y ago
  what a first world problem to complain about too much choice.
  - sph 4y ago
    You can reduce most tech discussion on this forum to a first world problem, so that's not very constructive either.

mattlondon 4y ago

This is pleasing to see - no node_modules, no npm install. Just a special import format. They are not clear if you need to have npm installed or not for this to work. I sincerely hope not - if it requires a locally-installed npm then they've shat the bed I think... that would be a major turn-off for me. Can't say I've ever been concerned by the performance of Deno, but looking forward to seeing this playout anyway since faster is always nice to have.

lucacasonato 4y ago
You will not need node or npm installed.
dmitriid 4y ago
> This is pleasing to see - no node_modules, no npm install. Just a special import format. You will still have both of those when deno resolves all dependencies and downloads them all. It will just be hidden from you by "magic".

chrismorgan 4y ago

As a non-user of Deno, I’m curious, how do people tend to manage dependency version centralisation in Deno? I suppose this will apply to existing Deno as well as npm imports. I can just see you ending up having to change “import express from "npm:express@5";” from 5 to 6 in lots of places when the next major version comes out. When contemplating how I might do it, I came up with centralised reexport, a file deps.ts containing: export express from "npm:express@5"; This would basically stand in for the dependencies object in package.json. So then I looked up the docs and found https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere https://deno.land/manual/linking_to_external_code#it-seems-u... and was amused to find the same solution, even down to the file name “deps.ts”! Is this how people tend to work with Deno? I see it also supports import maps, https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map..., which could readily solve the problem too. Do people use that?

yesbabyyes 4y ago
I've only built a few toy apps with Deno. I use import maps and consider them the canonical solution.
crowlKats 4y ago
deps.ts is currently the most common way, however new projects like fresh use import maps. the problem with importmaps is they are not composable, as such, using an importmap for a library is usually bad as said importmap is not picked up and used, so the end-user would have to add their own importmap with entries compatible for the library (this is what fresh does: it generates an importmap with entries it needs). due to this problem, deps.ts is the most common solution, however I do hope that composability issue with importmaps will change.
- conaclos 4y ago
  It could be nice to have import-maps composability. However, I don't think it is planned because browsers' import-maps are not composable. I dislike the deps.ts concept. It is one of the main reason I did not switch to Deno yet.

paulgb 4y ago

> import express from "npm:express@5"; I'm excited to see this, and I'm sure they'll work this out, but I sure hope I don't have to keep dependency versions in sync across all of my import statements. I don't have much love for package.json and node_modules, but it is nice to have one source-of-truth for all the dependencies of a project.

dsego 4y ago
https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere https://deno.land/manual/linking_to_external_code#it-seems-u...
- dmitriid 4y ago
  This is package.json with extra steps. And yet, people using Deno are so against package management.
  - itslennysfault 4y ago
    Seriously, no idea why anyone things this is a better option. Seems like more work, and if two packages export things with the same name you have to use aliases. Also, seems like this could get REALLY messy on large projects. I LOVE TypeScript, and was so excited about Deno when I first saw it, but the lack of package.json "feature" is a huge turn off for me. I sometimes feel like I'm the only person that has no problem with package.json. I think it works great.
    - Arnavion 4y ago
      Haven't used deno but I assume the standard `export * as asserts from "https://deno.land/std@0.152.0/testing/asserts.ts https://deno.land/std@0.152.0/testing/asserts.ts";` will work, which is the same effort as a package.json and does not create any identifier conflicts.
      - dmitriid 4y ago

ricardobeat 4y ago

I hope we figure out a better way to deal with the mountain of dead (and just plain bad) packages on NPM. Not carrying this legacy always sounded like a plus to me, but I haven't used Deno in production yet. It's also interesting to note how the tone changes after receiving funding. May just be a coincidence, but this looks like a reactionary jab back at Bun, which is barely out of the gate.

benatkin 4y ago
The first individual investor in the funding announcement is Nat Friedman, who defended ICE while at GitHub. I was one of many who signed the petition and cancelled my GitHub Pro account. Node is still a community project, since the creation of the Node.js Foundation. I feel like switching to Deno would be going backwards. https://www.theverge.com/2019/10/9/20906213/github-ice-microsoft-software-email-contract-immigration-nonprofit-donation https://www.theverge.com/2019/10/9/20906213/github-ice-micro...
- andrew_ 4y ago
  This seems unrelated to the parent and a bit of soapboxing.
  - zemo 4y ago
    can't say that I agree, it's in response to this: > It's also interesting to note how the tone changes after receiving funding. seems on-topic to me.
qbasic_forever 4y ago
Deno has had a node compatibility flag for a while now, and quite a few node packages have worked flawlessly. For anyone who has been using deno for some time this is not a big surprise to see smoother npm import support. I think all the people saying this is such a giant, game-changing big deal or that deno has changed, blah blah haven't actually been using it...

timmg 4y ago

This might sound odd, but: one thing I've wanted to do is use the Typescript compiler without using NPM. (I'm not smart enough to know why I hate NPM. I just want a tool that compiles TS.) It almost sounds like I could write a self-contained deno command-line "app" that does this. Does that seem right (for those that know better)?

ricardobeat 4y ago
What you're looking for is ESBuild: https://esbuild.github.io/ https://esbuild.github.io/ TS "compilers" basically strip out the type annotations, they don't care about the validity of the types, so you'll be missing out on the main reason to be using TypeScript.
- tomxor 4y ago
  esbuild is so awesome... my steps towards web dev sanity are 1. Switch everything to esbuild, remove 10k dependency security nightmare, bloatfest and slugishness of pretty much every other node based build system / bundler. 2. Switch to deno. Haven't quite got to deno yet, but #1 was liberating. esbuild also has some preliminary deno support, but not sure how stable it is. The main thing I like about esbuild is that I feel like I wont ever have to "migrate" build system again (and I have to deal with an unusually high number of repos so this is a big deal), not much in my repos have anything esbuild specific, migrating was more a matter of removing build system specific smells from repos, it's all just a js and css bundle now. i.e there could be something better than esbuild in the future, and switching to that should in theory be effortless. This has never been true for all of the NPM build systems prior, (I was there at the beginning with grunt).
  - vbezhenar 4y ago
    Why do you want to switch to deno? I still don't understand what's the reason to use it over node.
    - conaclos 4y ago

alvis 4y ago

I wish there is more clarity about package dependency will be resolved from Deno? Supporting npm is one big step forward, but without a package-lock.json that locks all child dependencies, it’d be a nightmare using the new compatibility in production

AgentME 4y ago
Deno optionally supports lock files, though its current lock files are just for asserting that specific URLs have specific hashes rather than controlling where/which dependencies are found. Maybe its lock files will be extended for handling this.

andrewmcwatters 4y ago

It would be nice if they included a compat flag for importing without this special syntax. As it stands, there is no clear drop-in replacement path for Deno, and as a result, I have no interest in using it. I'm not rewriting my work so someone can have fun playing with VC money and abandon mature software.

bartlomieju 4y ago
"compat" mode has been supported for some months now: https://deno.land/manual/node/compatibility_mode https://deno.land/manual/node/compatibility_mode

pier25 4y ago

People ITT mention Bun but I'm sure performance was always in the mind of Ryan et al. They were probably too busy with other stuff though.

andrew_ 4y ago

> We've been working on some updates that will allow Deno to easily import npm packages and make the vast majority of npm packages work in Deno within the next three months. This is really huge and will be a huge boost to the Deno ecosystem. On the other hand, I quite enjoyed that it wasn't jacked into NPM. There were reasonable alternatives like https://jspm.org/ https://jspm.org/. This is a big swing at Node and I'll be watching with maximum curiosity. As an aside, the only thing preventing me from adopting Deno as my daily driver has been the lack of AWS Lambda support (requiring a lambda layer, slowing down cold starts). Would be great if they could leverage connections and advocate for native AWS support.

alvis 4y ago
Well. While there's no official AWS Lambda runtime, you can always use a custom image to use deno as a lambda function. Here is just one from the community https://github.com/hayd/deno-lambda https://github.com/hayd/deno-lambda
- andrew_ 4y ago
  As I had mentioned, it requires using a Lambda Layer. See: https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e1a7f34cf9e5f69a90479a/example-aws-cdk/cdk/example-aws-cdk-stack.ts#L19-L23 https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e... Using your own image (i.e. without using the base AWS image with the layer) you'd get even worse cold start times.

jerrygoyal 4y ago

> 80-90% of npm packages work in Deno within the next three months. curious what kind of npm packages won't be supported in Deno

SahAssar 4y ago
Probably ones that use N-API or the ones that compile native addons.
- bartlomieju 4y ago
  N-API will be supported in future releases of Deno, we have a PR going that is close to completion.

wokwokwok 4y ago

> import express from "npm:express@5"; > There will be no node_modules folder, no npm install; the packages will be automatically downloaded in the Deno cache. My understanding of deno's package system (see https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere https://deno.land/manual/linking_to_external_code#it-seems-u...), is that basically, at compile time it will go and fetch external URLs and cache those files locally. So this change basically makes it so your import: > import { assert } from "https://deno.land/std@0.152.0/testing/asserts.ts https://deno.land/std@0.152.0/testing/asserts.ts"; Is magically generated from npm when you do this instead: > import { assert } from "npm:testing@2.0.1"; Ok cool. Whatever. ...surely this isn't the actual problem? There seem to be certain pretty fundamental problems: - not all npm packages are typescript - a package is not just an 'assert.ts' file, it's often an amalgamation (eg. using rollup) - a package often has many dependencies - a package may use the node API, that deno doesn't have (it has a more-or-less compatibility mode, see 'differences that cannot be overcome' -> https://deno.land/manual/node https://deno.land/manual/node) So bluntly, how on earth is this going to work? I mean, I'm a fan, the folk working on Deno are smart and motivated, and if it works, I'm more 'wow' than 'I don't believe it'... but I'm very surprised to see: > the vast majority of npm packages work in Deno within the next three months That seems... ambitious. I can't see how the approach is really sustainable, given that basically, it means 'anything node supports we have to support to'; doesn't that mean you're forever playing catchup and 'doesn't quite work'? How is vendoring going to work without a package lock file? Doesn't this just mean you've reimplemented npm and you'll forever be playing catchup to the various npm features that are required to make packages work?

frenchman99 4y ago
> not all npm packages are typescript All Javascript is Typescript isn't it?
- georgyo 4y ago
  All typescript is JavaScript, not all JavaScript is typescript.

glutamate 4y ago

AsyncLocalStorage support (https://github.com/denoland/deno/issues/7010 https://github.com/denoland/deno/issues/7010; essentially thread local storage) pretty pretty please?

substation13 4y ago

If we really care about performance, then this split between the runtime and user code is not ideal. What we should be trying to do is bake the user code into the runtime and apply total program optimization. This can be done today with C, C++ and Rust. However, in principle JavaScript code could be transpiled to Zig and then baked into Deno.

brrrrrm 4y ago
JITs (as those found in V8, JSC, SpiderMonkey) can theoretically compile better code than static compilation approaches like C, C++, and Rust. It's because the runtime can collect information about what is being run and then generate code accordingly.
- yencabulator 4y ago
  https://arxiv.org/abs/1602.00602 https://arxiv.org/abs/1602.00602 is a good exploration of why this just doesn't work out, and at best tends to lead to weird stuttering performance.
- whatshisface 4y ago
  Static compilers can also sometimes do that, it's called profile-guided optimization.
- emtel 4y ago
  This is true in some situations, but I think is mostly a just-so story told about JITed languages. Here's the problems: 1) Often, you have lots of code that only runs once (e.g. UI initialization), or runs rarely (click handlers). By the time the JIT has had an opportunity to observe this code and optimize it, it may be too late. 2) The dynamic nature of JS means that making your code JIT-friendly requires deep knowledge of what language features to avoid. 3) Performance isn't only driven by having the tightest possible machine code. Memory layout is often more important on modern processors. Indirection causes cache misses, and JS objects contain far more indirection than equivalent structs defined in C/C++/Rust. Further, in Javascript you can't really create cache-friendly collections of objects like vectors, BTreeMaps, etc.

brrrrrm 4y ago

> the next release of Deno will include a new HTTP server. It is the fastest JavaScript web server ever built. I feel unease reading untestable claims (with no numbers) about future releases. I'm made more uneasy by the fact that this is the second bullet point of the main tl;dr. It makes me wonder, what are the organizational incentives driving such a publication?

rglover 4y ago
Fealty.

lukevp 4y ago

Demo is awesome, and the npm compatibility is a game changer. Isn’t this the 3rd http server rewrite in less than a year though? They didn’t mention it being backwards compatible. I guess they needed to change the underlying server to support features in Fresh. This is one downside of the team making the core platform as well as many of the main components of the ecosystem… they can evolve the runtime to suit their vision even if it affects competitor’s implementations.

bartlomieju 4y ago
New server API is modelled after API available in "std/http/server.ts", so for most folks it should be a drop in replacement.

hardwaregeek 4y ago

This isn't entirely fair to Deno but it always amazes me how people start out with "we don't need packages! Just do direct imports" and eventually end up with "okay fine fine here's a package manager". Packages are great! Don't dismiss them just because in edgecases they're bad. In fairness, the two examples, Deno and Go, are successful projects, so maybe it's not a bad initial strategy.

johannes1234321 4y ago
Is deno successful? I (in my limited world) don't know anybody using it and don't see it mentioned in job descriptions etc. And to comparing to other languages: It's not like "ok, projects became to big we need better package management" or something, but to me reads more like "there's too little deno stuff and migration prevents people from going here, so let's try to embrace the other runtime's stuff so maybe more people can use our runtime without having to start from scratch"
- IshKebab 4y ago
  I think there's quite a big gap between success and being more popular than NPM. Plus it's only a few years old. Job adverts are usually several years behind what companies actually use and companies are behind what hobbyists use. I'd say it is on a successful trajectory. The main issue with it was NPM compatibility so I think this is a very very wise move, even if it is pragmatic rather than ideal.
- qbasic_forever 4y ago
  It's not even 5 years old, give it some time for people to pick it up and use it. Python was created in '91 but even by '96 it still wasn't widely used.
speedgoose 4y ago
The lack of packages in Golang is super annoying though. And I wonder about the mess it will be when something better than git will be popular.

stoicjumbotron 4y ago

Does something like patch-package: https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package exists for Deno? If yes/no how does it work/would work?

AgentME 4y ago
With normal Deno dependencies, you could use an import map to accomplish patches like this. Not sure if that currently is planned to work for npm sub-dependencies but it seems like a natural place for that to be implemented.

afavour 4y ago

I'm actually a little disappointed by NPM compatibility. Or at least conflicted. Deno has felt like an opportunity to reboot the server-side JS ecosystem into something far more sensible than it currently is. Not that anyone is to blame for what it is, really, but you learn lessons and move forward. Sometimes making breaking changes. This seems like an acceptance that moving on simply won't happen. The existing ecosystem is too big and too powerful to be ignored. If I were a particularly cynical person I'd also point to Deno taking on millions in VC funding - once you've done that you can't be content to create a perfect, gleaming sandbox. You have to bring in money.

lukevp 4y ago
I think this is the motivation behind requiring an npm: prefix. It is a way to virtue signal for devs who buy into the deno goals to push for migrating to non-“legacy” packages. If you see an npm: prefix in a deps.ts file you can consider it tech debt. And potentially set up a lint rule to enforce it in the future. If they had not put an explicit reference in the source (passed through the packages transparently or kept a server side list of packages on npm) then it wouldn’t be colocated with the source and the PR processes. I think this was a good move overall.
- brundolf 4y ago
  It's not just a "virtue signal"; those packages will have to go through some special (and pretty aggressive) transpiling in order to work. This wasn't just flipping a switch from the Deno team
  - bartlomieju 4y ago
    That's not really what's happening behind the scenes. We are consuming sources as they are provided in npm using "compat layer" that is part of Deno's standard library. We had to provide special module resolution, but besides polyfill for built-in Node APIs, it works very similar to how Node consumes these packages.
    - 4y ago

maxpert 4y ago

So we've come full circle. From the talk of author on how "NPM was a big mistake", to "Nobody is adopting it, we will die without the NPM ecosystem". I was hoping that Deno will spin off into something that can be compiled due to type system hints into something more optimized than JS, but seems like I was just living in dystopian utopia.

bbqbbqbbq 4y ago
aliswe 4y ago
you still sound quite dystopian!

AtNightWeCode 4y ago

> ...make 80-90% of npm packages work in Deno... Can this really be right? What is the number for Nodejs?

brundolf 4y ago

The NPM thing is a huuuuge deal. This has been by far the biggest thing holding Deno back, but it was tough because one of Deno's most exciting benefits was standardizing the module system and ditching NPM. It looks like they may have found a best-of-both-worlds solution for shoehorning NPM's massive ecosystem into Deno while it's still building out its own. Big changes indeed. That, and the emphasis on speed (esp quotes like "We aren't optimizing for a handful of edge cases, but for overall real world performance") makes me wonder if Bun is lighting a fire under them a bit. It's still a long way from catching up, but it's been closing the gap at a blistering pace and getting enormous amounts of hype. The more competition the better. Exciting times

999900000999 4y ago

>Deno to easily import npm packages and make 80-90% of npm packages work in Deno within the next three months. I get it, I understand it, but it is depressing to know that we're going to be dealing with horribly ridden legacy NPM code for the next 800 years. A lot of the code on NPM is just bad. And now we're going to keep this legacy of just, bad JavaScript . This is why I prefer dart and flutter for making mobile apps. Over react native.

tomphoolery 4y ago
There's a lot of code on NPM in general, and while there's definitely a lot of warts, there's a lot of good code on there as well. It makes no sense to write off an entire package ecosystem just because some of the packages are unmaintained or poorly written. Plenty of NPM packages are useful beyond the JS ecosystem, and I think until you get a better and more reliable system for distributing those packages, NPM is probably going to be here to stay, like it or not.
oefrha 4y ago
The Deno/npm incompatibility up till now means a good number of popular and semi-popular npm packages got a shoddy Deno port done by someone a year ago, then never updated again. That is to say, legacy code got even more legacy.
qbasic_forever 4y ago
Deno still has a great standard library, so there's much less need to pull in crufty little packages to do simple tasks. IMHO the npm support in deno is more for pulling in the big packages like wrappers around databases or services and such which haven't yet written or want to write a deno-specific version. Sure you can still pull in junk like left-pad, but you don't need to do that.

buzzwords 4y ago

I have a limited experience using NodeJs. My first interaction with Node was unpleasant. The whole npm world seemed very insecure and very wide wide west like, thinking back I can't remember why I felt that now. I know the article said some would like to get away from the npm. For those who still would like to use npm with Deno, I would love to know why. (I'm genuinely curious, not looking to start a flame war)

danschumann 4y ago

Deno + Coffeescript? I mean it runs Typescript natively, so why not my favorite flavor of javascript, too? https://github.com/jashkenas/coffeescript/issues/5150 https://github.com/jashkenas/coffeescript/issues/5150

AbraKdabra 4y ago

I've been using Deno in production at work for a while, and NPM compatibility is the one thing dragging me back to Node, some packages like Elasticsearch simply won't work in Deno, if they solve that I'll be throwing a party for all HN where we collectively remove Node from all my development workspaces.

junon 4y ago

And both Deno and Bun still rely on HTTPS imports which is a nonstarter. It's a security and availability minefield. I still don't understand why they have this feature and still consider themselves security focused.

SomeCallMeTim 4y ago

This chips away at one of the showstoppers for Deno for me, which is good. But while "the vast majority" of npm packages don't require a gyp build step for native addons, some of those modules are pretty important, and I see no indication in the announcement that they're also going to be implementing the Node C API or the gyp build process. Right now I'm working with a machine learning project, and XGBoost [0] is a direct Node.js extension [1] through the binary interface. So this does bring things a step closer to being generally usable, but there are still significant roadblocks. A WebAssembly build of XGBoost could work with Deno, but aside from some guy's unsupported side project/proof-of-concept for use in a browser, I'm not seeing an XGBoost WebAssembly build. And generally when deploying something like a machine learning model I'd rather use well-supported tools than to need to dive into the rabbit hole of maintaining my own. And yes, XGBoost will likely eventually have that kind of support for Deno, but then the next bleeding-edge project will come along and only support Node. Even assuming Deno eventually hits a tipping point in popularity where everyone wants to release Node _and_ Deno support in their bleeding-edge projects, there are still things that I miss from package.json that don't seem to exist in the Deno ecosystem. Things like the "scripts" block: A nice centralized place to find all of the things that need to be done to a project, plus auto-run script entries that can trigger when a project is installed. And inheritable, overridable dependency maps (see the yarn "resolutions" block). I'd love to jump into Deno, but I think there has been far too much "baby thrown out with the bathwater" to its design. It's the classic development problem of looking at a system and seeing a ton of complexity, but not really understanding that all of that complexity was there for a reason. Maybe when it re-evolves 80% of Node's and npm's features I'll be convinced to make the jump. I'm a huge TypeScript fan after all. But it still strikes me as a violation of "As simple as possible, but no simpler." [0] XGBoost is a _very_ promising approach to machine learning, training models much faster and with much more accuracy than traditional approaches. [1] https://github.com/nuanio/xgboost-node https://github.com/nuanio/xgboost-node

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

markhaslam 4y ago

> “… will allow Deno to easily import npm packages and make 80-90% of npm packages …” Do we know what will differentiate the 10-20% of packages that won’t work?

keyboardclicker 4y ago
I assume it's use of node-gyp, the native plugin system. https://github.com/nodejs/node-gyp https://github.com/nodejs/node-gyp