[jongjong]

If you count frameworks and libraries, I agree that the amount of bloatware is insane, but I don't think this is because of JavaScript. It's just that a few large companies which happen to use JavaScript (as most tech companies do) have been pushing their complex frameworks and tools onto everyone else and these happen to be bloated; they're only really effective in an environment where the employee headcount is not a concern - The real purpose of bloated tools (which are obsessively focused on 'code safety' as opposed to good architecture) is to allow companies to throw 10x more employees at a problem and not reduce the reliability of their development processes... But if they had chosen to hire better employees in the first place (with better hiring processes), they wouldn't need 10x more employees to get the job done in the same amount of time.

[Pet_Ant]

Framework bloat is community-scale efficiency. [Everybody uses a different 20% of the framework](https://www.joelonsoftware.com/2006/12/09/simplicity/), but it means that the core infrastructure, team, QA, etc are pooled. If you need to expand to 21% you already have that covered. If you look at the popularity of Spring Boot you see that people want more integration and between libraries not less. Now, it drives me nuts and definitely offers many sub-optimal solutions, but we need to face it, large frameworks are here to stay. Large frameworks are the new operating systems. You can do better with custom on bare-metal but there is a reason the Linux nevermade it on the desktop.