4 ms·

top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.

hombre_fatal 6y ago
It's cute for scripts. Otherwise there's the trivial top-level wrapper runProgram.catch(console.error) entry point. It's just not a detail that does much to sell Deno. Though I admit it's not that fun for me to come in here to poopoo Deno.
- ericlewis 6y ago
  I am not trying to do that either - I think the work they're doing is great and important, but the reasons listed above ain't it.
ravenstine 6y ago
Care to share some examples of said edge cases? I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial. EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.
- ericlewis 6y ago
  I think deno is really interesting in the aspects of how it is parsed and handled, I have a lot of hope they can continue to do cool things with it too. I would like to continue seeing them take strong opinions on things that improve the language, and hope to see it evolve beyond javascript. But thus far - it has been: stealing code from node.js and taking strong opinions on things that make the overall DX worse. Deno's strength will being a scripting language on its current path. Edit: just realized I gave no example.. an example would be a dep that has gone missing and there is no backup for it. Deno sort of handles this but all we have actually added is no centralized way to describe dependence. So if you dynamically import a package via its package manager you also need to write some code to ensure it even exists. how is that better?
  - ravenstine 6y ago
    Can't we have archives in case any packages fail to resolve? Archive.org might even work in some circumstances. (not saying that we should use that, but that it would be trivial to have backups in a repository that we don't always rely on for all dependencies)

hombre_fatal 6y ago

It's cute for scripts. Otherwise there's the trivial top-level wrapper runProgram.catch(console.error) entry point. It's just not a detail that does much to sell Deno. Though I admit it's not that fun for me to come in here to poopoo Deno.

ericlewis 6y ago
I am not trying to do that either - I think the work they're doing is great and important, but the reasons listed above ain't it.

ravenstine 6y ago

Care to share some examples of said edge cases? I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial. EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.

ericlewis 6y ago
I think deno is really interesting in the aspects of how it is parsed and handled, I have a lot of hope they can continue to do cool things with it too. I would like to continue seeing them take strong opinions on things that improve the language, and hope to see it evolve beyond javascript. But thus far - it has been: stealing code from node.js and taking strong opinions on things that make the overall DX worse. Deno's strength will being a scripting language on its current path. Edit: just realized I gave no example.. an example would be a dep that has gone missing and there is no backup for it. Deno sort of handles this but all we have actually added is no centralized way to describe dependence. So if you dynamically import a package via its package manager you also need to write some code to ensure it even exists. how is that better?
- ravenstine 6y ago
  Can't we have archives in case any packages fail to resolve? Archive.org might even work in some circumstances. (not saying that we should use that, but that it would be trivial to have backups in a repository that we don't always rely on for all dependencies)