5 ms·

Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it

by msoad 5y ago

Has anyone tried switching from Node to Deno in an existing project? I'm personally very interested in Deno but it's hard to find a greenfield project to try it out and writing toy programs is not giving me enough insights of how much better/faster Deno is.

yulaow 5y ago
Honestly not and for a simple reason: there is nothing in deno that I need and can't find in node, but there are a lot of libraries in node that I need and I can't use them in deno. Simple as that
- encryptluks2 5y ago
  Such as? Do you mean things in the standard library or like JS packages?
  - tentacleuno 5y ago
    Probably both. You can't use NPM (though you can use one of those online CDN's like unpkg) and the packages you can use probably don't work, as Deno doesn't support Node's API at all. It doesn't support any Node-specific packages like 'fs' or 'crypto' either. Unless you're writing a totally new application and don't need anything (even retrospectively) from NPM, Deno probably won't work for you. As much as I like Deno as a concept, I can't really use it. Making a totally new JavaScript runtime with new API's and no compatibility with the current largest runtime is a very ambitious goal, and I hope they succeed with it nevertheless.
    - MarkBennett 5y ago
      You might want to consider giving Deno another shot, as they've spent a lot of time on building node comparability since v1.15 specifically to address these problems. Many of the APIs you mentioned are supported already, while a few require the unstable flag... https://deno.land/std/node/README.md https://deno.land/std/node/README.md In my experience I've been able to use many node packages unmodified recently.
    - afavour 5y ago
      > and no compatibility with the current largest runtime Well… the current largest runtime is web browsers and Deno has a much better story there than Node does. But agreed, it’s a long road ahead.
  - erikpukinskis 5y ago
    I was playing with Deno for a side project about 6 months ago but stopped because none of the WebRTC handshake modules were supported. I tried to push through and port one of them, but the base Node Socket library was missing most of the methods. Deno looks awesome though, I can’t wait to take another look when it’s a little more mature!
    - chaosharmonic 5y ago
      It's a pretty ergonomic way of scripting smaller tasks, at least. The first time picked it up for the sake of a meaningful experiment I stopped short of actually deploying a full project on it -- the key limitation being that I couldn't find anything comparable to Mongoose -- but did end up building a companion tool that turned out to be pretty useful, and for stuff like API calls and bulk file manipulation I would reach for it every time. Specifically, it was a minimal simfile parsing/conversion/seeding tool, as part of a DDR workout tracker I was working on a while ago. (Everything from COVID to a mouse problem in my workspace kind of undercut me doing the cardio I had built it to track, so it sort of stagnated :-/ But the tooling itself was pleasant enough here.) Basically it had three core pieces of functionality: - Parsing .sm files and converting them to .ssc (the former doesn't label its fields, so doing this first simplified everything else) - Extracting metadata from simfiles in .ssc format and exporting it to JSON - Uploading extracted metadata to the accompanying API This is something of a moot point since it's been added to Node now, but at the time having access to server-side `fetch()` also saved me some frontend work, because then all of my client-side requests became isomorphic and I could just mock out what I was eventually going to need for my UI without actually having to make any other decisions about how the UI was going to be structured.
jitl 5y ago
I have enough trouble upgrading Node versions in serious projects. I don’t think it makes sense to convert a big existing project.
- cersa8 5y ago
  What kind of problems did you encounter ? I recently switched from v12 to v16 without any problems on a decent sized project. I was expecting to break a few things and surprised how smooth it all went.
mcraiha 5y ago
Maybe someone working with a library project can answer that. Trying to replace node with deno in e.g. React + NPM project might be way too complicated. Personally I won't taking part in any node projects anymore.
- o_m 5y ago
  The best way to start using Deno with React is to use Remix
ignoramous 5y ago
> ...enough insights of how much better/faster Deno is We moved our Deno project to Node because of lack of lower-level APIs on Deno's Conn interfaces [0][1], but otherwise for our use-case (lots of tiny HTTPS connections) Deno absolutely blew Node out-of-the-water. Even at p50 (100tps) Deno (v1.18) was 10x faster than Node (v17.x) [2] RAM wise, I found Deno (v1.18+) use 10M or so higher for the same code-base. DevEx wise, Node is miles away from Deno, but it might get there in-time, or it might not [3]. I'd imagine, what may also work in Deno's favour in terms of IO-bound workloads, is the underlying tokio layer (vs libuv in Node). API wise, Deno (comparatively) feels quite raw. [0] https://github.com/denoland/deno/issues/13636 https://github.com/denoland/deno/issues/13636 [1] https://github.com/denoland/deno/issues/9109 https://github.com/denoland/deno/issues/9109 [2] https://github.com/nodejs/undici/issues/1203#issuecomment-1033019530 https://github.com/nodejs/undici/issues/1203#issuecomment-10... | Explanation: https://github.com/RafaelGSS/nodejs-bench-operations/pull/3#issuecomment-1066872997 https://github.com/RafaelGSS/nodejs-bench-operations/pull/3#... [3] https://www.youtube-nocookie.com/embed/M3BM9TB-8yA https://www.youtube-nocookie.com/embed/M3BM9TB-8yA
- deleted 5y ago
  [deleted]
- inglor 5y ago
  If anyone wants to work on this (make web streams faster in Node) it'd be welcome. The main reason web streams are slower in Node is a lot less work has been put into making them fast. They're mostly seen as an interop layer.
- laurencerowe 5y ago
  I think it could make sense to implement lower-level APIs in Rust and then expose higher level APIs to JavaScript so that connections to upstream services can be shared across a pool of JavaScript Workers. When running NodeJS at scale we had to add proxy servers to pool connections to upstream services which had been designed for smaller numbers of more highly utilized connections from large multithreaded Java application servers.
Hamcha 5y ago
Not switching from Node, but I've been building some Typescript libraries that are mainly for the browser and when building command line app versions for them, Deno worked out of the box while Node has hiccups (no Fetch, no Websockets, etc) and since Deno works so well I just never added Node support. Small aside: if you ever plan on doing Deno-first libraries, https://deno.land/x/dnt@0.20.1 https://deno.land/x/dnt@0.20.1 is a library that takes a Deno project and builds an entire Node project with shims (sadly only for Deno-specific stuff, so no node-fetch or ws) so you can publish to NPM.
beaker52 5y ago
I'm an existing typescript user but I just can't see a reason to use Deno. Depending on the NPM repository CDN is less worrisome than depending n different CDNs. Including all my dependencies unilaterally (aka deps.ts) seems like a patch upon a bad decision. Making the server side runtime environment pretend to be or adopt aspects of the web browser client environment seems like a misguided direction in my wisdom, because it compromises the whole runtime and you it'll always eventually fall short, as everything that copies does. With everything going toward serverless, support there is essential and Deno just doesn't have it. Lack of backward compatibility with other libraries means an uphill struggle, likely resulting in a lot of ported and unmaintained packages. I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. For all these reasons, I regard Deno as dubious for now. I say all of this narrowly through my own experience and perception.
- azangru 5y ago
  > I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack. Deno is more appealing to seasoned web developers, who appreciate its conformity to modern web standards, the absence of Node quirks, and a better security. Example: discussion of Deno by two Google developer relations engineers: https://www.youtube.com/watch?v=SYkzk_j3yb0 https://www.youtube.com/watch?v=SYkzk_j3yb0
  - k__ 5y ago
    "This is a really strange take." No, this is the gatekeeping mentality of many people software development. It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.
    - beaker52 5y ago
nllsh 5y ago
I haven't done an existing project yet, but based on some experiments it seems like I'd mostly be deleting configuration files and making an import map. A simple SPA is crazy easy in deno: https://github.com/baetheus/deno-spa-example/ https://github.com/baetheus/deno-spa-example/
inglor 5y ago
I've switched a few projects back and forth but I am on the more experienced side (I'm comfortable with both codebases and have 2 digit commit numbers in both projects). My motivation for Node was that Deno's instrumentation/APM story doesn't exist which is a show stopper for many production apps and a lot of stuff was missing. My motivation for Deno was trying out deploy (their edge computing offering) which is really cool.

