A Newly-Generated Create-React-App 2.1.5 App Has 1,568 Dependencies

Long-term, stuff like the size of `node_modules` seems very solvable.

Simultaneously with that, I do think that there'd be benefit if some of the larger JS build tools started evaluating their own transitive dependencies and submitting PRs to inline some of the smaller pieces somehow [0].

[0] https://twitter.com/acemarke/status/1073593305378754560

For example, if you prefer to use small wrapper functions like `h(MyComponent)` and `div()`, there's `react-hyperscript-helpers` [0].

More recently, Jason Miller published `htm` [1], which provides near-JSX syntax using ES6 template literals, and no build step required. It appears to be a very viable alternative to JSX in many ways.

[0] https://github.com/jador/react-hyperscript-helpers

[1] https://github.com/developit/htm

What's painful about it? I prefer it without JSX, personally; JSX is a pretty simple syntax transform that doesn't really gain you anything that I can see, makes manipulating props a lot clumsier, and needs extra tooling. Most of the time it's almost identical with or without JSX, but when there is a difference, I've always found without to be smoother and clearer. You definitely want to assign React.createElement a shorter name, though.

Not just because it's harder to use without JSX (and JSX is a great idea), but also because every Stack Overflow answer assumes you're using Webpack and JSX. For a beginner, choosing not use JSX or Webpack, etc just makes the learning cliff steeper.

https://reactjs.org/docs/add-react-to-a-website.html#quickly...

For me, I find that it's a function of overall value to your code, number of issues you've had with it, overall size, ability to understand the code relative to what it's doing, and project health. Again, the calculus is different for everybody, but the important aspect is that you're consciously thinking about the utility of the dependency.

An ORM is hard to write, is often hard to read, but provides extreme value, and hopefully has a large community to quash issues and contribute to the project's health. To borrow an extreme example, left pad is not. Even if left pad is not in your core competency, that's not something that should be brought in because you can write your own. Even left pad may be subject to the event-stream style attack, and it being out of your control is risk you're bringing into your project.

Risk management is tricky, and you'll never get to 0 risk, but you should try to minimize it where you can reasonably do so. It's all about balance.

Tooling helps with this, but I usually do this reevaluation task when I go to do dependency bumps. "Why can't I bump this dependency to its current version?" usually causes me to reevaluate the dependency thoroughly. Many times it results in just making an upstream PR, but sometimes the decision is made to inline the parts that are used. As an example, we had a dev dependency that all it did was print tables with borders for pretty printing test failures in some capacity. When I went to do a language bump, it was incompatible, so I rewrote it in 10-15 lines using the standard language library. At the time, it was helpful, but it overstayed its welcome by preventing a language upgrade. As a counterexample, our ORM has caused me extreme strife this month because it changed a feature we were relying on heavily. That resulted in a bunch of work, but the dependency is so useful to our project that I would not have considered rewriting it.

Introducing dependencies is a quick way to get to market since you don't have to build a universe from scratch.

Once you've gotten to market, you have to support your thing. This is when dependencies start to have a non-zero cost. When you'd rather spend engineering efforts on building new features, you instead have to do regular house cleaning to make sure your thing continues to work and have a happy upgrade path.

The larger the engineering organization you work in, the more apparent this becomes. Smaller orgs can sometimes brush the ugly under the rug. Larger ones bump into issues constantly. I'd wager that 5% to 10% of engineering might be dealing with maintenance of dependencies.

(fwiw, I'm mostly speaking in terms of my experience as a backend engineer.)

That would not pass muster at all for me but I see it quite often and interestingly not in startups but bigger companies on departmental level (no code reviews there anyway...).

The whole brogrammer culture of "throw another library onto the fire" is the reason that simple programs require crazy amounts of computing power.

Similar case with babel and webpack, that each plugins (and loader) is a separate dependency. I don't know if it's more efficient or modular for development, but it is surely bloat the packages.

The unfortunate thing about CRA is that it's another tool on top of a tool to learn. It's not just instant and obvious, it has its own layer of configuration and understanding of how not to break it, how to upgrade it, etc. So people spend time learning the tool's tool instead of the tool.

I'm also not convinced this is "how the experts do it."

I think maybe I just struggle with the concept of being that hands-off with the tooling. I don't think I could cede control to some one-size-fits-all solution. For example, what happens when you run into some important library that doesn't tree shake or minify properly? What do people do? Do they just pick different libraries for the wrong reason? Do they just deploy an un-optimized application?

Not knowing how the stuff you depend on works feels really scary to me. Reminds me of the Star Trek TNG episode about "The Custodian" where the colony came to depend on a tool that nobody knew how to fix, so their lives were shaped by the tool's abilities, not the people's desires.

Until it breaks down leaving the project in an unmaintainable state, you're right. Then it's a scramble to understand and update that in my experience usually results in locking that dependency down to a strict version number and hoping that won't break anything else. It's great for security as pointed out in this thread /s. Not the optimal solution, but then again, they don't pay me enough/have enough staff for the optimal solution. And this is code that isn't even part of the app! Just shitty tools preventing me from even building the app. I can relate to the people complaining on here. This is with one or two dependencies too. Try solving those issues a few thousand times. You'll wish this horrific trend of front end code compilation would just stop. The problems truly never end as soon as one has to deal with npm and js dependencies. Which is not to say other languages don't have the same problems. They do, just not on this epic scale of shit.

  mkdir parceldemo
  cd parceldemo
  yarn init
  vi index.html 
  vi index.tsx
  npx parcel index.html

...and I have a working React app, with hot module reloading and TypeScript. Parcel installs TypeScript as a devdependency and react and react-dom as dependencies, and starts the HMR server. It took less than one minute.

Over time, though, the actual time to make any kind of change to the app became incredibly painful. The loss of the GWT DevMode plugin back around Firefox 27 hurt too.

We just finished rewriting that app with a modern React+Redux implementation, and I took great glee in deleting the entire GWT portion of that codebase. The changes have already paid off by letting us add some additional functionality that would have been a distinct pain to implement in the old codebase.

Sure, the fact that it was the second time through was a factor, but the iteration speed and codebase structure are truly both vastly improved over the original.

Another team has a SmartGWT app that they're planning to migrate in some fashion as well. Unfortunately, they locked themselves in badly by using SmartGWT's server-side black box that hooks into a DB to send data to the client. It's going to take them a while to start teasing that apart.

It's hard and boring work also.