Clarify goals with webpack (in)dependence

[modernserf]

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.

[gaearon]

Hope this helps! I’ll close as non actionable.

[geelen]

I wish I'd found this issue earlier. It's a wonderfully succinct explanation of your design goals, @gaearon, and to me totally refutes the arguments for adding Sass/cssnext over in #78, and puts big question marks over the compatibility of the PostCSS ecosystem with this project, CSS Modules included.

You've given me lots to think about!

[taion]

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.

This seems like an odd goal for a "create react app" project.

As with probably everyone else, I found @vjeux's "CSS-in-JS" talk extremely interesting, and I think there are a lot of benefits to exploring this space of extra CSS tooling.

That's very different from saying "the starting point for creating a React app is to also throw away everything you know about styling and instead use CSS-in-JS".

I think it would dramatically reduce the usability of this tool if it took such an opinionated approach to styling, especially given that said approach would be extremely unconventional.

Doing something like dropping CSS here and codemodding everyone's CSS to JS would be more than a recommendation – it would essentially be an imposition if this tool takes off as the standard entry point for new people into the ecosystem, and would make creating a React app less approachable.

[taion]

Also, judging by the current crop of encapsulated styling solutions floating around, the biggest challenging to automatically converting CSS to one of the encapsulated styling systems is that there's no obvious way to represent vanilla CSS selectors like .btn-toolbar > .btn – I'm not aware of any ways to directly represent that in any of the encapsulated styling systems I've seen.

[geelen]

@taion at this point you seem to be repeating yourself. Your goals for this project clearly differ from those who maintain it and if they're not convinced by your 25 (!!) comments in #78 I doubt they will be now. I consider it to be as simple as this

• React, Babel, Webpack, Eslint, etc, are all stable enough that a single project with no customisation can now support a good chunk of the use-cases & get people building real apps. For use cases beyond that, there is eject.
• Nothing in CSS is clearly the "winner" yet, therefore don't adopt anything for the time being (except introduce per-component styling which is definitely going to form part of the solution). If you need something else, there is eject.

There are already a multitude of React starter projects out there with Sass/PostCSS/CSS Modules etc enabled. This project is a week old.

I for one think the design (and adherence to a policy of nothing configurable/optional) is inspiring. Imagine if someone "solved" component-based CSS as well as React solves component-driven UI development. Let's go work on that instead.

[gaearon]

I think it would dramatically reduce the usability of this tool if it took such an opinionated approach to styling, especially given that said approach would be extremely unconventional.

At some point we think React itself might take an opinionated approach to styling. If it ever does, we will recommend it here because having so many options is confusing and not very composable.

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

[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"

[gaearon]

We are going to reevaluate this choice after a little while. There are other high priority issues to sort out before we can get to a 1.0 that we can link from React docs. 😉