undefined | Better HN

0 pointsmaga3y ago0 comments

Leo, your comments save me a lot of typing on threads like this, and since I recently wrote[1] what beeandapenguin wrote above almost to a point (sans security), I feel obliged to expand a bit.

You are right about incompatibility being a major issue; Deno recognizes that as well, hence, they are working on a compatibility mode that allows using Node specific libraries in Deno[2].

> migrating to Deno is, charitably, likely a monumental task that nobody would ever undertake, even considering the upsides.

This is, of course, contingent on the architecture used: for code tightly coupled to frameworks/runtimes it is indeed a monumental task. I have two small to mid size SaaS apps happily running on Node.js, but I'm looking forward to replacing it with Deno solely for the streamlined DX. The apps follow DDD architecture, thus, framework specific stuff is decoupled into a service/adapter and changing it is a day's work. The major technical road-block for now is indeed incompatibility of third-party libraries/SDKs written for Node.js (google sdk, mongdbo driver, etc.).

[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...

[2] https://github.com/denoland/deno/issues/12577

0 comments

lhorie3y ago

> The major technical road-block

Yeah, this is primarily what I'd expect would hold back migrations, both in actual technical terms (e.g. Deno-flavored libraries for some tasks may not exist at all) and buy-in from engineers. Don't get me wrong, I'd love to seriously consider Deno for our (very large) codebase (a 1000+ package monorepo with 400+ engineers committing), and I say this as someone who's successfully lead a number of massive migrations for this monorepo. But Node -> Deno at even 1/100 of this scale is, in my mind, potentially orders of magnitude more difficult than even a monorepo-wide Flow -> Typescript conversion, which is already fairly daunting migration.

j / k navigate · click thread line to collapse