4 ms·

It's Facebook library, not FE framework, enough for me. Never spent so much time configuring Angular app as React one.

madeofpalk 6y ago
What configuring do you need to do to use React? Install Node, run `npx create-react-app my-site` and you're all configured.
- deleted 6y ago
  [deleted]
- dimitrios1 6y ago
  CRA is one way to get a very opinionated starter kit, but like all boilerplates and toolkits, they are very tailored to one particular use case, and you never learn what is possible with the library outside of the toolkit. Breaking from the happy path of the toolkit yields an even more frustrating experience than if you had set it all up by yourself. (Ejecting anything above a medium-complexity SPA from CRA is painful) For example, on the reactjs.docs, https://reactjs.org/docs/create-a-new-react-app.html https://reactjs.org/docs/create-a-new-react-app.html, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.
  - amenod 6y ago
    In practice though, unless you have some very specific needs (and the people I have met who thought that they did, well,... didn't :) ), you should still "just use CRA". There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
    - codingdave 6y ago
      I've been on the other end of that story, where entire dev organizations freak out because of a concern with webpack, babel, or some other piece of the stack... and nobody knows how to fix it. CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
      - sli 6y ago
        I agree with it being important to know how to do this stuff from scratch (with Google, let's be realistic), but the black box problem is solved by ejecting.
        kingdomcome50 6y ago
        Have you ever ejected a CRA? If you think your problems are about to be solved after doing the above... I have a bridge to sell you.
    - fabioborellini 6y ago
      My excuse for longing for something non-CRA is updating an existing frontend to React piece by piece. To integrate it with the existing Django app’s asset pipeline, I kind of had to eject and now my Webpack configuration and its dependencies are completely out of control. I am considering starting over with another tool chain, copying the existing components to the new structure. Replacing the whole thing with a new SPA would not have been feasible.
    - wilsonrocks 6y ago
      We have a project we unejected to CRA. Or maybe injected...
  - duxup 6y ago
    >are very tailored to one particular use case What is that one use case? What are the others that don't fit?
  - madeofpalk 6y ago
    I don't think CRA is particularly opinionated, at least for the common scenario of "I want to make a react website". It doesnt force you down many (if any) routes, or prevent you from using too many popular technologies. Yes, 100%, if you have more exotic requirements from a bundler or build toolchain then you'll need to look elsewhere and probably have to start learning tools like Webpack in more detail. I try and avoid those requirements.
    - timw4mail 6y ago
      It's SOOOOOOO slow, though.
- kingdomcome50 6y ago
  Have you ever ejected a CRA? Your problems are just beginning once you've opened that can of worms. I used CRA exactly up until the point when I ejected it the first time. Never again. The sheer amount of code behind CRA is... remarkable. Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging. I'm sure other projects have other needs, but it's really not that hard to understand these technologies. And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
  - madeofpalk 6y ago
    The comment I was replying to was "React has too much configuration", which I disagree with because CRA and other low-effort build tooling exists. I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
    - kingdomcome50 6y ago
      Sorry, the impetus of my comment above was that CRA is introducing FAR MORE configuration/dependency/complexity than maintaining a webpack.config.js file! The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with. Go ahead, eject a CRA sometime. See how "low-effort" it really is...
      - madeofpalk 6y ago
        I've splunked through CRA webpack config and submitted patches to the project. I've ejected and then years later un-ejected because I didnt want to maintain a webpack configuration.

What configuring do you need to do to use React? Install Node, run `npx create-react-app my-site` and you're all configured.

deleted 6y ago
[deleted]
dimitrios1 6y ago
CRA is one way to get a very opinionated starter kit, but like all boilerplates and toolkits, they are very tailored to one particular use case, and you never learn what is possible with the library outside of the toolkit. Breaking from the happy path of the toolkit yields an even more frustrating experience than if you had set it all up by yourself. (Ejecting anything above a medium-complexity SPA from CRA is painful) For example, on the reactjs.docs, https://reactjs.org/docs/create-a-new-react-app.html https://reactjs.org/docs/create-a-new-react-app.html, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.
- amenod 6y ago
  In practice though, unless you have some very specific needs (and the people I have met who thought that they did, well,... didn't :) ), you should still "just use CRA". There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
  - codingdave 6y ago
    I've been on the other end of that story, where entire dev organizations freak out because of a concern with webpack, babel, or some other piece of the stack... and nobody knows how to fix it. CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
    - sli 6y ago
      I agree with it being important to know how to do this stuff from scratch (with Google, let's be realistic), but the black box problem is solved by ejecting.
      - kingdomcome50 6y ago
        Have you ever ejected a CRA? If you think your problems are about to be solved after doing the above... I have a bridge to sell you.
  - fabioborellini 6y ago
    My excuse for longing for something non-CRA is updating an existing frontend to React piece by piece. To integrate it with the existing Django app’s asset pipeline, I kind of had to eject and now my Webpack configuration and its dependencies are completely out of control. I am considering starting over with another tool chain, copying the existing components to the new structure. Replacing the whole thing with a new SPA would not have been feasible.
  - wilsonrocks 6y ago
    We have a project we unejected to CRA. Or maybe injected...
- duxup 6y ago
  >are very tailored to one particular use case What is that one use case? What are the others that don't fit?
- madeofpalk 6y ago
  I don't think CRA is particularly opinionated, at least for the common scenario of "I want to make a react website". It doesnt force you down many (if any) routes, or prevent you from using too many popular technologies. Yes, 100%, if you have more exotic requirements from a bundler or build toolchain then you'll need to look elsewhere and probably have to start learning tools like Webpack in more detail. I try and avoid those requirements.
  - timw4mail 6y ago
    It's SOOOOOOO slow, though.
kingdomcome50 6y ago
Have you ever ejected a CRA? Your problems are just beginning once you've opened that can of worms. I used CRA exactly up until the point when I ejected it the first time. Never again. The sheer amount of code behind CRA is... remarkable. Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging. I'm sure other projects have other needs, but it's really not that hard to understand these technologies. And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
- madeofpalk 6y ago
  The comment I was replying to was "React has too much configuration", which I disagree with because CRA and other low-effort build tooling exists. I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
  - kingdomcome50 6y ago
    Sorry, the impetus of my comment above was that CRA is introducing FAR MORE configuration/dependency/complexity than maintaining a webpack.config.js file! The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with. Go ahead, eject a CRA sometime. See how "low-effort" it really is...
    - madeofpalk 6y ago
      I've splunked through CRA webpack config and submitted patches to the project. I've ejected and then years later un-ejected because I didnt want to maintain a webpack configuration.