Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.9

deno.com

Post reply on HN
Print view View original

231–240 of 245 posts

Re: Deno 1.9

#231

Post by nikisweeting »

riho wrote: post #212
zkldi wrote: post #88

I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…

This is probably one of the bigger issues holding me back from adopting Deno (at least for personal projects anyway). I'm sorry, I don't want to go back to early 2000s where we're copy pasting random links to script tags. Those days are over and for the better. NPM has proved pretty much undeniably that people prefer the simplicity of just typing in the name of something to install it, and import it. Does it have iss…

This 100%. Every time it comes up I'm just saddened by the fact that they're so antagonistic towards the existing npm ecosystem, when those problems could be so easily solved and their userbase so easily expanded with some minor compatibility tooling that allows importing npm packages.

Re: Deno 1.9

#232

Post by nikisweeting »

tlrobinson wrote: post #163
Osiris wrote: post #159

Earlier quoted context omitted.

If dependencies are imports from URLs, how does one audit their dependencies? If a server gets hacked those TS can be replaced with malicious versions. In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time tho…

Integrity checking & lock files https://deno.land/manual@v1.9.0/linking_to_external_code/int... The same problem (and solution: package-lock.json or yarn.lock) exists in npm if you use semver version specifiers, or npm itself could be hacked, it’s just a bit more acute in Deno since it’s easy and common to load files from arbitrary hosts that don’t enforce immutable versions.

npm has a lot more to lose from being hacked than some random URL, I trust npm with my packages because they fix stuff when something like left-pad happens, the same is not true for every URL I'd have to import to build a deno package.

Re: Deno 1.9

#233

Post by nikisweeting »

zomglings wrote: post #106

I'm curious, if anyone has lived through the experience: What is the migration story like to port an existing codebase from node.js to Deno?

Very painful due to the lack of support for importing npm packages.

Re: Deno 1.9

#234

Post by goldenkey »

agnoster wrote: post #229
goldenkey wrote: post #209

Earlier quoted context omitted.

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style. Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857 Just take a look at a random stdlib source f…

Always snopes before you post! https://www.snopes.com/fact-check/patrisse-cullors-topanga-h... The "mansion" is a 3br 2ba, real estate is just kind of expensive in LA. My Bay Area home is actually worth more than that, and I don't see why she shouldn't be allowed to make real estate investments or have a nice-ish house. There's no evidence any funds have been misappropriated, and if it comes to light I'll join you in…

Snopes is a great source! /s https://www.dailymail.co.uk/news/article-4730092/Snopes-brin...

https://www.boston25news.com/news/trending-now/snopescom-cof...

https://en.wikipedia.org/wiki/Snopes

"Kids, say no to Snopes!"

Re: Deno 1.9

#235

Post by folkrav »

tengbretson wrote: post #210
folkrav wrote: post #148

Earlier quoted context omitted.

> enums [...] everybody but me hates them Hmm, what did I miss, why do people hate them exactly? > And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain. Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critica…

> Hmm, what did I miss, why do people hate them exactly? They operate in a weird gray-zone between being just compile-time types vs. an actual readonly object in the runtime. I don't think I've seen a use case for them yet that wouldn't have been better accomplished with a union type of string literals and using const string literals in the code.

Say all you need is a fixed set of strings that get reused everywhere. What is better accomplished by defining a union type AND consts literals rather vs creating a single string-based enum and using that everywhere? I feel like I'm misunderstanding...

Re: Deno 1.9

#236

Post by searchableguy »

nikisweeting wrote: post #233
zomglings wrote: post #106

I'm curious, if anyone has lived through the experience: What is the migration story like to port an existing codebase from node.js to Deno?

Very painful due to the lack of support for importing npm packages.

You can import npm packages using esm and skypack.

import React from "https://esm.sh/react@17.0.2" should work.

For skypack, add ?dts flag at the end to get typescript typing support automatically.

Self hosting is an option too with above.

if you want more npm modules to work with deno, you can contribute to https://deno.land/std/node

Re: Deno 1.9

#237

