2021-01-14
1869
#deno#node
Maciej Cieślar
3546
Jan 14, 2021 ⋅ 6 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:

Error Handling In Rust A Comprehensive Guide

Error handling in Rust: A comprehensive tutorial

Learn to handle Rust errors efficiently to write cleaner, more maintainable Rust code and create a more user-friendly application.

Eze Sunday
Jul 18, 2024 ⋅ 10 min read
Exploring Actions And Request Rewriting In Astro

Exploring actions and request rewriting in Astro

Astro v4.8 ships with server actions and request rewriting. Let’s see how to use these long-awaited (though still experimental) features.

Ivaylo Gerchev
Jul 17, 2024 ⋅ 13 min read
Comparing Fiber Vs Gin For Go Web Development

Comparing Fiber vs. Gin for Go web development

Go Fiber and Gin are two popular Go frameworks that provide extensive toolkits for developing high-performance apps with modern features.

Temitope Oyedele
Jul 17, 2024 ⋅ 8 min read
Leveraging Typescript Branded Types For Stronger Type Checks

Leveraging TypeScript branded types for stronger type checks

Branded types in TypeScript allow us to write code more clearly, provide more type-safe solutions, and maintain our code more efficiently.

Rashedul Alam
Jul 16, 2024 ⋅ 5 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