Replies: 3 comments 1 reply
-
I think it's worth looking at Razzle, and I do appreciate the effort that went into getting this working. I share some of @colinmegill's scepticism about config frameworks on top of webpack, but that comes from experience with CRA and |
Beta Was this translation helpful? Give feedback.
-
New folder structure and root directory is cleaner, I'll give you that. |
Beta Was this translation helpful? Give feedback.
-
I'm still interested in helping this move forward. |
Beta Was this translation helpful? Give feedback.
-
@colinmegill you've expressed a prior view that CRA or razzle or any CRA rewiring tool is either (1) only for toy projects, or (2) not stable or reliable enough to lean on. This may have been the case several years ago, but I'd suggest it's no longer true.
Here is someone's blog post from last summer espousing that hand-tuning is better than CRA. Note the pile-on in the comments, where those who are critiquing his arguments get tons of +1 votes. Essentially no one agrees, except someone who says something nice about "hand-tuned config as student learning project".
Here's a reddit thread in the reactjs subreddit 2 years ago, and the vast majority say they use it in production: https://www.reddit.com/r/reactjs/comments/81gfl6/do_people_use_create_react_app_in_production/
I'm trying to take another run at getting us off gulp in favour of webpack, but find myself rebuilding and refiguring lots of what I know exists and we already got working using a well-maintained framework. Truly, this work is done already, and if we were to merge that PR with your blessing, and then decide we don't like it later, it will be no more work than is already necessary now if we go it without a build framework like Razzle.
@ballPointPenguin spent a good chunk of time coworking with me on a call, comparing/contrasting and preparing a countering perspective of Razzle. Razzle is a framework option that lets us diverge a bit from CRA for our edge-case deploy stuff: #515 (comment) (it's essentially CRA + tunability)
Basically, that whole PR removes hundred of lines of bespoke and spaghetti code (gulpfile alone ~= 500 LOC) from our build process, and replaces it with 170 really clear lines of modified webpack config. This custom tunes a 10k-star build tool, Razzle.js. And it's ready to merge now for
client-admin
, and would be really easy to drop intoclient-report
as well. And once on same build system, we can merge those apps quite easily, and upgrade nodejs (since it's gulp holding us back). Basically, a cascade of benefits, and if we ever want to back out, it's only as much work as is being proposed right now to do it otherwise.Compare the cleanliness of this new folder structure:
https://github.com/pol-is/polis/tree/create-react-app/client-admin
With the current messiness:
https://github.com/pol-is/polis/tree/dev/client-admin
cc: @micahstubbs
Pls pls pls pls can we reconsider, or can it at least get a consideration after sync convo? Between the two of us, there was maybe 100 hours spent on that PR. While I understand it was never guaranteed to be merged, it didn't totally feel like it got a fair shake of consideration -- I recall the main resistance ("these frameworks are for toy projects") didn't feel grounded in current state of reactjs ecosystem.
Anyhow, thanks for hearing me out! ❤️
Beta Was this translation helpful? Give feedback.
All reactions