Hey there! In this article, I'm sharing my thoughts about Deno as a bad runtime system for enterprise applications. At least for now. Note, if you have some useful information on this topic, please put it in the comments, I will be appreciated. Package manager The main issue of the Deno package manager that it's terrible for use with the CI/CD. I mean, if you need your CI/CD process to be fast, all the packages must be loaded manually to your app Git (otherwise, developers and testers will need to wait until everything is loaded from the web for each CI/CD launch - it's just a waste of the development time and budget). If you choose the Git option, then your developers will need to do all the upgrades manually as in the previous century (or use Node.js with the NPM instead). { connect } ; * base64 ; { createLogger } ;
... import from "https://deno.land/x/amqp/mod.ts" import as from "https://denopkg.com/chiefbiiko/base64/mod.ts" import from "https://denolib.com/yamboy1/deno-structured-logging/mod.ts" Also, I don't like the idea that there is no one file with all indicated packages. This will create a mess in big enterprise apps. Just imagine that 20+ developers import packages without any systematic approach. And there are no versions at all (only in some URLs or in manually created file with dependencies, which is not strictly default). It's not right from my point of view. Packages I expected Deno to have all the Express features so it can be used without any framework. Instead of this, we have that oak framework ('oak' is its name): . And for logging purposes, we need to import one more package: . And for other simple development features - more and more packages: . It's rather strange that Deno can't have almost all these features integrated by default ('out of the box') since its using area is pretty clear. At least for the most basic features like routing, logging, and debugging. https://deno.land/x/oak https://deno.land/x/deno_structured_logging https://deno.land/x/ Security policies Deno's security policies look okay only for relatively small applications. Large enterprise applications will need a lot of permissions, so, from my point of view, the policies must be indicated for each package. That's why the one root file or generator (for the monolith app, services, etc.) with packages is needed. With the current approach, one permission for the entire app is not effective if one package was infected and the permission was provided for another package on the app level (the infected package will have the permission then). deno run  --allow-net .\main.ts
# it allows running the server via the net
# basically, there is one permission the whole app right now for Preliminary сonclusions From what I see right now, Deno is a bad choice for enterprise applications. At least when we have Node.js with all its developed features. N.B. I'd like to change my opinion, so, as I wrote in the Introduction section, please share your thoughts in the comments. Thank you for your attention.

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Everything Wrong About Deno as a Runtime System for Enterprise Applications

Too Long; Didn't Read

onederman

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Everything Wrong About Deno as a Runtime System for Enterprise Applications

Too Long; Didn't Read

onederman

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES