,
40 tweets,
5 min read
Read on Twitter
This attitude is exactly what prevents webpack from owning its own mistakes. Worse, it kills any discussion around Webpack 1/n
The laws of diminishing returns and all that. You solve a common problem that 80% of people face, then the next 80% etc. 2/n
Provide configurable opt-outs for people who want something else. *not* opt-ins for the most common cases out there
I wonder how many people still manually provide all of theire node_module dependencies to CommonChunksPlugin because the docs say so 4/n
And because CommonChunksPlugin doesn't split node_modules in a separate bundle by default 5/n
How many people struggle to properly include generated bundles in their HTML pages because *web*pack *doesn't* provide a way to do it? 6/n
How many people struggle to figure out why the countless "caching" plugins don't cache jack shit? 7/n
Oh, thank god the webpack team decided to write a 100-page treatise on how to achieve proper caching... Instead of making it the default 8/n
Sean boasted how they reduced bundling times at microsoft ... using a non-documented plugin ... 9/n
that "solves the *most common* config problems of the official plugin". Make it default? Heck no. Let everyone suffer. 10/n
Here's a related issue, by the way github.com/asfktz/autodll… 11/n
And the list just goes on and on and on and on. Instead of providing sane defaults every single part provides indecipherable configs 12/n
Look at prettier. They didn't even provide any configuration until they made sure that all the defaults work properly. 13/n
And a perttier config is *override the defaults*, not a way to struggle and get the default behaviour working in the first place 14/n
So, when the webpack team tells you there is no commonality between web projects, they are disingenuous *at best* 15/n
I'll have a separate discussion on how this is also verifiably false but I have to run now 16/n
Let's unroll this gem, shall we: 17/n
The claim by @TheLarkInn that the problems with config stem form it being Javascript are verifiably false 18/n
Look at this screenshot of a sample webpack config and tell me if you spot a problem 19/n 
Yup. Eve ry single array is in natural order. The loaders/use array is in *reverse* order. This is not a JS problem. 20/n
This is a deliberate design choice by the Webpack team. It made sence at the beginnig, when it was just loaders 21/n
It stemmed from how people would abuse the `require` mechanism and how it was solved at the time. webpack 2 came and deprecated loaders 22/n
It now has the new and more powerful rule system. The team deliberately left the loader order as is. A JS problem? Not in the least 23/n
Look at this next screenshot. Notice something strange? Aka main reason webpack configs cannot be serialized/loaded/diffed/optimized? 24/n
Indeed. Loaders are initialized with options. Plugins are initialized with options. One is a declarative list (in reverse order) 25/n
The other? A list of imperative initializations and object instantiations. Is this a JS problem? Nope, a deliberate design choice 26/n
There are many more such things. For example, `entry` can be either a string, an object, or an array. A JS problem? Nope, design 27/n
The main problem, obviously, is the lack of sane defaults. At least one member of the team thinks there can be no sane defaults 28/n
Which is verifiably false, see previous discussion. This hints at a much bigger problem. Will this blindness lead to bad decisions? 29/n
So, webpack 4 will have a fully re-written plugin system. Because there's a big performance hit running many plugins in large projects 30/n
Would removing the need for most plugins in common cases solve the same problem? No one knows.The team doesn't acknowledge common cases 31/n
Currently webpack needs three separate plugins to achieve predictable long term caching. What about removing all three? 32/n
Webpack needs a separate plugin to inject links to generated assets into html files. What about removing the need for the plugin? 33/n
Webpack needs a convoluted setup to make sure node_module deps are separated into a separate chunk. Why not remove the need? 34/n
Webpack needs a magic step to extract "manifest" (which gets duplicated in every chunk). Why not remove the need? 35/n
Webpack needs an undocumented plugin to solve the problems of the official DLL plugin. Why not remove the need for either? 36/n
These are not the problems of JS. These are deliberate design choices and failures. Failure to recognize them as such is very worrying 37/n
Failure to recognize the existence and the need for sane overridable defaults is just as worrying 38/n
As Tom Dale said, Webpack really needs competition. Anything that provides sane DX will take the world by storm 39/n
I said this before: this is the reason create-react-app is so popular. Meanwhile, enjoy your horrendous unmanageable webpack configs 40/40