by msoad 5y ago

yulaow 5y ago

Honestly not and for a simple reason: there is nothing in deno that I need and can't find in node, but there are a lot of libraries in node that I need and I can't use them in deno. Simple as that

encryptluks2 5y ago
Such as? Do you mean things in the standard library or like JS packages?
- tentacleuno 5y ago
  Probably both. You can't use NPM (though you can use one of those online CDN's like unpkg) and the packages you can use probably don't work, as Deno doesn't support Node's API at all. It doesn't support any Node-specific packages like 'fs' or 'crypto' either. Unless you're writing a totally new application and don't need anything (even retrospectively) from NPM, Deno probably won't work for you. As much as I like Deno as a concept, I can't really use it. Making a totally new JavaScript runtime with new API's and no compatibility with the current largest runtime is a very ambitious goal, and I hope they succeed with it nevertheless.
  - MarkBennett 5y ago
    You might want to consider giving Deno another shot, as they've spent a lot of time on building node comparability since v1.15 specifically to address these problems. Many of the APIs you mentioned are supported already, while a few require the unstable flag... https://deno.land/std/node/README.md https://deno.land/std/node/README.md In my experience I've been able to use many node packages unmodified recently.
  - afavour 5y ago
    > and no compatibility with the current largest runtime Well… the current largest runtime is web browsers and Deno has a much better story there than Node does. But agreed, it’s a long road ahead.
