DEV Community

Discussion on: What is Deno.js and why should you care?

Collapse
 
gregfletcher profile image
Greg Fletcher

Great question.

It does follow the standard of using URLs for pulling in packages that GoLang employs and what the Web is built upon. The versioning can be solved by deps.ts file which Deno is currently using also. Deno is following in the footsteps of other projects and learning from them to create a (hopefully) better third-party package system.

I understand the concern that you might have, it's understandable. The good news is that the Deno project is very deliberately going in this direction. So a lot of thought has gone into it.

I highly recommend watching Ryan Dahl's talk announcing Deno. He talks about his reasons and you learn a lot about Node.js along the way. Definitely worth a watch. You can see it here

Collapse
 
ribizlim profile image
Mark Magyarodi

I'm still curious (and doubtful):

  • how the download of 100s of *.ts files is optimized (HTTP request overhead, HTTP/2 is a solution here? or bundling?)
  • how semver works (e.g. to use common version for the different versions of the same module): does cache support semver?
  • what about gzipped packages, will it be possible in the future? or bundling is the idea? So indirect deps are included multiple times in different modules?
  • what if a module is hosted from different sources, but it is the same. this is common practice with browser JS CDN hosting (jsdelivr, cdnjs, unpkg). if deno.land/x is the answer isn't it centralized like npm?

This discussion mostly covers all my concerns: github.com/denoland/deno/issues/47