2021-01-14
2493
#deno#node
Maciej Cieślar
3546
Jan 14, 2021 ⋅ 8 min read

What is Deno, and how is it different from Node.js?

Maciej Cieślar A JavaScript developer and a blogger at mcieslar.com.

Recent posts:

When is low-code the right choice? Here’s how to decide

Not sure if low-code is right for your next project? This guide breaks down when to use it, when to avoid it, and how to make the right call.

Popoola Temitope
Jul 11, 2025 ⋅ 7 min read
Comparing AI App Builders — Firebase Studio vs. Lovable vs. Replit. LogRocket Article

Comparing AI app builders — Firebase Studio vs. Lovable vs. Replit

Compare Firebase Studio, Lovable, and Replit for AI-powered app building. Find the best tool for your project needs.

Emmanuel John
Jul 11, 2025 ⋅ 7 min read
Gemini CLI tutorial — Will it replace Windsurf and Cursor?

Gemini CLI tutorial — Will it replace Windsurf and Cursor?

Discover how to use Gemini CLI, Google’s new open-source AI agent that brings Gemini directly to your terminal.

Chizaram Ken
Jul 10, 2025 ⋅ 8 min read
React & TypeScript: 10 Patterns For Writing Better Code

React & TypeScript: 10 patterns for writing better code

This article explores several proven patterns for writing safer, cleaner, and more readable code in React and TypeScript.

Peter Aideloje
Jul 10, 2025 ⋅ 11 min read
View all posts

13 Replies to "What is Deno, and how is it different from Node.js?"

  1. Yes would it be possible to get a citation for the Deno team recommending storing the cache in the project directory?

  2. @alastair
    “Relying on external servers is convenient for development but brittle in production. Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime.”

  3. @Maciej thanks for the reply; I more meant a link to wherever the Deno team recommended storing the cache in the project directory *over* the system’s default cache directory.

    Great article on the whole btw, really interesting stuff.

  4. This is very surprising, it’s like asking to check-in node_modules to avoid dependency issues. Which actually would avoid a ton of issues but it makes the git repository huge and hard to use.

    There are typically tens of thousands of files in node_modules, that’s why we avoid to commit this folder. I wonder how this will work in practice, I actually wouldn’t mind taking longer to clone a repo if it ensures that no-one will run into versioning issues in the project, due to different machines having installed different versions of some library.

  5. I don’t understand these complaints. How is bundling dependencies and cloning them later any different than doing an `npm install`? You have to download these files one way or another…

  6. I guess the difference will be that in npm you are downloading a lot of garbage with every package like readme files etc. In deno on the other hand you will be caching nothing more than minified javascript.

  7. We don’t like package.json, that’s why we are using map JSON file …., We don’t like node_modules, that’s why we are using folder with a different name and store packages in our own repo …,

  8. because module is code, it’s normal to push all the code to the repo and not rely on third party tools to do it for you each time on the client

  9. I just wonder if allowing ‘anyone’ to publish from their own site, code that I’m going to use, is defeating the contention that Deno is improving security. I don’t know what npm does to ensure the code they host is not destructive or poorly written, but the downloading from npm site for me seems to provide a better way to do some type of inspection and validating of the code for the developer. If npm does nothing, then at least you can look at the popularity of the npm packages based on downloads. If anyone can publish from their own site, how can we even know the popularity of that code – who will track that?

Leave a Reply