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

421–430 of 446 posts

Re: The Deno Company

#421

Post by leodriesch »

kibleopard wrote: post #192

The issue with Deno, personally, is that it feels like it doesn’t deviate enough from NodeJS to even make it worth taking the time to learn/migrate projects over to it. From what I recall, the only really new and nice features are: a) sandboxed by default b) no need for a node_modules folder since you can directly import from a URL And is that really worth dumping loads of money into developing further? I just find i…

I think the biggest missing piece right now are the big libraries: Webpack, Babel, Next.js, ESLint (maybe this will no be needed with `deno lint`), NestJS. Stuff like that. I'd think it's hard right now to spin up a project that you would've usually used these frameworks for without writing a lot of infrastructure code yourself.

Re: The Deno Company

#422

Post by Master_Odin »

speedgoose wrote: post #395
ggregoire wrote: post #393

Earlier quoted context omitted.

Yes I agree it's better to have one library with 20 helper functions than 20 libraries with 1 function each. Think Lodash. Although some people will then complain about the size of the library...

Yes. Every Lodash function is available in its own npm package too. I use it like this, I rather have 4 lodash packages than the big whole lodash library in one package with almost everything left unused.

These will go away in v5 (if a v5 is ever released) and is not recommended if using a bundler as it'll end up wasting space rather than saving as it'll include duplicate code that each individual function could share.

https://lodash.com/per-method-packages

Re: The Deno Company

#423

Post by natevancouver »

azinman2 wrote: post #372
whimsicalism wrote: post #364

Earlier quoted context omitted.

I find the idea that AWS will just eat the competition always a little silly as well. I've used AWS managed offerings that were far inferior to the alternatives.

So why were you using the AWS managed offering then instead of the alternative?

Usually because the company already pays an AWS bill. No one will care if you add another Lambda function, but to use an alternative you’ll have to get past some gatekeepers.

Re: The Deno Company

#424

Post by rvz »

KingOfCoders wrote: post #9
ignoramous wrote: post #3

Earlier quoted context omitted.

> From there I stopped reading. Why? Is it https://news.ycombinator.com/item?id=6845286 ? Because the next paragraph goes: 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. We do not want to find ourselves in the unfortunate position where we have to…

"it must remain permissively free." ... until the VCs change their mind or AWS uses our code to make more money than we do.

> ... until the VCs change their mind or AWS uses our code to make more money than we do.

That is the correct answer.

Amazon (AWS) can lift Deno and use it as a service on AWS for devs and effortlessly compete, out scale and out do them 100 times over and supersede the Deno Company. Thanks to using the '...permissively free' MIT license (Being AGPL will also make no difference) AWS can do just that.

Just like how they did that to MongoDB, Redis and Elasticsearch who were all victims of Amazon's ruthless tactics on open-source.

Re: The Deno Company

#425

Post by afiori »

cpcallen wrote: post #354
kinjba11 wrote: post #351

Earlier quoted context omitted.

I agree with the spirit of what you're saying, but there billions of lines of JavaScript code that can't "just go away". Being able to use e.g. 'window.crypto' without worrying about whether I'm in Node, Deno, some other runtime or a browser is great news for reusing huge amounts of code.

I'm in favour of compatibility and against a global named 'window' in a non-browser JS implementation, and I don't understand why the former necessitates the latter. Since window is the global object, why not just refer to crypto? Then you don't care what the global object is named.

It is relevant to this that ecmascript specifies `globalThis` as the global object (the one pointed by this outside of functions in non-strict mode), all js environments have it and simiply globalThis === window || globalThis === global

Re: The Deno Company

#426

Post by [deleted] »

webmaven wrote: post #366
resonantjacket5 wrote: post #317

Earlier quoted context omitted.

Not against url-based imports but I don't quite understand why is "no implied dependency on stateful disk in the runtime itself." a big deal?

> Not against url-based imports but I don't quite understand why is "no implied dependency on stateful disk in the runtime itself." a big deal? I think that lets you deploy to things like edge devices that don't have a hard drive, and even more ephemeral environments.

[deleted]

Re: The Deno Company

#427

Post by afiori »

LunaSea wrote: post #360
ravenstine wrote: post #339

Earlier quoted context omitted.

> This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use. Depends on your point of view. With TypeScript being built in, you don't have to think about using tsc or whatever version of TypeScript you have. It's just what version of Deno you use. If someone doesn't like that, then they still can have the option of using TypeSc…

> That's pretty dismissive. Why should an app that doesn't interact with the file system be allowed to write or even read from it? I don't know how this feature can be considered a drawback. Don't like it? Don't use it. I don't see how it detracts objectively from Deno. Because any app of a medium size and above will require access to all permissions. Also Deno had some obvious security vulnerabilities around symboli…

> due to other tools that will need to live with your app like log shipping, load balancers, DNS caches, firewalls, daemons, etc.

some apps are just CLI tools.

Top-level await helps with the rigidity of the ES module systems[1]; I believe they can also be used with dynamics imports giving ES-modules and CommonJS similar expressivity

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: The Deno Company

#428

Post by afiori »

adkadskhj wrote: post #228
kibleopard wrote: post #192

The issue with Deno, personally, is that it feels like it doesn’t deviate enough from NodeJS to even make it worth taking the time to learn/migrate projects over to it. From what I recall, the only really new and nice features are: a) sandboxed by default b) no need for a node_modules folder since you can directly import from a URL And is that really worth dumping loads of money into developing further? I just find i…

I feel like sandboxing could be huge, but WASM might be cutting the legs out from that feature. Sandboxing doesn't sound so unique or innovative when WASM is coming along and doing the same thing, and with a much wider audience and thus more likely to have massive traction.

They compete on different use cases, most js/ts apps cannot be (reasonably) compiled to wasm and also wasm sandbox doesn't limit what the environment can do.

As a glaring strawman if you expose eval to wasm it will not help you.

Deno's sandbox will allow you to crate a dedicated worker with no network/disk access to handle sensitive informations, or to force your application to use a specific worker as a proxy (by making it the only thing with network acess)

Re: The Deno Company

#429

Post by afiori »

speedgoose wrote: post #396
FunnyLookinHat wrote: post #40

Earlier quoted context omitted.

The built-in Typescript support is amazing, but the selling feature for me was the ability to generate static binaries. Shipping is much easier when your built process can produce a single output!

A NodeJS Docker container is a few lines. I agree Deno's single binary is a nice feature but it's not very interesting for everyone.

Docker is very nice to deploy on docker-dedicated servers, but on legacy app or personal workstations binaries are more flexible

Re: The Deno Company

#430

Post by azinman2 »

natevancouver wrote: post #423
azinman2 wrote: post #372

Earlier quoted context omitted.

So why were you using the AWS managed offering then instead of the alternative?

Usually because the company already pays an AWS bill. No one will care if you add another Lambda function, but to use an alternative you’ll have to get past some gatekeepers.

So there you go. Lots of friction for competitors.
Post reply on HN