- erikpukinskis 5y ago
  I was playing with Deno for a side project about 6 months ago but stopped because none of the WebRTC handshake modules were supported. I tried to push through and port one of them, but the base Node Socket library was missing most of the methods. Deno looks awesome though, I can’t wait to take another look when it’s a little more mature!
  - chaosharmonic 5y ago
    It's a pretty ergonomic way of scripting smaller tasks, at least. The first time picked it up for the sake of a meaningful experiment I stopped short of actually deploying a full project on it -- the key limitation being that I couldn't find anything comparable to Mongoose -- but did end up building a companion tool that turned out to be pretty useful, and for stuff like API calls and bulk file manipulation I would reach for it every time. Specifically, it was a minimal simfile parsing/conversion/seeding tool, as part of a DDR workout tracker I was working on a while ago. (Everything from COVID to a mouse problem in my workspace kind of undercut me doing the cardio I had built it to track, so it sort of stagnated :-/ But the tooling itself was pleasant enough here.) Basically it had three core pieces of functionality: - Parsing .sm files and converting them to .ssc (the former doesn't label its fields, so doing this first simplified everything else) - Extracting metadata from simfiles in .ssc format and exporting it to JSON - Uploading extracted metadata to the accompanying API This is something of a moot point since it's been added to Node now, but at the time having access to server-side `fetch()` also saved me some frontend work, because then all of my client-side requests became isomorphic and I could just mock out what I was eventually going to need for my UI without actually having to make any other decisions about how the UI was going to be structured.

jitl 5y ago

I have enough trouble upgrading Node versions in serious projects. I don’t think it makes sense to convert a big existing project.

cersa8 5y ago
What kind of problems did you encounter ? I recently switched from v12 to v16 without any problems on a decent sized project. I was expecting to break a few things and surprised how smooth it all went.

mcraiha 5y ago

Maybe someone working with a library project can answer that. Trying to replace node with deno in e.g. React + NPM project might be way too complicated. Personally I won't taking part in any node projects anymore.

o_m 5y ago
The best way to start using Deno with React is to use Remix

ignoramous 5y ago

> ...enough insights of how much better/faster Deno is We moved our Deno project to Node because of lack of lower-level APIs on Deno's Conn interfaces [0][1], but otherwise for our use-case (lots of tiny HTTPS connections) Deno absolutely blew Node out-of-the-water. Even at p50 (100tps) Deno (v1.18) was 10x faster than Node (v17.x) [2] RAM wise, I found Deno (v1.18+) use 10M or so higher for the same code-base. DevEx wise, Node is miles away from Deno, but it might get there in-time, or it might not [3]. I'd imagine, what may also work in Deno's favour in terms of IO-bound workloads, is the underlying tokio layer (vs libuv in Node). API wise, Deno (comparatively) feels quite raw. [0] https://github.com/denoland/deno/issues/13636 https://github.com/denoland/deno/issues/13636 [1] https://github.com/denoland/deno/issues/9109 https://github.com/denoland/deno/issues/9109 [2] https://github.com/nodejs/undici/issues/1203#issuecomment-1033019530 https://github.com/nodejs/undici/issues/1203#issuecomment-10... | Explanation: https://github.com/RafaelGSS/nodejs-bench-operations/pull/3#issuecomment-1066872997 https://github.com/RafaelGSS/nodejs-bench-operations/pull/3#... [3] https://www.youtube-nocookie.com/embed/M3BM9TB-8yA https://www.youtube-nocookie.com/embed/M3BM9TB-8yA

deleted 5y ago
[deleted]
inglor 5y ago
If anyone wants to work on this (make web streams faster in Node) it'd be welcome. The main reason web streams are slower in Node is a lot less work has been put into making them fast. They're mostly seen as an interop layer.
laurencerowe 5y ago
I think it could make sense to implement lower-level APIs in Rust and then expose higher level APIs to JavaScript so that connections to upstream services can be shared across a pool of JavaScript Workers. When running NodeJS at scale we had to add proxy servers to pool connections to upstream services which had been designed for smaller numbers of more highly utilized connections from large multithreaded Java application servers.

Hamcha 5y ago

Not switching from Node, but I've been building some Typescript libraries that are mainly for the browser and when building command line app versions for them, Deno worked out of the box while Node has hiccups (no Fetch, no Websockets, etc) and since Deno works so well I just never added Node support. Small aside: if you ever plan on doing Deno-first libraries, https://deno.land/x/dnt@0.20.1 https://deno.land/x/dnt@0.20.1 is a library that takes a Deno project and builds an entire Node project with shims (sadly only for Deno-specific stuff, so no node-fetch or ws) so you can publish to NPM.

beaker52 5y ago

I'm an existing typescript user but I just can't see a reason to use Deno. Depending on the NPM repository CDN is less worrisome than depending n different CDNs. Including all my dependencies unilaterally (aka deps.ts) seems like a patch upon a bad decision. Making the server side runtime environment pretend to be or adopt aspects of the web browser client environment seems like a misguided direction in my wisdom, because it compromises the whole runtime and you it'll always eventually fall short, as everything that copies does. With everything going toward serverless, support there is essential and Deno just doesn't have it. Lack of backward compatibility with other libraries means an uphill struggle, likely resulting in a lot of ported and unmaintained packages. I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. For all these reasons, I regard Deno as dubious for now. I say all of this narrowly through my own experience and perception.

azangru 5y ago
> I sense that Deno is primarily being pushed by developers who cut their teeth in React-based code camps who are looking for (understandably) a wave to ride into "full stack" software development. This is a really strange take. Deno isn't significantly easier to work with than Node, so it shouldn't matter much for a React code camp graduate which of those two to ride into full stack. Deno is more appealing to seasoned web developers, who appreciate its conformity to modern web standards, the absence of Node quirks, and a better security. Example: discussion of Deno by two Google developer relations engineers: https://www.youtube.com/watch?v=SYkzk_j3yb0 https://www.youtube.com/watch?v=SYkzk_j3yb0
- k__ 5y ago
  "This is a really strange take." No, this is the gatekeeping mentality of many people software development. It's also wrong, since Deno removes many idiosyncrasies about server-side JavaScript.
  - beaker52 5y ago

nllsh 5y ago

I haven't done an existing project yet, but based on some experiments it seems like I'd mostly be deleting configuration files and making an import map. A simple SPA is crazy easy in deno: https://github.com/baetheus/deno-spa-example/ https://github.com/baetheus/deno-spa-example/

inglor 5y ago

I've switched a few projects back and forth but I am on the more experienced side (I'm comfortable with both codebases and have 2 digit commit numbers in both projects). My motivation for Node was that Deno's instrumentation/APM story doesn't exist which is a show stopper for many production apps and a lot of stuff was missing. My motivation for Deno was trying out deploy (their edge computing offering) which is really cool.