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

321–330 of 446 posts

Re: The Deno Company

#321

Post by jedahan »

jacobwg wrote: post #236
jedahan wrote: post #189

Trying to signup for Deno Deploy, it asks for the 'Act on your behalf' github permission to make an account. Clicking on 'Learn more about Deno Deploy' leads to https://github.com/apps/deno-deploy , which does not tell me more. What does 'act on your behalf' mean for Deno Deploy?

I believe it's a very poorly written description in the newer GitHub App permission system. My understanding it describes something akin to "can act on your behalf, but only in the scope of what other permissions are being requested" but it's overall very unclear wording. See https://news.ycombinator.com/item?id=26485844

Deno's response here seems to confirm that https://github.com/denoland/deploy_examples/issues/15

Re: The Deno Company

#322

Post by justicezyx »

This is a great news!

Ryan and the team should be capturing some of the value produced by their creation. And because of Deno's a developer tool, it's actually capturing the far minor part of the whole value and enable a much bigger value creation!

Re: The Deno Company

#323

Post by xixixao »

> The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.

I know this might be hard to see, but Rust is actually in the same domain. It is also, among other things, enabling product/frontend/web engineers to build backend/native/browser-less applications.

I'd bet Rust will be more successful here, especially given its amazing ability to change itself and innovate.

Re: The Deno Company

#324

Post by WorldMaker »

nawgz wrote: post #282
sod wrote: post #251

Earlier quoted context omitted.

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 su…

Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? Also, from your link: "In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:" I d…

> Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package?

npm install copies in to your node_modules an entire zip/tarball package. Deno uses ES2015+ module syntax and it's only going to grab the JS files that are imported (or imported by imports). So it "naturally" tree shakes at the file level, and doesn't have a concept of a "package" in the same way. It's not directly going to tree shake inside of single file boundaries in the way that a major bundler/packager might (though the V8 JIT should still sort of indirectly compensate).

So yeah, if the package is published as just a single (M)JS file it will still get entirely downloaded by Deno, but if the modules are split across multiple files, Deno will only download the ones that are directly or indirectly imported (and will have no idea of the remainder of the files in the "package").

> I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production.

> Is it possible to do this in deno today? I don't really get that sense.

Yes, because URLs are just URLs, you could always have a Proxy service running at a URL that knows how to request the packages from upstream. https://jsproxy.mydomain.example.com/lodash/v1.1/module.js could be simple caching proxy that knows how to get lodash from upstream if it doesn't have the requested version cached (or sends a 404 error if it isn't allowed to cache a specific version or whatever).

Re: The Deno Company

#325

Post by dmux »

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. -…

First class in all but its REPL.

Re: The Deno Company

#326

Post by sneak »

paxys wrote: post #298
srmarm wrote: post #64

Earlier quoted context omitted.

Looks like https://deno.com/deploy will be a managed service - the implication seems to be that the default option will be to use their CDN to run code with an option to DIY if you prefer.

I'll be very surprised if "quick and easy hosting" is still a viable business model, considering how crowded the space is by now.

Quick, easy, and cheap hosting will always be a viable model, for varying definitions of cheap.

Re: The Deno Company

#327

Post by sneak »

forty wrote: post #308
wperron wrote: post #286

Earlier quoted context omitted.

Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exactly TypeScript) We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.

Exactly. And I guess the package still needs to be compiled to JS before deploying to production? To avoid shipping a full TS compiler on a production server which would be a crazy thing to do.

I don't think that would be that crazy, especially if it's in the stdlib.

Re: The Deno Company

#328

Post by Kranar »

nawgz wrote: post #282
sod wrote: post #251

Earlier quoted context omitted.

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 su…

Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? Also, from your link: "In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:" I d…

>"deno download exactly the code that is imported" and not just a whole package?

In a fairly simple and elegant manner. You specify a URL to the specific file FOO you want to import and FOO gets downloaded. Then deno looks at FOO to see what files FOO depends on, and downloads those, so on so forth...

That's very different from how NPM works where you have to download the entire package, including parts you may never use, along with every dependency the package depends on, even if you never end up using those dependencies either.

NPM's approach, which frankly worked well given the circumstances, has the downside of not providing end-users much benefit of writing code in a modular fashion, so there's no advantage to breaking a package up into multiple files versus distributing a single and large minified file.

Deno's approach promotes breaking up packages into multiple files so that an end-user only downloads the files and dependencies that are actually needed.

Re: The Deno Company

#329

Post by qbasic_forever »

srmarm wrote: post #64
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…

Looks like https://deno.com/deploy will be a managed service - the implication seems to be that the default option will be to use their CDN to run code with an option to DIY if you prefer.

How does this business model survive Amazon AWS making a blog post, "Here's a template to run your deno code on Lambda!"? They'll never beat AWS on costs in the long term. They can burn VC cash to stay afloat and try I guess.

Re: The Deno Company

#330

Post by qbasic_forever »

not_knuth wrote: post #21

If I understood correctly this is how they intend to make money: > Not every use-case of server-side JavaScript needs to access the file system; our infrastructure makes it possible to compile out unnecessary bindings. This allows us to create custom runtimes for different applications: Electron-style GUIs, Cloudflare Worker-style Serverless Functions, embedded scripting for databases, etc. So it's basically more of…

That's a description of a command line flag or feature of the runtime, not a business model.
Post reply on HN