A javascript runtime that essentially restricts all access unless explicitly provided by the user. Also, it has typescript support out of the box. Also, it essentially decentralizes package sharing by using URLs for retrieving javascript codes (just like we do by using script tags in the browser).
It seems, and apparently is (based on Ryan Dahl's presentations), like a do-over of Node by learning from its mistake.
However, there are large code bases written in Node, and since Deno does not try to be compatible with node, it would be interesting to see how or if the transition will happen.
I wondered about that last point myself. No doubt there will be projects that can take advantage of Deno, but the Node ecosystem and market share are huge. It would take a long time for this kind of transition to happen.
Among other things, Deno is a great replacement for utility scripts that may have been historically written with bash or python.
The above is from the introduction page of Deno. So, maybe Node and Deno won't compete but co-exist. Deno seems, at the moment, focused to make CLI apps generation easier, or at least that is what I gather from the above quote.
Also, I realize you have to explicitly give Deno certain permissions at runtime, but I'm skeptical of the idea of using ES module imports with third-party URLs for server-side code. Maybe I just need to read up on that...
Yes, I think that will be addressed in some way as the platform matures. However, researching before using a third party package/URL is a must. So, we need to ensure that we only use those packages that we absolutely trust.
The other issues have been solved by the Deno team already. Mainly, importing the packages and exporting them; this ensures that we know the packages that we are using and that we use only single version of any library/package. Next, the Deno automatically caches code the first time we install dependencies, so our software won't break because of change in code from the URL. We could also version control our dependency if we want.
I like doing, helping people do, getting things done. founder. http://codewit.co . directorat http://loudspeakerdigital.com lead. http://bloopglobal.com , http://agriprohub.com , souledoutlive.
// , “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)
A javascript runtime that essentially restricts all access unless explicitly provided by the user. Also, it has typescript support out of the box. Also, it essentially decentralizes package sharing by using URLs for retrieving javascript codes (just like we do by using script tags in the browser).
It seems, and apparently is (based on Ryan Dahl's presentations), like a do-over of Node by learning from its mistake.
However, there are large code bases written in Node, and since Deno does not try to be compatible with node, it would be interesting to see how or if the transition will happen.
I wondered about that last point myself. No doubt there will be projects that can take advantage of Deno, but the Node ecosystem and market share are huge. It would take a long time for this kind of transition to happen.
The above is from the introduction page of Deno. So, maybe Node and Deno won't compete but co-exist. Deno seems, at the moment, focused to make CLI apps generation easier, or at least that is what I gather from the above quote.
That sounds interesting.
Also, I realize you have to explicitly give Deno certain permissions at runtime, but I'm skeptical of the idea of using ES module imports with third-party URLs for server-side code. Maybe I just need to read up on that...
Yes, I think that will be addressed in some way as the platform matures. However, researching before using a third party package/URL is a must. So, we need to ensure that we only use those packages that we absolutely trust.
The other issues have been solved by the Deno team already. Mainly, importing the packages and exporting them; this ensures that we know the packages that we are using and that we use only single version of any library/package. Next, the Deno automatically caches code the first time we install dependencies, so our software won't break because of change in code from the URL. We could also version control our dependency if we want.
Yeah. Interesting times. Can’t wait to see how it all plays out.
Chill.