Note that the listed discussion is specifically about projects generated by the Create-React-App tool, not React itself. React has always been usable by just adding a pair of `<script>` tags to any HTML page.
Dan Abramov pointed out [0] that:
> in terms of feature set (test runner, devserver, compiler with support for bundle splitting and optimizations, error overlay with editor integration, static code checker) it’s comparable to a small Xcode.
> It’s valid criticism that tools like Xcode are installed once whereas react-scripts is per project. But the upside is you never have the “different projects demand different Xcode versions” problem. And everything runs on CI thanks to full encapsulation.
> I’m hoping approaches like Yarn Plug’n’Play will give us best of both worlds. Shared install for the same versions between projects but with isolated and versioned tooling.
The bigger issue is less about weight (most of that doesn't end up in the final bundle anyway) and more about the fact that each of those dependencies is a point of possible a) breakage and b) security compromise. The latter in particular has been a rising issue with NPM's micro-packages trend.
I don't know how that problems is going away. Javascript doesn't have a great standard library and it's hard to impose restrictions on which packages/features/functionalities should be the "defacto" ones.
> I’m hoping approaches like Yarn Plug’n’Play will give us best of both worlds. Shared install for the same versions between projects but with isolated and versioned tooling.
TBH, I personally am not too concerned with the duplication/disk usage, but the number of dependencies it pulls is a pretty big one.
> Yes but good luck with React.createElement(). React without JSX is really a pain to use (or Preact, Inferno, etc).
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.
There's a number of options available if you don't want to use JSX.
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.
You know that jsx just compiles down to those calls right? Heck if all you need is just the transpile of jsx, typescript's compiler will do it just fine from the command line, no config to setup.
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.
Yep. I've glanced briefly at both PnP and Tink. Both sound neat conceptually, I just haven't dug far enough to know what the differences are in terms of actual approaches and implementation. Also haven't had a chance to play with either yet.
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].
Unfortunately, the ts compiler neither supports yarn pnp or rink right (and angular doesn't either). It's the biggest blocker for me personally - but I've played with yarn pnp and it's great.
A former boss of mine had a sign above his desk: “Transitive dependencies are the lifeblood of stuff. We don’t build stuff, we build software.”. While I am not a JS developer, I am distrustful of every dependency brought in and aggressively work to eliminate the only kind of useful ones. They’re debt brought into the code base and must be constantly evaluated for security concerns, interactions with other dependencies, and upcoming changes being incompatible with your code, which may in turn cause you to be unable to upgrade other dependencies.
Not having to write code is great, but when you bring something in it becomes code you must maintain for however long it is in your project. The utility calculus is variant for all projects and even different phases of the same project. But the calculation should be done often and ones that fall below the utility threshold should be removed.
One thing to note about create-react-app is that nearly all, in fact almost literally all, of those dependencies are development tools. They are also a pretty “normal” configuration of tools, based on standards rather than some custom framework.
This means that if you have a problem with create-react-app or it were to be abandoned, you could just get a different development tool and likely make zero changes to your actual code.
For sure, I'm not necessarily commenting on this particular example, as I'm unfamiliar with the tooling brought in by that command, and don't use JS myself. It's more of a comment about software dependencies in general. I'm usually much more tolerant of development dependencies than production dependencies.
And at what utility threshold should one ought to take a lib vs self-write?
Unless you're deeply experienced, it's a very hard judgement to make.
Plus the time spent investigating is not small either.
My rule of thumb is to take a lib if it's not you're core concern, and write your own if it is. You only have one core concern in a project, and that's what the customer pay for.
It's different based on each dependency and where you're at in the project lifecycle. If you're running as fast as you can to get off the runway before you crash, you have more of an incentive to bring it in and punt the problem down the road. But after that point passes it should be reevaluated. You should know every dependency in your code and why it's there.
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.
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.)
To thoroughly abuse the metaphor, you don't always want to go where the giant goes. Sometimes you would like to climb down and walk your own direction. Dependencies can take you near where you want to go, and if they can take you all the way there, terrific! Use them for as long as you can! But if you're not directing the giant, you're subject to its whims. And the more people standing on the giant's shoulders, yelling in its ears where they want it to go, the harder it is to make sure it's going where you want. At a certain point, this risk outweighs the rewards, and you adjust accordingly.
Ever look in your node_modules folder? I dislike the JS ecosystem for this very reason. It's so common to find dependency soup in any non-vanilla JS app.
Not in JS, but yes I do. Often. A useful exercise is trying to just bump everything one at a time and seeing where you can't.
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.
It's a little ridiculous to view this as a problem. I am currently working on a small personal project in my spare time with 775 dependencies. Quickly perusing the dependencies the reason there are so many is because I am using:
* Webpack
* Unit testing (Mocha)
* Code coverage (Istanbul)
* Browser transpilation (Babel)
* Type safety (typescript)
Now for an apples to apples comparison I used to work on c#/.net. Complaining about these dependencies would be akin to me complaining that I couldn't manually audit the unit testing dlls that VS is using to do code coverage for me. Of course, no one ever audits these DLLs. A more interesting analysis is to look at how many non-dev dependencies you have (I have none, I doubt this basic react package has more than just react for the production code).
Of course one could argue "someone might stop maintaining this project", but this is equivalent to saying "I won't use open source". In fact, in my experience the opposite is true, with closed source paid software becoming obsolete more regularly than open source alternatives. If a company decides something isn't making money they will usually can it while with open source at least someone has the opportunity of picking it up when an author loses interest.
Those 1,568 create-react-app dependencies are maintained by people you have no formal relationship to, and are all versioned independently. Visual Studio is one monolithic package released by one of the largest companies on earth. Microsoft is not going to back door you and it has a huge incentive to stop anyone else from directly back dooring you via Visual Studio. On the other hand, the maintainer of the event-stream NPM package, with ~1.5 million weekly downloads, recently gave control to a stranger. They successfully back doored it and evaded detection for over a month. https://blog.npmjs.org/post/180565383195/details-about-the-e...
Is that any less true for completely unrelated pieces of software on the same machine? If you have a nice secure monolithic .NET project on your machine, and you also ran a create-react-app project on the same machine, shouldn’t you be just as worried?
I think the "package count" is perhaps a bit of a red herring. IMHO the "publisher count" is more important.
I don't care if there are 700 packages if they all come from the Apache Foundation. I trust the Apache foundation and as such they can be considered one "block" when it comes to reviewing their chance of releasing a malicious/hacked package.
Visual studio is basically ONE package from ONE publisher Internally it's made up of thousands of tiny components, and includes third-party open source software such as Newtonsoft.JSON, but Microsoft is responsible for vetting all that stuff, and they do.
The problem with the JS ecosystem is that many of the packages come from all over the place. For example, create-react-app depends on envinfo which is published by "Trevor Brindle".
It also wants cross-spawn, from "André Cruz", chalk from "Josh Junon", Commander.js from "abe tomo", fs-extra from "JP Richardson", this list goes on and on.
Who are all these people and are they all trustworthy? I don't know, I can't tell, and neither does anyone else, which is the core problem.
Well with .net it's usually less than 10 of dlls (not counting .net framework itself, though it may have increased in several years). As opposed to npm, where webpack itself may need 3-5 packages (css loader, url loader, etc), not counting their dependencies.
But I'm not saying it's better or worse, just different. But for sure it's harder to audit.
I am (usually) not a JS dev, but we have quality standards which are, to some extend, regulated in my business (banking/payments), so to use this, I would not only want to, but to some extend need to understand all (ok, maybe not all, but at least the ones that seem to not be maintained very well or the ones that come from lone devs who might find another hobby and just quit maintaining) these 1568 dependencies and audit them for security every update. I would need to make sure they are maintained and if not decide if we will maintain them (if we are on a certain version of a NuGet package (we use .NET Core mostly) and the maintainer quits but somewhere in our stacks something depends on it, we have to make this decision, but we or the packages we use simply do not have that many dependencies). I do not want to dismiss other companies by saying 'apparently they don't care' but in the React/Node (JS) space in general, that feeling does creep up quite often when I read HN.
Though this submission is talking about development dependencies rather than runtime dependencies. For example, the scaffolding it generates builds a Javascript app that runs in the user's browser.
Still a potential problem, since each transitive dependency even gets to run arbitrary code during install on the developer's machine, but a different one.
Point taken, but then we get into the 'omg how is this development package installed on the prod machines?' ' Because it is convenient for finding issues'. I am sorry to say I know disturbingly many devs that run dev on prod because they can just continue devving on prod. That's not restricted to Node but I see it with RoR and .NET Core as well.
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 problem here is that any code run during development could generate code that ends up in production. Even if the dependency isn't used in production, there is a "compile step" (though it's technically transpiled) during which all sorts of mayhem could ensue.
I too work in this regulated business, and don't think your argument holds unless you don't inventory your dependencies and regularly scan code (source code and dependencies) for vulnerabilities
"JS developers keep reaching for huge JS packages. Just import small ones"
"JS developers install too many small packages."
Whooooooo cares. When you come up with the maximum arbitrary acceptable packages (including nested dependencies) for a project, and then also the arbitrary minimum LOC needed to publish a package (for all you leftpad haters), then throw your numbers in the toilet and stop talking.
I love that Babel, Prettier, Jest, etc use plugins as individual npm packages. I love the ecosystem it has created. I love that we have a big ecosystem that improves developer experience.
It looks like the left-pad incident has collectively taught us nothing and has had no lasting effects. One of the things that bothers me the most is over and over casually downloading 1568 independently controlled packages from a free-for-all repository (also privately owned and controlled, but that's a different discussion).
create-react-app is a complex tool put together by I team I largely trust. What I want on my machine is a static build of their work, not the whole sausage making factory in 1568 pieces. Once I would have the binaries, the whole of npm and the JavaScript ecosystem could go away altogether and I would still be able to build and deploy my apps.
The package, in its published form, would be vetted by the create-react-app, who have a much better idea of what's going on in their dependency tree than I do. If they decided they need that many dependencies, it is up to them to manage the complexity. That said, it would probably make their lives easier to depend on 10-20 packages, statically built by people they trust, and so on.
Even if the result of this would initially be very similar to today (still running the same code of those 1568 packages), it would make me trust this stack a lot more.
Exactly. Even if it had 10m loc and 10k dependencies, that’s not a problem at first sight.
In fact, the 1.5k dependencies in this example is a drop in the bucket when you consider all the dependencies that your react app needs to do anything useful (http, dns, tcp, ip, browsers, OS’s, et cetera).
I’m not defending React here, I don’t know enough about it, I’m just saying 1.5k dependencies for a hello world app might be bad, but it depends on the details.
And repeating as usual, it is caused by lack of standard library for js environment. All of things mentioned could've been packaged into 1-2 dependencies. But instead we need to independently add each one.
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.
For context, I'm a lead frontend dev in a company of a few hundred people.
Most people don't remotely know how Webpack works. And they shouldn't have to! Same for most other developer tools. You need a few people who can dig out issues if they arise, but most of your people will be concerned with actually building things on top of those tools.
When every team starts a new project from every few months to every few years, having a boilerplate setup quickly becomes very valuable. The added benefit that third-party boilerplate has is that you don't have to maintain the whole lot yourself.
Needless to say these upsides don't come without issues, security and accountability being the big elephants in the room, but popularity helps here, too. The boilerplate is used by a lot of people, in organizations both big and small. If an issue arises, you can usually collectively work out the problem very quickly. It doesn't make the issues go away, but it gives you a good balancing point.
As a tradeoff versus either setting up every project manually or maintaining your own boilerplate project, it's definitely worth consideration — it might not match your needs, but it's a strong option.
Thanks for sharing. I'm not going to be one of those, "well you should learn how it works" kind of people. If people make useful, maintainable products with these tools, great.
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.
> Most people don't remotely know how Webpack works. And they shouldn't have to!
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.
I agree that most of the reason to use CRA is to avoid needing to set up a complicated toolchain. However I've mostly stopped using it now in favour of Parcel. That gives you the zero-config of CRA without the weight. As a test, I just tried setting up an absolutely minimal React + TypeScript app. This is what I did:
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.
Because almost no-one in the office knows how to do anything without that tooling? I wish I was kidding. Not in my own company but I am integrating with a partner at the moment and any deviation from the create react app and subsequent tutorials that build on top of that is stopping them dead in their tracks. Things like 'JSX is some magic programming language with magic and more magic' is akin to, in my world, 'XAML is some magic language stuff that has nothing to do with C#!'. Obviously both are (trivial) transformations, but most 'break shit fast, break everything' crowd seems to not have grasps the absolute fundamentals of anything. But, to be honest, when it works, they do work at breakneck speed; the downside is that the result is on a 6-12 month throwaway (complete refactoring) cycle. Which is ok for many projects.
>Are there people who churn out apps so regularly that this tool has value?
Its the opposite. You create a new app so infrequently that its not worth learning how to do it yourself. Just run the tool once and its all set up and you can forget about it.
I used the vuejs equivalent and it set up everything in a usable way and I have been happily developing without having to change any of those configs set up for me.
First, it allows React learners to set up an environment without having to learn Webpack and Babel first. Prior to that, most tutorials would waste multiple pages on "Before you can do anything else, here's how to set up a Webpack+Babel config..."
Second, it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere). It also provides good defaults for build output, lints for common mistakes, and makes it really easy to get future build improvements just by updating a single `react-scripts` dependency.
Third, it also acts as a common starting point for instructions and tutorials. For example, I wrote a blog post a while back on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p... ), and I was able to start by just saying "Create a CRA project, eject, and modify these two config values".
I agree that create-react-app is bloated and overkill, but that's also a lot of the value in it, or at least it has been for me.
When I used CRA for a project about a year ago, it spit out a gigantic README with everything anyone ever might want to know about JS development, it had a long webpack configuration that hot-loaded CSS and auto-reloaded the page on JS edits, it set up the app to use a service worker, and it used a ton of other technologies and libraries and tools that I didn't know existed. They've scaled it back quite a bit since then, but I think getting a feel for what's out there is really valuable, and even though it has way more than you need, it's nice to be able to easily try those things to learn what they are and confirm that you don't need them. Otherwise, you might end up with a community of people who don't know about ESLint because none of the tutorials thought it was critical to set up before getting started.
One mindset (not necessarily for beginners) is that when working on a serious project that will need non-trivial config, it's best to run create-react-app, eject, carve away all of the unnecessary stuff that you don't want, then take ownership over every aspect of the build system and tooling. That leaves you with a much more solid starting point than if you start totally from scratch and only add things as you need them.
I think a great option is a collection of example configurations for a stack. When learning Webpack, 90% of my learning was by looking at other examples. The hardest part was making sure I wasn't looking at out of date examples.
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 it's handy for people who have never used a framework before to have all the tooling set up and available immediately. If I've never really worked on a JS project before, it's perverse to wade through docs of a bunch of orthogonal tools just so I can play about with the tool I set out to learn.
Even if you have worked with that framework before, odds are six months have passed since then and the framework has changed 50% of its best practices. Using a tool like this also avoids stale documentation/tutorials.
I frequently spin up empty repositories for bug reports/playgrounds/one-off ideas. It's an extremely valuable tool when you just want to get down to working on the code.
Readit News
Dan Abramov pointed out [0] that:
> in terms of feature set (test runner, devserver, compiler with support for bundle splitting and optimizations, error overlay with editor integration, static code checker) it’s comparable to a small Xcode.
> It’s valid criticism that tools like Xcode are installed once whereas react-scripts is per project. But the upside is you never have the “different projects demand different Xcode versions” problem. And everything runs on CI thanks to full encapsulation.
> I’m hoping approaches like Yarn Plug’n’Play will give us best of both worlds. Shared install for the same versions between projects but with isolated and versioned tooling.
[0] https://twitter.com/dan_abramov/status/1097309141075456000
TBH, I personally am not too concerned with the duplication/disk usage, but the number of dependencies it pulls is a pretty big one.
Yes but good luck with React.createElement(). React without JSX is really a pain to use (or Preact, Inferno, etc).
Vue is much more straightforward for those simpler cases where you don't need/want to setup Babel, Webpack, etc.
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.
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
https://reactjs.org/docs/add-react-to-a-website.html#quickly...
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.
[0]: https://blog.npmjs.org/post/178027064160/next-generation-pac...
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
Not having to write code is great, but when you bring something in it becomes code you must maintain for however long it is in your project. The utility calculus is variant for all projects and even different phases of the same project. But the calculation should be done often and ones that fall below the utility threshold should be removed.
This means that if you have a problem with create-react-app or it were to be abandoned, you could just get a different development tool and likely make zero changes to your actual code.
Unless you're deeply experienced, it's a very hard judgement to make.
Plus the time spent investigating is not small either.
My rule of thumb is to take a lib if it's not you're core concern, and write your own if it is. You only have one core concern in a project, and that's what the customer pay for.
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.
We can strive for sustainability and autonomy, but we're forever dependent on each other's work. As they say, it's turtles all the way down.
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.)
Ever look in your node_modules folder? I dislike the JS ecosystem for this very reason. It's so common to find dependency soup in any non-vanilla JS app.
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.
Deleted Comment
* Webpack
* Unit testing (Mocha)
* Code coverage (Istanbul)
* Browser transpilation (Babel)
* Type safety (typescript)
Now for an apples to apples comparison I used to work on c#/.net. Complaining about these dependencies would be akin to me complaining that I couldn't manually audit the unit testing dlls that VS is using to do code coverage for me. Of course, no one ever audits these DLLs. A more interesting analysis is to look at how many non-dev dependencies you have (I have none, I doubt this basic react package has more than just react for the production code).
Of course one could argue "someone might stop maintaining this project", but this is equivalent to saying "I won't use open source". In fact, in my experience the opposite is true, with closed source paid software becoming obsolete more regularly than open source alternatives. If a company decides something isn't making money they will usually can it while with open source at least someone has the opportunity of picking it up when an author loses interest.
Those 1,568 create-react-app dependencies are maintained by people you have no formal relationship to, and are all versioned independently. Visual Studio is one monolithic package released by one of the largest companies on earth. Microsoft is not going to back door you and it has a huge incentive to stop anyone else from directly back dooring you via Visual Studio. On the other hand, the maintainer of the event-stream NPM package, with ~1.5 million weekly downloads, recently gave control to a stranger. They successfully back doored it and evaded detection for over a month. https://blog.npmjs.org/post/180565383195/details-about-the-e...
I don't care if there are 700 packages if they all come from the Apache Foundation. I trust the Apache foundation and as such they can be considered one "block" when it comes to reviewing their chance of releasing a malicious/hacked package.
Visual studio is basically ONE package from ONE publisher Internally it's made up of thousands of tiny components, and includes third-party open source software such as Newtonsoft.JSON, but Microsoft is responsible for vetting all that stuff, and they do.
The problem with the JS ecosystem is that many of the packages come from all over the place. For example, create-react-app depends on envinfo which is published by "Trevor Brindle". It also wants cross-spawn, from "André Cruz", chalk from "Josh Junon", Commander.js from "abe tomo", fs-extra from "JP Richardson", this list goes on and on.
Who are all these people and are they all trustworthy? I don't know, I can't tell, and neither does anyone else, which is the core problem.
But I'm not saying it's better or worse, just different. But for sure it's harder to audit.
Still a potential problem, since each transitive dependency even gets to run arbitrary code during install on the developer's machine, but a different one.
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...).
You could for example use React with TypeScript and have far, far fewer dependencies...
"JS developers install too many small packages."
Whooooooo cares. When you come up with the maximum arbitrary acceptable packages (including nested dependencies) for a project, and then also the arbitrary minimum LOC needed to publish a package (for all you leftpad haters), then throw your numbers in the toilet and stop talking.
I love that Babel, Prettier, Jest, etc use plugins as individual npm packages. I love the ecosystem it has created. I love that we have a big ecosystem that improves developer experience.
I ask because your reaction goes against everything I've ever felt, and I sincerely want to understand.
https://www.youtube.com/watch?v=1K5SycZjGhI
create-react-app is a complex tool put together by I team I largely trust. What I want on my machine is a static build of their work, not the whole sausage making factory in 1568 pieces. Once I would have the binaries, the whole of npm and the JavaScript ecosystem could go away altogether and I would still be able to build and deploy my apps.
The package, in its published form, would be vetted by the create-react-app, who have a much better idea of what's going on in their dependency tree than I do. If they decided they need that many dependencies, it is up to them to manage the complexity. That said, it would probably make their lives easier to depend on 10-20 packages, statically built by people they trust, and so on.
Even if the result of this would initially be very similar to today (still running the same code of those 1568 packages), it would make me trust this stack a lot more.
It's not surprising or concerning.
That's what it takes to get modern things built - lots of other things.
In fact, the 1.5k dependencies in this example is a drop in the bucket when you consider all the dependencies that your react app needs to do anything useful (http, dns, tcp, ip, browsers, OS’s, et cetera).
I’m not defending React here, I don’t know enough about it, I’m just saying 1.5k dependencies for a hello world app might be bad, but it depends on the details.
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 whole brogrammer culture of "throw another library onto the fire" is the reason that simple programs require crazy amounts of computing power.
I tried it and in order to satisfy everyone's needs it seems like overkill tooling for most needs.
Most people don't remotely know how Webpack works. And they shouldn't have to! Same for most other developer tools. You need a few people who can dig out issues if they arise, but most of your people will be concerned with actually building things on top of those tools.
When every team starts a new project from every few months to every few years, having a boilerplate setup quickly becomes very valuable. The added benefit that third-party boilerplate has is that you don't have to maintain the whole lot yourself.
Needless to say these upsides don't come without issues, security and accountability being the big elephants in the room, but popularity helps here, too. The boilerplate is used by a lot of people, in organizations both big and small. If an issue arises, you can usually collectively work out the problem very quickly. It doesn't make the issues go away, but it gives you a good balancing point.
As a tradeoff versus either setting up every project manually or maintaining your own boilerplate project, it's definitely worth consideration — it might not match your needs, but it's a strong option.
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.
...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.
Its the opposite. You create a new app so infrequently that its not worth learning how to do it yourself. Just run the tool once and its all set up and you can forget about it.
I used the vuejs equivalent and it set up everything in a usable way and I have been happily developing without having to change any of those configs set up for me.
First, it allows React learners to set up an environment without having to learn Webpack and Babel first. Prior to that, most tutorials would waste multiple pages on "Before you can do anything else, here's how to set up a Webpack+Babel config..."
Second, it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere). It also provides good defaults for build output, lints for common mistakes, and makes it really easy to get future build improvements just by updating a single `react-scripts` dependency.
Third, it also acts as a common starting point for instructions and tutorials. For example, I wrote a blog post a while back on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p... ), and I was able to start by just saying "Create a CRA project, eject, and modify these two config values".
When I used CRA for a project about a year ago, it spit out a gigantic README with everything anyone ever might want to know about JS development, it had a long webpack configuration that hot-loaded CSS and auto-reloaded the page on JS edits, it set up the app to use a service worker, and it used a ton of other technologies and libraries and tools that I didn't know existed. They've scaled it back quite a bit since then, but I think getting a feel for what's out there is really valuable, and even though it has way more than you need, it's nice to be able to easily try those things to learn what they are and confirm that you don't need them. Otherwise, you might end up with a community of people who don't know about ESLint because none of the tutorials thought it was critical to set up before getting started.
One mindset (not necessarily for beginners) is that when working on a serious project that will need non-trivial config, it's best to run create-react-app, eject, carve away all of the unnecessary stuff that you don't want, then take ownership over every aspect of the build system and tooling. That leaves you with a much more solid starting point than if you start totally from scratch and only add things as you need them.
Even if you do stuff by hand you can run CRA and see how the experts do it.
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."
Deleted Comment