[docs] Improve bundle size option 2 advantage wording

[ilanbm]

Speed is identical between option 1 and 2.

---

#### fast-imports

Converts all @material-ui/core top level imports to direct path imports

-import Card, { CardActions, CardContent } from '@material-ui/core';
+import CardContent from '@material-ui/core/CardContent';
+import CardActions from '@material-ui/core/CardActions';
+import Card from '@material-ui/core/Card';

find src -name '*.js' -print | xargs jscodeshift -t node_modules/@material-ui/codemod/lib/v4.0.1/fast-imports.js

on https://material-ui.com/guides/minimizing-bundle-size/ it says that direct path imports are the fastest way. Current existing codemodes don't satisfy the need to rapidly use this fast import option.
screenshot from minimizing-bundle-size doc:

[mui-pr-bot]

No bundle size changes comparing d28f415...90d2c90

Generated by 🚫 dangerJS against 90d2c90

[oliviertassinari]

on https://material-ui.com/guides/minimizing-bundle-size/ it says that direct path imports are the fastest way.

@ilanbm The Babel plugin on https://material-ui.com/guides/minimizing-bundle-size/#option-2 is meant to provide equal bundling speed. If somebody cares enough to apply a codemod, would it be better to use the Babel plugin instead?

[eps1lon]

TL;DR Optimizations should be handled at compile time not manually.

It makes more sense to put this into a babel plugin since this can give us the freedom to move things around internally and address that in the babel plugin. Any optimization with a codemod has to be reapplied if the codemod improves/changes. Same applies to new code that you introduce which also needs this codemod applied.

We had this stance on the /es build as well. Put path transforms into a single place instead of spreading it throughout the entire codebase.

[ilanbm]

@eps1lon the goal here is to have fast imports that don't need extra compilation / tree shaking.
So what you suggest contradicts the goal of having a simple way to change imports to the fast way, doing it on compilation contradicts the goal

[ilanbm]

@oliviertassinari if option 2 has equal bundling speed, then why is it the direct import titled "fast"?

[eps1lon]

So what you suggest contradicts the goal of having a simple way to change imports to the fast way, doing it on compilation contradicts the goal

I'm pretty sure that by doing it during transpilation webpack won't pick up the first bundle. We're implementing naive tree-shaking at the transpiler level. The cost of rewriting an import is negligible.

But if you have some benchmarks comparing a babel plugin which rewrites the import with pre-rewritten imports then I would take a look again. Otherwise I'll reiterate that optimizations should almost never be done manually. That's what a compiler is for.

[oliviertassinari]

@ilanbm I would propose that we focus on the documentation. If the page makes you think that option 1 is the fastest, then we don't do a good job with the current wording. It's fast, as much as option 2 with the Babel plugin. I think that we can expand this sentence.

This option provides the best DX and UX.

Should we continue the documentation changes in this pull request?

[ilanbm]

@oliviertassinari I agree, if they are fast the same way than the docs weren't so clear
(and thanks for the chrome autofill commit :) )

[oliviertassinari]

@ilanbm I have tried to improve the wording with a new commit. Let us know if it's better of it you have a different suggestion :).

[ilanbm]

@oliviertassinari it's way better now, now it is clear. thanks!

[joshwooding]

Great re-wording!

updated