Full-time freelancer; CTO Inertialbox -- Over 10 years in software engineering; Background in Robotics; Rails/Node JS & DevOps/SaaS/PaaS Architect; open for consulting and freelance opportunities.
Education
EEE & MSc (Dist) Mechatronics King's College London, UK
It sounds like deno is going to be npm incompatible (just by its name!); not sure if yarn would support it. So my larger question, what would be the options for deno in terms of:
Managing package dependencies
Managing the version of deno installed (on your dev system)
deno & webpack, how would this work?
I also hope folks picked up on the fact that deno is node switched around 😏
I think that we won't need some dependencies management basing in the fact that they are defined at the import statements using urls, which serves to identify them.
As deno has a bundler out of the box the intention should be that developers use this bundler and not third party options (Webpack, Parcel, Rollup), the same principle can by applied for testing , linting and formatting
Good question about different versions in the system, but the platform is shipped as a single executable so isn't hard build some tool like nvm
I am pretty much in agreement with Ben Awad's opinion in his video. Technically Deno is pretty cool, and I like TypeScript and Rust, but unless Deno has a blessed dependency management strategy and a good compatibility story with Nodejs and npm, I don't see it growing out of the niche easily.
Unfortunately, Deno is born out of Ryan Dahl's regrets about Nodejs, which means it would be hard for him to accept the same perceived warts back in.
EDIT: Or, if some huge communities decide to migrate to Deno entirely such as Angular, React or Vue, then that would boost Deno right out of niche too.
I saw the video and I also agree with him , mainly the fact about the incompatibility between existing libraries and the new deno apis, it seem that this can be a issue in which the community will play a huge roll
If this picks up pace, then, it will really be - one language for everything. With Node.js, you always had Node.js specific things (like their callback style for async actions, require(), exports etc.).
Promises for async methods - the best difference IMO.
It's great for software itself; it's moving the ecosystem forward with new ideas. I like that.
Now, if this picks up, it'll certainly take 3 or 4 years for serious adoption - no company will be willing to switch their entire engineering to a whole new platform.
"node" was brilliant from a marketing standpoint, I'm not so sure about "deno". I get it, deno is the letters in node rearranged. deno sounds friendly to me. When you have to convince devops to uptake a tool, "deno" sounds like a toy compared to "node" which sounds like it just belongs.
You'd be surprised how much naming really matters.
FWIW I like deno a lot. I appreciate some of the problems it solves and with Microsoft acquiring npm I want to move on. I honestly hope deno is the future.
i have few questions. 1) It doesn't have a centralized package management like package.json. Q) Imagine you have two developers who install whatever they wish to get the work done. Does one need to check all those files to get the list of what dependencies are installed?
2)Secure by default. No file, network, or environment access, unless explicitly enabled.
Q) Is this a big thing? then do other languages have this feature by default? can't we manage by using user groups in unix based systems?
3)Supports TypeScript out of the box. Q) can add type script support if i need whats the big deal?
4)Ships only a single executable file. Q) i use linux and never had any problems like this can anyone explain why this is a big usp
5)Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt). Q) npm, eslint and prettier => node + some scripts?
6)Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std Q) does this mean all those tons of code on github which work with node are dead?
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
This mean that unlike Node when you we run our applications they by default don't have access to the file system, network or enviroment, for that we need enable them using some flags as command line options to allow access for example deno --allow-read=/etc
Explicit permissions.
Deno always dies on uncaught errors.
Less silly name
I have to admit, if the above pan out, there's a good chance I might hate it less than I hate Node.js/Node.JS/Node/NodeJS/justStopALready.
Dependency by url is nice because there doesn't need to be a central repository, but it feels pretty cumbersome to use. URLs are long and hard to remember.
It gets worse if you want to use one dependency in multiple files. You have to copy the url across and upgrading a dependency means searching your entire code base for imports. This is worse than npm, imo
In order to avoid this issue they defined imports maps you can check this video for a more detailed explanation , also the official repo has information about this topic.
A Front-End Developer with a passion for learning how people work, the efficacy of good design, and a growing interest in the complexities of functional programming.
I'm pretty excited by the premise
It sounds like deno is going to be
npmincompatible (just by its name!); not sure if yarn would support it. So my larger question, what would be the options for deno in terms of:I also hope folks picked up on the fact that
denoisnodeswitched around 😏Thanks!
I think that we won't need some dependencies management basing in the fact that they are defined at the
importstatements using urls, which serves to identify them.As deno has a bundler out of the box the intention should be that developers use this bundler and not third party options (Webpack, Parcel, Rollup), the same principle can by applied for testing , linting and formatting
Good question about different versions in the system, but the platform is shipped as a single executable so isn't hard build some tool like nvm
Thanks for your comment
Well, if you want to see a resource for ES6 import-compatible libraries (compatible with Deno), Pika looks like the best option right now.
I would like to see example nestJS app on deno 🦄
Me too
This is exciting
I am pretty much in agreement with Ben Awad's opinion in his video. Technically Deno is pretty cool, and I like TypeScript and Rust, but unless Deno has a blessed dependency management strategy and a good compatibility story with Nodejs and npm, I don't see it growing out of the niche easily.
Unfortunately, Deno is born out of Ryan Dahl's regrets about Nodejs, which means it would be hard for him to accept the same perceived warts back in.
EDIT: Or, if some huge communities decide to migrate to Deno entirely such as Angular, React or Vue, then that would boost Deno right out of niche too.
I saw the video and I also agree with him , mainly the fact about the incompatibility between existing libraries and the new deno apis, it seem that this can be a issue in which the community will play a huge roll
If this picks up pace, then, it will really be - one language for everything. With Node.js, you always had Node.js specific things (like their callback style for async actions, require(), exports etc.).
Promises for async methods - the best difference IMO.
It's great for software itself; it's moving the ecosystem forward with new ideas. I like that.
Now, if this picks up, it'll certainly take 3 or 4 years for serious adoption - no company will be willing to switch their entire engineering to a whole new platform.
"node" was brilliant from a marketing standpoint, I'm not so sure about "deno". I get it, deno is the letters in node rearranged. deno sounds friendly to me. When you have to convince devops to uptake a tool, "deno" sounds like a toy compared to "node" which sounds like it just belongs.
You'd be surprised how much naming really matters.
FWIW I like deno a lot. I appreciate some of the problems it solves and with Microsoft acquiring npm I want to move on. I honestly hope deno is the future.
i have few questions.
1) It doesn't have a centralized package management like package.json.
Q) Imagine you have two developers who install whatever they wish to get the work done. Does one need to check all those files to get the list of what dependencies are installed?
2)Secure by default. No file, network, or environment access, unless explicitly enabled.
Q) Is this a big thing? then do other languages have this feature by default? can't we manage by using user groups in unix based systems?
3)Supports TypeScript out of the box.
Q) can add type script support if i need whats the big deal?
4)Ships only a single executable file.
Q) i use linux and never had any problems like this can anyone explain why this is a big usp
5)Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).
Q) npm, eslint and prettier => node + some scripts?
6)Has a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std
Q) does this mean all those tons of code on github which work with node are dead?
I really like to think Deno will become the next big thing in the JS ecosystem....
I have to admit, if the above pan out, there's a good chance I might hate it less than I hate Node.js/Node.JS/Node/NodeJS/justStopALready.
Dependency by url is nice because there doesn't need to be a central repository, but it feels pretty cumbersome to use. URLs are long and hard to remember.
It gets worse if you want to use one dependency in multiple files. You have to copy the url across and upgrading a dependency means searching your entire code base for imports. This is worse than npm, imo
In order to avoid this issue they defined imports maps you can check this video for a more detailed explanation , also the official repo has information about this topic.
Great Post! I'm really excited for this project .
lol very funny your comment
Looks interesting! I have a question (Haven't read manuals yet), are Deno executables compiled? Or they are like zipped packages?
It was implemented in Rust, so it should be compiled
There's still frameworks…
Deno must have a large community to really grow up. but I very excited about its feature.