3 ms·

As someone new to React, but who has used Webpack, I'm glad that CRA is gone. It felt like "ravioli code" to me, and it seemed wrong that everyone was reluctan

As someone new to React, but who has used Webpack, I'm glad that CRA is gone. It felt like "ravioli code" to me, and it seemed wrong that everyone was reluctant to use "eject", but then you couldn't configure any of the underlying tools, like Webpack, easily either. Tools should be easily composable, they shouldn't be clumped together with an inflexible "ravioli" abstraction.

steve_adams_86 4y ago
The irony of CRA is that it would become a system you needed to learn in and of itself in order to navigate the treachery of trying to manage a modern React app. I’m not disparaging it generally though. It was truly useful to many people and reduced barriers to allowing people to more easily experience React. Arguably, the mess of needing to understand internals of CRA to solve weird bugs or needing to eject was in some ways a good thing. Perhaps people wouldn’t have made it that far without the initial ease of building with react! You’re absolutely right though. The design of CRA imposed a lot of inevitable issues. Partially due to how webpack works and due to (in my opinion) the fragility of the npm ecosystem. There was so much complexity and so many dependencies. Perhaps some of these things changed for the better over time — it has been a while since I looked at it. The last time I did, that aspect was labyrinthine and awful to navigate when things went wrong.
- okeuro49 4y ago
  > I’m not disparaging it generally though. Definitely, it was neat how the developers gave you a survey if you did use "eject". But I think the answer is to deal with the issue of making tools more easily composable, or improving the documentation of how to use them, rather than providing the abstraction.
mst 4y ago
I am not much of a fan of CRA myself but I am very much glad that https://craco.js.org https://craco.js.org exists - so far it's handled my needs for tweaking CRA behaviour in situations where "eject" didn't seem like a good route to take. Mostly tbh to stop the freaking thing spawning inotify watchers for the entire contents of node_modules - I don't mind having to do a manual restart when I've changed dependencies and I definitely -do- mind having it eat a shedload of my user's inotify kernel allocation. (I know you can up the allocation, that's not the point, why are you on my lawn? :)

steve_adams_86 4y ago

The irony of CRA is that it would become a system you needed to learn in and of itself in order to navigate the treachery of trying to manage a modern React app. I’m not disparaging it generally though. It was truly useful to many people and reduced barriers to allowing people to more easily experience React. Arguably, the mess of needing to understand internals of CRA to solve weird bugs or needing to eject was in some ways a good thing. Perhaps people wouldn’t have made it that far without the initial ease of building with react! You’re absolutely right though. The design of CRA imposed a lot of inevitable issues. Partially due to how webpack works and due to (in my opinion) the fragility of the npm ecosystem. There was so much complexity and so many dependencies. Perhaps some of these things changed for the better over time — it has been a while since I looked at it. The last time I did, that aspect was labyrinthine and awful to navigate when things went wrong.

okeuro49 4y ago
> I’m not disparaging it generally though. Definitely, it was neat how the developers gave you a survey if you did use "eject". But I think the answer is to deal with the issue of making tools more easily composable, or improving the documentation of how to use them, rather than providing the abstraction.

mst 4y ago

I am not much of a fan of CRA myself but I am very much glad that https://craco.js.org https://craco.js.org exists - so far it's handled my needs for tweaking CRA behaviour in situations where "eject" didn't seem like a good route to take. Mostly tbh to stop the freaking thing spawning inotify watchers for the entire contents of node_modules - I don't mind having to do a manual restart when I've changed dependencies and I definitely -do- mind having it eat a shedload of my user's inotify kernel allocation. (I know you can up the allocation, that's not the point, why are you on my lawn? :)