[ecmascript]

When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript. Most of it is the international libraries anyway so.

I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.

[atraac]

So the fact that everything around is poorly made, forbids him from whining that a certain solution is as bad as everything else? Shouldn't we criticize and point out stuff that is bad, no matter whether it's as bad as something else? It's because of attitude like yours that we get 15mb of javascript on every website, 500gb games and UIs that take seconds to load.

[ecmascript]

Well my point is that it isn't that bad and there's a reason for it being ~100mb. You can throw out the Intl stuff and remove a large portion of that for example.

[0x457]

Modern games aren't 700Gb, there are a very few very large games. One of them is large on purpose to make to delete other games.

Updates for games are large because they aren't "just updated files", but a giant blob that can't be rearranged since it's optimized for loading order later.

Giant self-contained deploys like that are bad because their use case is CLI/GUI tools shipped to the end user. To give you context: my /usr/bin is ~900 binaries and total size is 109mb.

[declaredapple]

100MB at 1Gbps is ~0.8s to load. This especially sucks for FaaS and CI/CDs. This makes it difficult to use for on-demand use cases that are latency sensitive.

That and that's likely 100MB that's going to be competing for memory now* , in FaaS environments especially that's a ton of resources and you increase latency to load that especially over network storage. This also inflates container sizes and just becomes a pain in general.

*Server environments you often don't want to be using swap, and the OS will likely consider it high priority anyway.

I could only agree with you if you have a single monolithic server, don't use containers, don't need to distribute it to others, and don't frequently need to run a CI/CD pipeline. Only then are there not a ton of downsides to a 10mb vs 100mb executable.

> When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript.

People have been complaining about game sizes for years. "You complain about a 100GB game, I don't know why you also complain about a 100mb self-executable for a javascript runtime" doesn't really make sense.

[tracker1]

Could be worse, could be Java. At least in terms of container size, cold start times and overhead at runtime. And I know there are options for AOT, etc. that are all more complex to configure than Deno build.

[konart]

You download it to you game rig, not some cloud solution with limited resources to be paid for. Plus you may want to have more than one instance of service running.

[ecmascript]

Pretty much all cloud services offers way more than that for free and besides, maybe don't use javascript if 100mb is such big of a deal?

[konart]

I'm not using js, but that's not the point of a discussion.

And we were not talking about js, we were talking about Deno specifically. And about binary growing year to year notably.

>Pretty much all cloud services offers way more than that for free

More than what? The question is always about difference in %. The number of services\instances can grow faster than you can rewrite your conde in go\c++\rust of whatever (not to mention you will have to hire people for the task). And all of a sudden this x3-x4 difference matters.

[surajrmal]

This is whataboutism. Different sizes are acceptable for different people based on context. I worry about 10s of kilobytes for things I work on for instance.

[ecmascript]

Yes but there is a reason for it being 100mb. You get a self-contained app where you can get to write in javascript. You don't have to spend 100x the time in order to get the same app working in Rust.

If size is such a big deal, then don't use Deno, Node or Bun.

My issue is that most people that are working in restricted environments would never touch javascript since it's not well suited for those kinds of environments. People that complain tend to be haters that just want something to hate upon.

It used to be about php, now it's about javascript.

[int_19h]

Your argument seems to be that those 100 Mb include the necessary libraries. The problem with this assertion is that much richer runtimes don't require that much. For example, a .NET Core console app published as self-contained is ~65 Mb, and it comes with more libraries than Deno.

[ecmascript]

Well what is the size of .NET that I assume you need installed?

[int_19h]

You don't - that's the size of a completely self-contained binary, with .NET effectively baked in. A "hello world" .NET app that uses external runtime would be measured in kilobytes.

[xtreme]

There are size limits when deploying on serverless or edge infrastructure so developers have to care about that. The providers also typically charge by compute seconds * memory consumed so a larger executable costs real money as well.

[fshr]

The compiled option isn’t intended for serverless or edge uses, you just deploy the source files and the platform takes over.

[dmattia]

Some serverless use cases work like you say, but Docker-based options such as AWS ECS, Docker-based Lambda functions, or Kubernetes would all commonly make use of compiled options

[0x457]

No, you won't use compiled option in k8s or any other container based deployment.

You would use deno as base layer, your dependencies in another layer, your code is in the last layer.