[snowl]

If your node_modules is 3.7GB, you are doing something seriously wrong. My node_modules for a 100k+ line app is 243MB and that includes all my dependencies, compiler and testing frameworks which seems very reasonable. All compiled down to a 4MB blob which seems pretty reasonable for a big app :)

[drcongo]

3.7GB was obviously an exaggeration for comic effect, however, I laughed just as hard at 243MB. How on earth do you think that's OK?

[rak1507]

243 MB?! If that's all code (which is unlikely, sure) and it has an average line length of 100, that's 2.4 MILLION lines! Do you really need that, (no), or have you just 'stockholm syndrome'-d yourself into believing this is not a problem?

[acemarke]

I just tried running WinDirStat on the `node_modules` folder in a Create-React-App project I had lying around. Total size was 234 MB. Of that, 129MB was JS files. By far the biggest piece was TypeScript, which has 45MB of .js in 6 files making up its parsing and IDE language service implementation.

Beyond that, the breakdown is:

- .ts source files: 25MB

- Sourcemaps: 23MB

- Markdown: 15MB

- JSON: 10MB

It also looks like there's a 12MB Linux binary that was only in there as a publishing accident for the `user-event` library that has since been resolved ( https://github.com/testing-library/user-event/issues/266 ).

Or, take Redux Toolkit, which I maintain. If you look at https://unpkg.com/browse/@reduxjs/toolkit@1.6.2/ , the published package for our current version, it adds up to about 10MB on disk. But, that's because we ship three separate entry points (RTK core, RTK Query UI-agnostic core, RTK Query with React-specific additions), and for each entry point we compile the code to multiple file formats (CommonJS, ESM legacy, ESM modern, ESM with "dev" and "prod" already built in, UMD dev, UMD production), and each of those has sourcemaps. The actual amount of code that ends up in your bundle is about 20KB min+gz.

So, it's a combination of many things: TS itself is big, libraries typically publish packages containing both the original source code plus multiple build artifacts to run in different environments, and packages also include various metadata and other files as well.

I'm not saying this is necessarily a _good_ situation :) Goodness knows that JS dependency trees _should_ be much smaller. But there's a lot more nuance to it than just "245MB of code wut lol".

[lhorie]

There's definitely an anchoring effect going on. I remember when dart came out and people were like "lol 100kb hello world, wtf" and now people say "4mb app is reasonable" and nobody bats an eyelid.

[acemarke]

Heh, that's actually part of the point I'm making - big difference between "size of build dependencies unzipped and extracted on disk", vs "size of actual app bundle".

[abstract_put]

As an alternative view, while living in a very unremarkable North American area I have atrocious internet service. I don't think it's particularly uncommon, but it certainly is enlightening to browse the internet. Depending on the time of day a 4MB blob by itself can take ~8 seconds to download. 8 seconds is a _long_ time.

Obviously I have no idea what your app is, I have found very frequently it is not reasonable to have blobs of similar sizes (especially if text content waits for some front end framework to download/initialize).

[kirse]

Certainly. My hope is things like WASM eventually make Javascript obsolete if we're into pushing giant blobs of client UI over the wire. Blazor / Bolero in C#/F# are promising starts in that direction.

[sadn1ck]

How do you compile it to a single blob?

[ruszki]

With tree shaking, and it is usually split into several files for caching purposes and to download only what's really necessary.