7 ms·

This may be inviting downvotes, but I still don't understand the use-case of Deno. Why would I use this over something like Python? In Python, I find I can do

This may be inviting downvotes, but I still don't understand the use-case of Deno. Why would I use this over something like Python? In Python, I find I can do most things I want with the standard library plus a handful of well-known packages, so even just downloading the tarballs and installing manually isn't all that onerous. Why do I want a "browser for code"? I may just be out-of-touch, as a purely backend/machine-learning/quality engineer. Clearly, this is a real need in the front-end / JavaScript space, but coming from the outside I just don't quite understand yet the value proposition here. Can anyone explain?

root_axis 6y ago
if you have everything you need in python then you're not really the target audience. deno is an answer to the current state of the npm ecosystem. Not that you shouldn't switch to deno from python, but you should only do that if you already had a reason why you wanted to switch to node from python.
paxys 6y ago
Your question really is "why use server-side JS over Python" and that doesn't have a real answer, just never-ending arguments.
- mst 6y ago
  Let's paint it blue!
shriek 6y ago
> Clearly, this is a real need in the front-end / JavaScript space I think you answered your own question there. If you already know JS/TS and want to dive into server code then this is more approachable than learning a brand new language.
ordinaryradical 6y ago
>Why would I use this over something like Python? That's more a js vs python question than a Deno question so I don't think you'll find many answers here as we'd veer off-topic. >I find I can do most things I want with the standard library A standard library exists for Deno as well. Code from any URL is not an argument against having a standard library. The distinction being made is whether or not package management should be brittle and baked into the programming model to accept only one source of truth vs. any. Any source of truth has the advantage of letting better solutions evolve and reveal themselves over time, which is great for longevity, standards, etc. etc. > Why do I want a "browser for code"? My understanding is that this a lot to do with reproducing how front-end code behave "in the wild." If you have a full browser, you aren't tricking your programming model into thinking it's being run in a browser. I think this has tooling advantages in the short term (i.e. simplicity) and more subtle ones in the long term.
- oddthink 6y ago
  Thanks. My question really wasn't focused well, and it was easily read not as "please help me understand" but as "hurr durr Python is better". I think my reaction comes from the dissonance between people saying "Deno is the best thing ever for CLI apps!" then following up with "Here are the ways it's better than Node!", without acknowledging all the other scripting languages out there. But I think I need to read that first line as having an implicit "...in the JS/TS ecosystem", and then it all makes sense. Since clearly one of Deno's draws is that it improves on the package management of Node, I was wondering why JS projects so often end up with such a long list of dependencies, compared to the Python/Go/C++ projects that I'm more familiar with. That's probably explained just by NPM making it easy, so people did it. (Sort of like how Java grew convoluted DI schemes because OO + GC + reflection made it possible.) One of these days I should learn more JS than having read through the Good Parts once. :-)

root_axis 6y ago

if you have everything you need in python then you're not really the target audience. deno is an answer to the current state of the npm ecosystem. Not that you shouldn't switch to deno from python, but you should only do that if you already had a reason why you wanted to switch to node from python.

paxys 6y ago

Your question really is "why use server-side JS over Python" and that doesn't have a real answer, just never-ending arguments.

mst 6y ago
Let's paint it blue!

shriek 6y ago

> Clearly, this is a real need in the front-end / JavaScript space I think you answered your own question there. If you already know JS/TS and want to dive into server code then this is more approachable than learning a brand new language.

ordinaryradical 6y ago

>Why would I use this over something like Python? That's more a js vs python question than a Deno question so I don't think you'll find many answers here as we'd veer off-topic. >I find I can do most things I want with the standard library A standard library exists for Deno as well. Code from any URL is not an argument against having a standard library. The distinction being made is whether or not package management should be brittle and baked into the programming model to accept only one source of truth vs. any. Any source of truth has the advantage of letting better solutions evolve and reveal themselves over time, which is great for longevity, standards, etc. etc. > Why do I want a "browser for code"? My understanding is that this a lot to do with reproducing how front-end code behave "in the wild." If you have a full browser, you aren't tricking your programming model into thinking it's being run in a browser. I think this has tooling advantages in the short term (i.e. simplicity) and more subtle ones in the long term.

oddthink 6y ago
Thanks. My question really wasn't focused well, and it was easily read not as "please help me understand" but as "hurr durr Python is better". I think my reaction comes from the dissonance between people saying "Deno is the best thing ever for CLI apps!" then following up with "Here are the ways it's better than Node!", without acknowledging all the other scripting languages out there. But I think I need to read that first line as having an implicit "...in the JS/TS ecosystem", and then it all makes sense. Since clearly one of Deno's draws is that it improves on the package management of Node, I was wondering why JS projects so often end up with such a long list of dependencies, compared to the Python/Go/C++ projects that I'm more familiar with. That's probably explained just by NPM making it easy, so people did it. (Sort of like how Java grew convoluted DI schemes because OO + GC + reflection made it possible.) One of these days I should learn more JS than having read through the Good Parts once. :-)