Post by nikisweeting »

searchableguy wrote: post #236
nikisweeting wrote: post #233

Earlier quoted context omitted.

Very painful due to the lack of support for importing npm packages.

You can import npm packages using esm and skypack. import React from " https://esm.sh/react@17.0.2 " should work. For skypack, add ?dts flag at the end to get typescript typing support automatically. Self hosting is an option too with above. if you want more npm modules to work with deno, you can contribute to https://deno.land/std/node

This is good, but even with integrity hashes it makes me slightly uncomfortable to have a (relatively unknown) SaaS company stand between the original source on npm and us.

Self-hosting seems good, but how does one do that? I didn't see any docs on Skypack's site about self-hosting something that would work as a npm-to-deno-repackaging server.

Re: Deno 1.9

#238

Post by searchableguy »

nikisweeting wrote: post #237
searchableguy wrote: post #236

Earlier quoted context omitted.

You can import npm packages using esm and skypack. import React from " https://esm.sh/react@17.0.2 " should work. For skypack, add ?dts flag at the end to get typescript typing support automatically. Self hosting is an option too with above. if you want more npm modules to work with deno, you can contribute to https://deno.land/std/node

This is good, but even with integrity hashes it makes me slightly uncomfortable to have a (relatively unknown) SaaS company stand between the original source on npm and us. Self-hosting seems good, but how does one do that? I didn't see any docs on Skypack's site about self-hosting something that would work as a npm-to-deno-repackaging server.

Sorry, I was talking about esm.sh

https://github.com/postui/esm.sh

This is written in golang and can be self hosted.

> This is good, but even with integrity hashes it makes me slightly uncomfortable to have a (relatively unknown) SaaS company stand between the original source on npm and us.

I understand the worries but npm is a private SAAS company which was unknown at the time of node too. Things take time to sort out and become stable.

Unlike node, where npm defaults to npmjs - a private company which can go anytime. Deno doesn't make that choice for users. I believe that is the right step.

Trust what you need to and have an allow list.

Re: Deno 1.9

#239

Post by fiiv »

kaba0 wrote: post #206
rsp1984 wrote: post #39

I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.

Similarly, how does both Node.js and Deno compare to GraalJS? I've been reading about it and find the idea absolutely genius, but I'm sure it doesn't have nearly as much of a userbase as these.

They're kind of different things. Graal is an attempt to create a polyglot environment. For example, using Python and Javascript in the same environment. For example you might be working on an application where the web server managed by the web team is written in Node and your data scientist team uses Python scripts to deal with the data, but they need to run in the same environment. Graal lets you re-use that environment for both.

Node and Deno are dedicated runtimes to run Javascript using the V8 engine. Both provide a standard library of additional functionality to make them worthwhile beyond just browser code.

Re: Deno 1.9

#240

Post by apatheticonion »

z3t4 wrote: post #185
apatheticonion wrote: post #141

Earlier quoted context omitted.

The issue is that JavaScript (by extension TypeScript) doesn't have the concept of folders. You can only import a single file per import statement. Developers create "barrel" files that allow them to re-export all of the important stuff in a folder externally. This allows for namespacing // foo/index.ts export * from './foobar' // main.ts import * as foo from './foo/index' new foo.Foobar() Or use destructured imports…

Gotcha in ES6 import is that you need to import the default export specifically eg. import default as Foo, * as Bar It would be much easier if it was one namespace like in Node.js require. eg. var Foo = await requires("foo", {fs: "/home/user"}) Node.js modules are pretty much perfect besides the security flaws.

Yeah I am sad that ES6 imports don't allow for easy namespacing.

You can get around this with a double barrel. In the outer barrel, export your individual things

   // index.barrel.js
   export * from './foo.js'
Then in your main barrel re-export them under a namespace

   // index.js
   export * as foobar from './index.barrel.js'
Then from you application you are forced to have a named import with the namespace defined

   // main.js
   import { foobar } from './foobar/index.js'
   
   foobar.foo()
You can submit a proposal to introduce namespacing to ES6 imports
Post reply on HN