Hacker News new | ask | show | jobs
by chakkepolja 1726 days ago
As someone without this new web tech background, I have same experience about react.

create-react-app has so many dependencies and takes a lot of time to scaffold a hello world. Adding some router or some popular library produces deprecation warnings and '2 moderate vulnerability' messages. Folder size will blow up over 1 GB to make trivial apps. That's insane.

3 comments

The "audit warnings" are unfortunately entirely irrelvant to a build tool like CRA:

https://overreacted.io/npm-audit-broken-by-design/

The size of CRA is largely due to its primary dependencies (Webpack, Babel, Jest, and ESLint), which are normal parts of most modern web app build toolchains.

That said, there's plenty of other alternatives. For example, Vite uses a combination of ESBuild + Rollup for its build steps, and has only a relative handful of dependencies. As a result, it installs fast, and creates + starts projects even faster.

None of that is specific to React the UI library, though.

Yes. But I am a n00b and the obvious way was CRA.

In contrast, when I tried sveltejs, the 'official' way using degit worked sewmlessly, standard dependencies were also much smaller than when I used react.

But I will give a try to Vite, thanks for recommendation!

create-react-app is incredibly bloated. My current day job inherited a CRA app, and I've spent silly amount of time getting rid of the rubbish in there. But you don't need most of it.

For a simple production-ready React setup try the following libraries:

- react (obviously)

- redux, and react-redux (which ties react and redux together), and redux-thunk (enables asynchronous redux actions).

- react-router and react-router-dom (adapts react-router for web rather than react-native)

That's 6 libraries, but it's really only 3 as the auxiliary ones under redux and react-router are tiny. If you need to support older browsers then you might also need core-js to polyfill the newer apis, but that's it.

And if you use esbuild to build then you won't need need all the complexity that webpack brings.

Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packages like `redux-thunk` and `reselect` as well.

We've updated the Redux core docs tutorials to teach RTK as the default [1] [2], and have examples of migrating existing Redux logic to use RTK [3].

As for the CRA aspect: I still don't really understand why some people refer to CRA as "bloated". It has all the standard pieces that have been used in the React ecosystem for years: Webpack for bundling, Babel for transpilation, Jest for testing, and ESLint for linting, and all with a very reasonable default configuration that has had thousands of hours of effort to deal with edge cases.

I'm not saying that CRA is _perfect_. The maintenance has been spotty lately, it's taken a very long time for the Webpack 5 branch to get close to release, and I'd love to see CRA adopt tools like SWC or CRA to speed up builds. But given the problems in the ecosystem before CRA, it's done exactly what it was supposed to: provided a single command to set up a new React app with good build defaults.

[0] https://redux-toolkit.js.org

[1] https://redux.js.org/tutorials/quick-start

[2] https://redux.js.org/tutorials/essentials/part-2-app-structu...

[3] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

> It has all the standard pieces that have been used in the React ecosystem for years

Yes, that's the problem. It has ALL the pieces, whether you are using them, whether you understand them or not. For example, most projects will use either babel typescript. CRA? It has both and extra logic to switch between the two.

I feel like a better approach would be / have been an "open book" config where there is minimal starting point and it teaches you how to add the extra bits you want/need. That way it would be kept as simple as possible, and people using CRA would actually understand the tools they are using.

I'm genuinely curious - what difference does it make to you, the end user, if CRA has that extra logic internally? You won't see any of it unless you intentionally eject, and all it really is is some checks in the Webpack config file and the startup process.
And don't even think about using "npm audit fix --force", it wants to downgrade the react-scripts dependency from 4.0 to 1.1 and introduce another 50 vulnerabilities.

Not the smoothest first impression for what's supposed to be the "on rails" introduction to react development.

I found svelte ecosystem to be much lighter than react, svelte also being much smoother to write, but sadly it's still new and doesn't have the same amount of libraries that react has.