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

241–250 of 446 posts

Re: The Deno Company

#241

Post by lucacasonato »

unityByFreedom wrote: post #222
davnicwil wrote: post #73

What I find most exciting here is: > Our infrastructure makes it possible to... create custom runtimes for different applications [like] Cloudflare Worker-style Serverless Functions Fascinated to see what happens here. The serverless / edge compute paradigm fits Javascript hand-in-glove philosophically, but until now it's always felt quite clunky to me. When I've tried it out, I've always been left thinking "but this…

Their comparison to Cloudflare workers doesn't seem right. The benefit of cloudflare workers is that they run on the edges of a CDN. Putting Deno on one server wouldn't achieve that.

Then you put Deno on the edge : https://deno.com/deploy

Re: The Deno Company

#242

Post by breck »

hu3 wrote: post #226
breck wrote: post #158

Earlier quoted context omitted.

The best IMO is to go public domain. SQLite is a great example: ( https://sqlite.org/copyright.html ).

SQLite's case is super interesting. It is said that they can get away with having it as Public Domain because a key part of their business is SQLite's reliability which is asserted by their large and closed source test codebase.

> which is asserted by their large and closed source test codebase.

Oh I didn't know (or forgot about) this! Super interesting. I love that strategy.

That's competition at its best. Don't assert any control over someone else, but do keep a few secrets to yourself so people know to come to you for the best stuff.

Re: The Deno Company

#243

Post by ChrisArchitect »

Article left me wondering what the plan is for them here - why is it becoming 'The Company Deno'... other than they have a bunch of investors. Is it just to get a team in to properly manage the project as a whole?

Re: The Deno Company

#244

Post by ivan888 »

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 the abstraction, and to some degree the centralization, of package management is generally a good thing

Re: The Deno Company

#245

Post by turdnagel »

csbartus wrote: post #59

I'm very pleased Javascript / Node evolves. But thanks, too late, I'll skip it as soon as possible. It has so many unpleasant surprises. I'll move the ladder up, to something which compiles to Javascript, or whatever else, but no Javascript anymore please.

You can write TypeScript natively with Deno.

Re: The Deno Company

#246

Post by auganov »

celeritascelery wrote: post #85

> Many are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. Bash and Zsh scripts calling into native code will never go away. But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Many developers, we think, prefer web-first abstraction layers. Every time I read so…

A lot of modern software has to ship a browser version and this simple fact can be all it takes to inform downstream choices.

Let's go with WebSockets as an example. You decide you need them in the browser. This will likely mean some other component will have to support them too. By now you need a pretty good reason to reimplement it over something else. If you need a handshake you may exploit the fact that WebSockets open with a standard HTTP request. Your handshake over another socket may look pretty different. DDoS services, proxies etc may support WebSockets but not arbitrary TCP or they may support it differently. A WebSocket "message" doesn't exist in plain TCP, will you make your TCP protocol work the same or will you handle frames differently?

Point is - your choice may be between just WebSockets or WebSockets AND something else.

Re: The Deno Company

#247

Post by pknopf »

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…

There will likely be some kind of npm at some point.

Re: The Deno Company

#248

Post by searchableguy »

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…

deno has a lock file like other package managers. If you use a lock file, deno will refuse to run if the file has been modified.

Deno caches everything offline and only reloads if you use --reload flag.

I would recommend going through the manual to learn more about deno workflow.

https://deno.land/manual

Re: The Deno Company

#249

Post by jansommer »

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…

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

Re: The Deno Company

#250

Post by Already__Taken »

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

I was just looking for git tooling and found a few node base projects with npm-install instructions. I thought deno is going to eat these things up for teams. We don't want C++ devs to need a node tool-chain for one tool.
Post reply on HN