[acemarke]

Yep. To repeat Dan Abramov's standard reply:

> The set of dependencies that Create-React-App uses includes:

> A compiler. a bundler/linker, an optimizing minifier, a linter, a development server with live reloading, and a test runner

All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.)

As you said, a full-blown IDE like XCode or Visual Studio is easily multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of dozens of MB - those are just usually preinstalled on Linux or Mac systems.

So, context is pretty important here. A couple hundred MB for a complete JS build toolchain is understandable. I don't think it's necessarily _good_, and I think it can be improved a lot (especially with upcoming tooling like NPM Tink and Yarn PnP), but it's not the catastrophe many make it out to be.

[lewisjoe]

Here's an interesting observation from recent HN reactions to JS:

+ The hardcore server folks are hating JS these days, because it requires more than dropping a single script tag.

+ The full-stack people / JS beginners are hating JS with a passion, because they think it's unneeded complexity for their deadline.

+ Advanced JS veterans totally like how the JS ecosystem is rapidly maturing & solving its problems in interesting ways.

And there's people like you (the latter), constantly explaining the former groups that JS isn't so bad.

I'll see if I can write a blog (or a book if it has to be) on each part of JS ecosystem that has changed with detailed explanations on why it is better.

I already wrote a piece along those lines - https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... but I guess I (or someone else) can do better.

[ryanbrunner]

I think this is all true, but one important factor is that there's currently an assumption that any serious project must necessarily use all this complexity, which makes your second point true - but not in a way that's the fault of javascript, but more the community around it.

If you're making a simple site, or even a fairly simple application, the typical modern Javascript toolchain is absolutely unneeded complexity. It's not even React - many developers will turn their nose up on anything that isn't using Redux / Typescript / GraphQL / whatever flavour of the week is popular, even on sites where Javascript itself is probably not that big a requirement. As an example, we're all talking on a site that has almost no Javascript and works perfectly well - but I have no doubt that if you hired a developer to build a site like this in 2018 it would absolutely use a typical complex setup.

That isn't Javascript's fault, really - no library demands that you use it for everything, and many like Redux make it a point to push users away from using them inappropriately. But the Javascript community is currently in a phase that's probably unhealthily pushed towards the new, shiny, more complex library, regardless of how well it suits the problem.

[bjoe_lewis]

I have to agree with you. The shiny stuff syndrome is spreading like cancer in the front-end world.

The only way to set this right is: when you create something, don’t sell it as a one size fit for all solution. State the tradeoffs as loud and clear as possible. Guide the users on what point you necessarily need the library and point them to simpler alternatives when needed.

This is something I deeply respect about Dan Abramov. He did this with Redux. Now that he’s in React, I see a lot of this culture in React docs as well these days.

Bottomline: The responsibility is on the creators to stop spreading this shiny stuff syndrome.

[acemarke]

I will say that as a current Redux maintainer, I _hate_ that I seem to have to spend more time cautioning people about when it's appropriate to use Redux, than I do actually promoting its use. :( I can't think of any other lib off the top of my head where the maintainers have had to do that.

That said, yeah, we've got a Redux FAQ entry that discusses when you should use Redux [0], and some other "caveat"-type sections scattered throughout the docs.

We're currently planning a revamp of the Redux docs structure and content [1], and we'll see if we can improve some of the messaging as part of that. Would appreciate any suggestions you can offer.

[0] https://redux.js.org/faq/general#when-should-i-use-redux

[1] https://github.com/reduxjs/redux/issues/3313#issuecomment-45...

[silverwind]

> many NPM packages do include unnecessary files in the published artifacts

This is the main reason node_modules grow so quickly. Many authors are careless on what files they include in their published packages.

The npm cli now makes the package files and size visible during publishing, but I guess we need some way to shame authors publishing big packages, maybe by including size info on the npm website and downranking them in searches.

[jjkaczor]

>Visual Studio is easily multiple gigs

In June of last year, I had to prepare an offline Visual Studio installer for an isolated environment - the install package (with all available options) weighed in at over 50gb...

[acemarke]

Right, exactly. Now, that can be broken down into smaller chunks based on what toolset you're intending to work with (C#, C++, web, SQL, etc), and the sizes for each toolset vary, but clearly these toolsets take up a lot of space.