Clarify goals with webpack (in)dependence

In #90, regarding support for webpack’s native support for css modules, @gaearon says:

We might want to migrate away from webpack in the future. We’d need to make our CSS files are as vanilla CSS as possible (aside from minor stuff like relative dependency paths).

and:

Having to back out of infrastructure changes (e.g. super fast new bundler) because people relied on webpack in ways like this would be super sad.

However, there are still a ton of other webpack-isms. Some, like require.ensure for code splitting, will probably be banned now that I’ve drawn your attention to them. But others, like import logo from './logo.svg' or import './App.css' are not only permitted but are part of the boilerplate.

I understand that the purpose of this config is to completely abstract Babel/ESLint/webpack configuration from users, and allow for tooling to change mostly independently from app code. I also understand that some webpack-isms, like image and non-modular CSS loading, are extremely useful for React development.

But CSS modules and dynamic loading/code splitting are also very useful; a decision has been/will be made made that their use does not outweigh the costs. Meanwhile, import logo from './logo.svg' isn’t strictly necessary – images and CSS could be in a static/ directory that gets served by the dev server and bundled in the build – but this project has chosen the more ergonomic approach, even though it couples the project to webpack-specific implementation.

Obviously you have to find a sweet spot between no webpack-isms (if you do that, why even bother?) and all webpack-isms (because that impedes you from using any other tools, and even webpack might drop support for these). So how do you do it? What are your heuristics?

[gaearon]

Things like require.ensure could be problematic but those tend to be used more sparingly than CSS (which is basically half of the project files). They aren’t as painful to migrate away from as custom syntax extensions to CSS, I think.

If we add more JS tools they aren’t going to fail because of require.ensures. Webpack overloads some semantics here but it’s still a JS function call. It’s easy to codemod away if we ever need to do it. We also think code splitting is a necessary feature and we’d have to support it one way or another anyway (although Webpack 2 APIs for this look nicer and we’d like to switch to them in the future).

CSS Modules is much more involved. If you look around PostCSS repos, you’ll find tens of unsolved issues related to CSS Modules support, for example. I’m not saying we plan to use PostCSS more extensively, but we don’t want this to lock ourselves out of this, or to have to figure out how to fix many issues caused by overloading of CSS semantics with custom syntax.

Ultimately our current usage of CSS files is a compromise. We would like to eventually move to a way to represent styles in JS instead. This is a longer term goal and it will take a while before we have something we can recommend to people. But we think this is a better solution to encapsulating styles than a custom syntax extension to CSS.

Since we can’t reach this goal soon, we want to at least leave the door open for it. It seems to me that, the closer our files to vanilla CSS, the easier it will be to automatically codemod them to JS someday if we decide to proceed with moving into that direction. Custom extensions make this harder in my opinion but maybe I’m wrong.

Then why do we even use the Webpack way of importing CSS into components? Again, practical reasons:

1. We want to have at least some knowledge about which CSS files are associated with which components in case we want to codemod CSS usage later.
2. This automatically integrates those files into Webpack build system so it puts right content hashes on output files. This tool has an explicit goal of being suitable for production, and we can’t ask users to run additional “revving” tasks. This nicely sidesteps the problem.
3. This gives us hot reloading of CSS in development which is super convenient.

To sum up:

1. We prefer conventions to custom syntax
2. We don’t know which tools we will support in the future so we don’t want to introduce more potential incompatibilities
3. We think the real solution to encapsulation is using JavaScript primitives (modules), not custom syntax in CSS
4. We want to use patterns practical in production apps so our users don’t need to worry about hashes and stuff
5. We are okay with suboptimal patterns that are relatively easy to codemod away from

I understand if you disagree with some of these points. Like everybody, we are exploring this space, and we need to make some decisions. We might eventually change our minds but for now we decided we care about specifying JS <-> asset dependencies but want assets to stay as vanilla as possible. I hope this helps.

[jquense]

Until it does, we don’t want to artificially “bless” the existing non-vanilla-CSS options by supporting them (rather than their alternatives) here.

This seems like saying “Because we haven’t yet reinvented CSS in React we are going to ignore the last 5 years of best practices, improvements and common choices made by most web developers”. Not to harp on a point but this is exactly the sort of thing folks from outside the React community face palm and shake their head about, a seemingly tone deafness to how most productive web development works outside the bubble of bleeding edge React innovations.

If React isn’t going to have its own special solution then it should at least support some of the things the majority of modern web developers use now and not tell them to do something actively bad like use “plain css”. If anything we should at least look at how successful versions of these tools in other communities work and copy them. Both emberCli and AngualrCli support some amount of config, and easy options for handling CSS (and others) and that has not lead ppl to “fatigue”. Hopefully, there is probably a spot between “nothing” and “write your own babel and postCSS plugins for everything you need”