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

The Deno Company

deno.com

Post reply on HN
Print view View original

251–260 of 446 posts

Re: The Deno Company

#251

Post by sod »

ivan888 wrote: post #244
ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…

Answered in https://deno.land/manual@v1.8.2/linking_to_external_code#but...

Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.

Re: The Deno Company

#252

Post by ivan888 »

jansommer wrote: post #249
ivan888 wrote: post #244

Earlier quoted context omitted.

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…

"Deno can store and check subresource integrity for modules using a small JSON file." - https://deno.land/manual/linking_to_external_code/integrity_...

Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource

Re: The Deno Company

#253

Post by sbarre »

elisee wrote: post #183
sbarre wrote: post #34

Earlier quoted context omitted.

Peeking at sparks.land I see that you're serving .ts files, I assume that's what you mean by using sucrase, you're transpiling "live" instead of building/deploying bundles offline? I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?

Correct! In production we've got Cloudflare in the middle, so we're only using sucrase on-the-fly for each .ts file during development. So far it's unnoticeable in terms of loading times. > I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach? Not that I can tell. But if we need to, we can always do a minified bundle in production…

Wait, so you're running Sucrase in a Cloudflare Worker?

It compiles, and then caches the output I assume?

That's a really cool use case I hadn't thought of..

Re: The Deno Company

#254

Post by searchableguy »

samjmck wrote: post #196
elisee wrote: post #15

Happy to see Deno get some financial backing! I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use. The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip…

Is the VSCode support good? I tried using Deno with WebStorm a few months ago and it wasn't a great experience.

Jetbrains extension hasn't been updated much since release and doesn't interface with the official LSP. The experience is poor and outdated.

Vscode extension is maintained by the official team and will provide the best experience. There are unofficial plugins for sublime and Vim. They use LSP too and provide a comparable experience.

Re: The Deno Company

#255

Post by goodoldneon »

ivan888 wrote: post #244
ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…

URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code?

The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits

Re: The Deno Company

#256

Post by cdash »

celeritascelery wrote: post #179
oblio wrote: post #87

Earlier quoted context omitted.

> Or if it just exists because JavaScript developers don’t want to learn something new. It's probably a big reason. But if you think about it from the other angle... you don't want to learn Javascript, which would be new to you :-)

Touché. I will admit I am resistant to learning JS. Part of this is that it seems like no one actually "likes" to program in it, they just have to because it is so ubiquitous. But I guess that just goes back to the Bjarne Stroustrup quote: "There are two kinds of programming languages: The ones people complain about and the ones nobody uses."

For me, Typescript changed everything. I don't enjoy programming in plain old JS but I love Typescript.

Re: The Deno Company

#258

Post by luma »

franciscop wrote: post #42

Nice to see! How do they plan to monetize? I either became blind or missed it somehow. The article does say how they DON'T plan on monetize: "Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno." There are some hints though: "If you watch our conference…

I know this isn't the SV-approach to things but maybe they intend to offer consulting services for those looking for some expertise with the ecosystem, bill hours, and retire in their 50s as millionaires instead of billionaires.

This might be surprising, but not everyone is looking to be a unicorn.

Re: The Deno Company

#259

Post by searchableguy »

ivan888 wrote: post #252
jansommer wrote: post #249

Earlier quoted context omitted.

"Deno can store and check subresource integrity for modules using a small JSON file." - https://deno.land/manual/linking_to_external_code/integrity_...

Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource

> Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project

Could you expand on this? Any examples would be appreciated.

Re: The Deno Company

#260

Post by ivan888 »

searchableguy wrote: post #259
ivan888 wrote: post #252

Earlier quoted context omitted.

Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource

> Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.

Code examples abound on Stack Overflow, GitHub Gist, blog posts, etc. These may contain direct URL dependencies.

Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker

There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and incidents happen, but without a centralized authority for package management, there is much less assurance that a package is not malicious

Post reply on HN