5 ms·

Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that w

Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling. If Deno was where it is today but like 8 years ago, it would have made a splash. Now it just looks like someone made a few creature comforts to Node.

ericlewis 6y ago
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)
hn_throwaway_99 6y ago
Thanks, I agree 100%. Perhaps I'm getting unnecessarily cocky in my old age, but this really does feel like other cases I've seen in the past where people (including the original founder) want "a clean slate", because of course there are warts and lessons learned from the original implementation, but the cost of workarounds for those warts is actually lower than the cost of switching to an entirely new competing technology for most people. Going back to the original list: - Typescript as a first class citizen: Agreed, it's not hard to get TS set up in Node, and it's a "one and done" cost. - An actual `window` global with familiar browser APIs: I've never needed or wanted this, though I could see how the server-side rendering crowd could benefit, but I still have to believe there would by necessity be enough difference between the browser-based window that implementing SSR is still non-trivial. - Sandboxing w/ permissions: I honestly think this is going to be useless. As you stated, if you're really running untrusted code better to rely on process permissions. This actually reminds me of many of the overly complicated security/permissions architecture in the Java SecurityManager stuff that I rarely if ever actually saw being used. - URL-based imports (no need for NPM): NPM certainly has its warts, but I think a lot of Deno supporters woefully underestimate how most server-side JS developers love having a single primary global package repo. - Bundling into self-contained binaries: Again, this is nice, but also gets a "Meh, I don't really care" from me. - Things like top-level-await which Node.js still treats as experimental: Once you learn how to do an IIFE who really cares? - Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks): Again, a minor nice-to-have, especially with Util.promisify.

ericlewis 6y ago

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)

hn_throwaway_99 6y ago

Thanks, I agree 100%. Perhaps I'm getting unnecessarily cocky in my old age, but this really does feel like other cases I've seen in the past where people (including the original founder) want "a clean slate", because of course there are warts and lessons learned from the original implementation, but the cost of workarounds for those warts is actually lower than the cost of switching to an entirely new competing technology for most people. Going back to the original list: - Typescript as a first class citizen: Agreed, it's not hard to get TS set up in Node, and it's a "one and done" cost. - An actual `window` global with familiar browser APIs: I've never needed or wanted this, though I could see how the server-side rendering crowd could benefit, but I still have to believe there would by necessity be enough difference between the browser-based window that implementing SSR is still non-trivial. - Sandboxing w/ permissions: I honestly think this is going to be useless. As you stated, if you're really running untrusted code better to rely on process permissions. This actually reminds me of many of the overly complicated security/permissions architecture in the Java SecurityManager stuff that I rarely if ever actually saw being used. - URL-based imports (no need for NPM): NPM certainly has its warts, but I think a lot of Deno supporters woefully underestimate how most server-side JS developers love having a single primary global package repo. - Bundling into self-contained binaries: Again, this is nice, but also gets a "Meh, I don't really care" from me. - Things like top-level-await which Node.js still treats as experimental: Once you learn how to do an IIFE who really cares? - Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks): Again, a minor nice-to-have, especially with Util.promisify.