webpack-common-shake
meta
Our great sponsors
| webpack-common-shake | meta | |
|---|---|---|
| 2 | 5 | |
| 914 | 113 | |
| - | - | |
| 0.0 | 0.0 | |
| about 1 year ago | over 3 years ago | |
| JavaScript | ||
| - | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
webpack-common-shake
-
CommonJS Is Hurting JavaScript
While I agree the dynamic nature of CommonJS would be problematic, there were successful projects around treeshaking commonjs[0] that worked really well.
I think dynamic imports have some of the same footguns here, to be honest. Can't deny ESM is easier to statically analyze though, that much appears to be true across the board based on available evidence.
[0]: https://github.com/indutny/webpack-common-shake
-
[AskJS] What are still present issues in contemporary (2022) JavaScript?
Tree shaking in CommonJS is possible: here's a Webpack CommonJS Tree Shaking package.
meta
-
CommonJS Is Hurting JavaScript
> You write this as if that mattered... Should he only works on stuff that gets more download?
It was a statement of fact. You appear to be drawing conclusions that were never hinted at nor implied. It's tiresome.
> It's normal to be sad to have lost someone that was working on something you needed, but anything else is just entitlement.
How and why are you applying entitlement and emotion to a documented statement of fact? Do you need to see links such as [1] to view that as fact? It's one of a myriad. Take your asinine analysis and commentary elsewhere, please.
[1] https://github.com/sindresorhus/meta/discussions/15
-
Today’s JavaScript, from an outsider’s perspective (2020)
ESM is the biggest waste of time in the JS ecosystem. People are trying to move thing to ESM before it's even in a stable enough state. Mixing ESM and commonjs is a PITA. I've been a JS-only dev since 2013, and I've had enough of ESM ideologues.
See https://github.com/sindresorhus/meta/discussions/15 for just ONE example of this mess.
I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.
- It's a community splitting decision, like Python 3 vs 2.7, which has been an on-going battle for over a decade, I wouldn't be surprised to see the same happen here unless changes are made.
-
My collection of helpful Utility Types :D
Also here's some reading for you by people that are saying the same thing I am: - The dude that wrote half of npm: https://github.com/sindresorhus/meta/discussions/7 - The guy who wrote "JavaScript the Good Parts": https://www.youtube.com/watch?v=PSGEjv3Tqo0&feature=youtu.be&t=9m21s
What are some alternatives?
proposal-upsert - ECMAScript Proposal, specs, and reference implementation for Map.prototype.upsert
packj - Packj stops :zap: Solarwinds-, ESLint-, and PyTorch-like attacks by flagging malicious/vulnerable open-source dependencies ("weak links") in your software supply-chain
esm - Tomorrow's ECMAScript modules today!
tetra - Tetra - A full stack component framework for Django using Alpine.js
loader - A universal async JS loader.
paperclips - Universal Paperclips mirror
proposal-do-expressions - Proposal for `do` expressions
node-fetch - A light-weight module that brings the Fetch API to Node.js
.NET Runtime - .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
node - Node.js JavaScript runtime ✨🐢🚀✨
utility-types - Collection of utility types, complementing TypeScript built-in mapped types and aliases (think "lodash" for static types).