10 ms·

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

276 points by _0nac 8y ago

acemarke 8y ago
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. [0] https://twitter.com/dan_abramov/status/1097309141075456000 https://twitter.com/dan_abramov/status/1097309141075456000
- sisk 8y ago
  In addition to Yarn PnP, the folks at npm are still working on tink[0] which is early but useable right now. [0]: https://blog.npmjs.org/post/178027064160/next-generation-package-management https://blog.npmjs.org/post/178027064160/next-generation-pac...
  - acemarke 8y ago
    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]. [0] https://twitter.com/acemarke/status/1073593305378754560 https://twitter.com/acemarke/status/1073593305378754560
  - swsieber 8y ago
    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.
- pier25 8y ago
  > React has always been usable by just adding a pair of `<script>` tags to any HTML page. 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.
  - acemarke 8y ago
    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. [0] https://github.com/jador/react-hyperscript-helpers https://github.com/jador/react-hyperscript-helpers [1] https://github.com/developit/htm https://github.com/developit/htm
    - pdimitar 8y ago
      Sure, but your claim of "you just need a pair of <script> tags" is no longer true then, is it? I can start building a house with a hammer and a shovel. Doesn't mean I can build the entire house with them alone.
      - acemarke 8y ago
        My claim of "you only need two script tags to write a working React app" is entirely accurate. That _does_ limit you to just `React.createElement()`, which is the core React API. If you don't want to call `React.createElement()` every time (whether or not you alias to to something like `h()`), then you either use JSX (and a build step), or one of the other options like the ones I listed. Pointing at that, and then claiming it's insufficient for "building an entire house", makes it look like there's some goalposts being shoved down the field.
        pdimitar 8y ago
- hdra 8y ago
  > 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.
- _bxg1 8y ago
  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.
  - arvinsim 8y ago
    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.
    - _bxg1 8y ago
      The strength of JavaScript is also the problem: it's really easy to create and distribute really flexible and dynamic code. This encourages a massive, vibrant ecosystem of packages which are extremely modular and flexible, and often tiny. So you end up building sandcastles out of thousands of grains of sand instead of LEGO houses. What we probably need to do is walk that back a bit at a cultural level, and make our libraries just a bit more cohesive and self-contained. There are a few libraries like Lodash and Ramada that aim to be general-purpose toolkits, and Vue and Angular are good examples of reactive libraries that come with their own state management, plus some other stuff. Of course, the latter probably (I'm not actually positive) carry their own big lists of npm dependencies.
      - _bxg1 8y ago
        And for a tooling example, VSCode is basically a much more cohesive and holistically-designed version of Atom.
- ratdiary 8y ago
  Sounds like a job for Blazor! https://blazor.net/ https://blazor.net/
jarym 8y ago
... I continue to use smartclient.com for my front end work. It continues to kick everything from a productivity perspective and the framework is fantastic (for business-y apps). People used to tell me it was too heavy weight. People used to tell me jQuery or Angular were better. No external dependencies. NPM not needed. Might be a bit old in some places but so what.
- padseeker 8y ago
  It may be great for you. But it will not go well when someone else needs to support it. It might be old? GWT? Just go back to developing Web 1.0 applications and see how that goes. GWT is antiquated. I realize the churn associated with front end can be maddening, and you don't always need a Single Page App, but from a usability perspective you are really behind the times.
  - acemarke 8y ago
    My first actual web app I ever built was with GWT + SmartGWT, back in 2011-12. The decision made sense at the time, because I didn't have any JS experience, and the JS ecosystem wasn't nearly as mature at the time. 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.
    - isostatic 8y ago
      It amazes me how many people suggest that $2015_technology is behind the times, on a site that - aside from a javascript voting button - would happily exist in 1995.
_asummers 8y ago
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.
- chii 8y ago
  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.
  - _asummers 8y ago
    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.
andrewstuart 8y ago
Yes but it does alot of stuff. It's not surprising or concerning. That's what it takes to get modern things built - lots of other things.
- zinckiwi 8y ago
  Agreed. Why reinvent a wheel that's there for the using, when you could be working on the aspects of your project that make it your project?
  - reaperducer 8y ago
    Because the scope of a project should include usability, speed, resource thrift, maintainability, and security. The whole brogrammer culture of "throw another library onto the fire" is the reason that simple programs require crazy amounts of computing power.
    - andrewstuart 8y ago
      Unless you are doing assembly language programming at a clean screen then you are building software that sits on the shoulders of other software. It's not just JavaScript that has dependencies - everything does.
      - snazz 8y ago
        You make a very valid point, but compared to other programming languages and cultures, the JavaScript ecosystem encourages mammoth projects with many more dependencies than they need. It’s not the concept of dependencies that’s at fault, it’s the number of them proportional to the task.
      - PavlovsCat 8y ago
        > Unless you are doing assembly language programming at a clean screen then you are building software that sits on the shoulders of other software. Yet, we don't just eat dirt off the street because even when we eat the usual food, there's always some dirt in it.
aboutruby 8y ago
So, only needs a 0.06% chance of a package having compromised code (e.g. bitcoin stealer, ssh/pgp keys stealer, keylogger, mitm, etc etc.)
- jstewartmobile 8y ago
  Apparently, the trade thinks its 1970s-style orgy-bathhouse is fine just like it is--thank you very much.
Waterluvian 8y ago
I don't exactly understand the point of create react app. Are there people who churn out apps so regularly that this tool has value? I tried it and in order to satisfy everyone's needs it seems like overkill tooling for most needs.
- 0xADEADBEE 8y ago
  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.
  - DCoder 8y ago
    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.
- tluyben2 8y ago
  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.
- acemarke 8y ago
  CRA serves three primary purposes. 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-part-1-cesium-webpack/ 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".
linkmotif 8y ago
I just don’t see how this matters. Looking at it this way is just not interesting. This is the whole point of dependency management: making dependencies so easy that this sort of thing happens. One must ask: what’s the dependency graph for the complete build, after tree shaking etc. it’s definitely not thousands of modules. And if so—so what?? That’s the whole point!! The real issue is security, but that’s another issue. It’s remarkable you can just push code to npm without signing it. Every time I push a commit to GitHub and then release it on npm it really gives me the creeps. Fortunately we have CSPs.
- gary_bernhardt 8y ago
  You acknowledge security as "the real issue" in your comment. I don't know how to square that with the first sentence in your comment, "I just don't see how this matters." It matters because of security, like you said.
  - linkmotif 8y ago
    Install a CSP and you’re done? (assuming we’re talking about front end code)
    - gary_bernhardt 8y ago
      That's not the kind of security problem we're talking about here. https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident https://blog.npmjs.org/post/180565383195/details-about-the-e...
      - linkmotif 8y ago
        Huh? This is an issue affecting backend JS. We are discussing front end applications.
        gary_bernhardt 8y ago
        There's nothing special about "backend". It's normal for the client side bundle to contain many dependencies that came from NPM.
tluyben2 8y ago
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.
- hombre_fatal 8y ago
  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.
  - tluyben2 8y ago
    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...).
  - marcus_holmes 8y ago
    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.
jstewartmobile 8y ago
When you look at what a mess the web is as a platform, 1,568 dependencies is a modest amount of asphalt to fill as many potholes as it does. In JavaScript land, you need an external dependency for freaking left-pad[0]. In freer countries, that cutting-edge 1970s technology[1] is built-in. [0] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [1] https://stackoverflow.com/questions/293438/left-pad-printf-with-spaces https://stackoverflow.com/questions/293438/left-pad-printf-w...
- crooked-v 8y ago
  I agree. There's an effort to get at least a standard library namespace, but it's at month 8 of just deciding on the semantics of how to import: https://github.com/tc39/proposal-javascript-standard-library https://github.com/tc39/proposal-javascript-standard-library
  - tasubotadas 8y ago
    Oh, God. Finally, they have at least started talking about stdlib. It's bizarre how a modern language could exist without a standard lib.
jxcole 8y ago
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.
- fendy3002 8y ago
  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.
- gary_bernhardt 8y ago
  Dev dependencies are as dangerous as production dependencies and always have been. Read this from 1984: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7... 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-event-stream-incident https://blog.npmjs.org/post/180565383195/details-about-the-e...
stevebmark 8y ago
"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.
- peteforde 8y ago
  Genuinely curious: how long have you been developing web apps, and what stacks/platforms did you work with previously? 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 https://www.youtube.com/watch?v=1K5SycZjGhI
  - stackola 8y ago
    I've been working in web dev since 2008 and have never been happier with the ecosystem or more productive.
    - peteforde 8y ago
      Cool. Still excited to hear from @stevebmark! When you started in 2008, were you self-taught, college/university or bootcamp? No wrong answers. Have you been working primarily in JS the whole time? Did you do front-end, back-end or some blend of the two?
Scooty 8y ago
I don't really understand how headlines like this are helpful. Is there an ideal number of dependencies? How do we decide that 1568 is too high? Is it better or worse than 156 dependencies that each have 10x the LOC? How should the CRA devs address the bad big number? Rewrite all their dependencies from scratch and bundle them with CRA? Instead of guilting developers for their dependency count, maybe we should be auditing open source project dependencies or suggesting better tips for vetting dependencies.
- xg15 8y ago
  > Is there an ideal number of dependencies Maybe we could at least argue about the number of digits?
xiphias2 8y ago
The solution would be a node standard library project that contains the slowly moving parts of the 1500 dependencies, which means that it doesn't need too much maintainence. I don't understand why the companies that depend on webpack haven't built a project like this yet (and made sure that the important projects use that library), but I believe it's just a matter of time.
- baddox 8y ago
  That’s a great way to have even more competing libraries. https://xkcd.com/927/ https://xkcd.com/927/
  - xiphias2 8y ago
    Where are those 15 efforts? I don't see any effort to take a hard look at combining the most used few hundred libraries into a collection of a few libraries. It's hard and boring work also.
    - baddox 8y ago
      Underscore and Lodash are obvious examples. I don't know if the project maintainers' stated purpose is specifically that, but they are clearly creating big libraries of common utilities. And, surprise surprise, two extremely common problems with frontend NPM projects are: 1) unintentionally importing the entire library instead of the few functions you use, and 2) having many different versions of the libraries in your output bundle because of other dependencies. Hence things like this exist: https://www.npmjs.com/package/babel-plugin-lodash https://www.npmjs.com/package/babel-plugin-lodash https://www.npmjs.com/package/lodash-webpack-plugin https://www.npmjs.com/package/lodash-webpack-plugin
bayesian_horse 8y ago
Javascript dependencies grow on you, quickly...
lab 8y ago
Cool beans!
EslintMustBurn 8y ago
This is entirely the fault of Babel, everything that led up to Babel, and Ruby on Rails for forcing transpilers on the world. Pyramids of doom aren't a problem, promises eat 30% of the CPU, OO training has made us lazy and stupid, and now, hello world React apps are 1.1M lines of code. Thanks, transpilers.
- rymate1234 8y ago
  ESLint isn't a transpiler, it's a linter It checks code formatting, it doesn't enforce a transpiler
tasubotadas 8y ago
Nice.
tga 8y ago
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.
pictur 8y ago
I don't think this will be a sustainable ecosystem. The software is even built on fast consumption now.
smackfu 8y ago
You can’t say “it is good design to have small composable building blocks” and then complain about the number of those blocks.

276 points by _0nac 8y ago

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. [0] https://twitter.com/dan_abramov/status/1097309141075456000 https://twitter.com/dan_abramov/status/1097309141075456000

sisk 8y ago
In addition to Yarn PnP, the folks at npm are still working on tink[0] which is early but useable right now. [0]: https://blog.npmjs.org/post/178027064160/next-generation-package-management https://blog.npmjs.org/post/178027064160/next-generation-pac...
- acemarke 8y ago
  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]. [0] https://twitter.com/acemarke/status/1073593305378754560 https://twitter.com/acemarke/status/1073593305378754560
- swsieber 8y ago
  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.
pier25 8y ago
> React has always been usable by just adding a pair of `<script>` tags to any HTML page. 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.
- acemarke 8y ago
  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. [0] https://github.com/jador/react-hyperscript-helpers https://github.com/jador/react-hyperscript-helpers [1] https://github.com/developit/htm https://github.com/developit/htm
  - pdimitar 8y ago
    Sure, but your claim of "you just need a pair of <script> tags" is no longer true then, is it? I can start building a house with a hammer and a shovel. Doesn't mean I can build the entire house with them alone.
    - acemarke 8y ago
      My claim of "you only need two script tags to write a working React app" is entirely accurate. That _does_ limit you to just `React.createElement()`, which is the core React API. If you don't want to call `React.createElement()` every time (whether or not you alias to to something like `h()`), then you either use JSX (and a build step), or one of the other options like the ones I listed. Pointing at that, and then claiming it's insufficient for "building an entire house", makes it look like there's some goalposts being shoved down the field.
      - pdimitar 8y ago
hdra 8y ago
> 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.
_bxg1 8y ago
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.
- arvinsim 8y ago
  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.
  - _bxg1 8y ago
    The strength of JavaScript is also the problem: it's really easy to create and distribute really flexible and dynamic code. This encourages a massive, vibrant ecosystem of packages which are extremely modular and flexible, and often tiny. So you end up building sandcastles out of thousands of grains of sand instead of LEGO houses. What we probably need to do is walk that back a bit at a cultural level, and make our libraries just a bit more cohesive and self-contained. There are a few libraries like Lodash and Ramada that aim to be general-purpose toolkits, and Vue and Angular are good examples of reactive libraries that come with their own state management, plus some other stuff. Of course, the latter probably (I'm not actually positive) carry their own big lists of npm dependencies.
    - _bxg1 8y ago
      And for a tooling example, VSCode is basically a much more cohesive and holistically-designed version of Atom.
ratdiary 8y ago
Sounds like a job for Blazor! https://blazor.net/ https://blazor.net/

jarym 8y ago

... I continue to use smartclient.com for my front end work. It continues to kick everything from a productivity perspective and the framework is fantastic (for business-y apps). People used to tell me it was too heavy weight. People used to tell me jQuery or Angular were better. No external dependencies. NPM not needed. Might be a bit old in some places but so what.

padseeker 8y ago
It may be great for you. But it will not go well when someone else needs to support it. It might be old? GWT? Just go back to developing Web 1.0 applications and see how that goes. GWT is antiquated. I realize the churn associated with front end can be maddening, and you don't always need a Single Page App, but from a usability perspective you are really behind the times.
- acemarke 8y ago
  My first actual web app I ever built was with GWT + SmartGWT, back in 2011-12. The decision made sense at the time, because I didn't have any JS experience, and the JS ecosystem wasn't nearly as mature at the time. 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.
  - isostatic 8y ago
    It amazes me how many people suggest that $2015_technology is behind the times, on a site that - aside from a javascript voting button - would happily exist in 1995.

_asummers 8y ago

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.

chii 8y ago
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.
- _asummers 8y ago
  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.

andrewstuart 8y ago

Yes but it does alot of stuff. It's not surprising or concerning. That's what it takes to get modern things built - lots of other things.

zinckiwi 8y ago
Agreed. Why reinvent a wheel that's there for the using, when you could be working on the aspects of your project that make it your project?
- reaperducer 8y ago
  Because the scope of a project should include usability, speed, resource thrift, maintainability, and security. The whole brogrammer culture of "throw another library onto the fire" is the reason that simple programs require crazy amounts of computing power.
  - andrewstuart 8y ago
    Unless you are doing assembly language programming at a clean screen then you are building software that sits on the shoulders of other software. It's not just JavaScript that has dependencies - everything does.
    - snazz 8y ago
      You make a very valid point, but compared to other programming languages and cultures, the JavaScript ecosystem encourages mammoth projects with many more dependencies than they need. It’s not the concept of dependencies that’s at fault, it’s the number of them proportional to the task.
    - PavlovsCat 8y ago
      > Unless you are doing assembly language programming at a clean screen then you are building software that sits on the shoulders of other software. Yet, we don't just eat dirt off the street because even when we eat the usual food, there's always some dirt in it.

aboutruby 8y ago

So, only needs a 0.06% chance of a package having compromised code (e.g. bitcoin stealer, ssh/pgp keys stealer, keylogger, mitm, etc etc.)

jstewartmobile 8y ago
Apparently, the trade thinks its 1970s-style orgy-bathhouse is fine just like it is--thank you very much.

Waterluvian 8y ago

I don't exactly understand the point of create react app. Are there people who churn out apps so regularly that this tool has value? I tried it and in order to satisfy everyone's needs it seems like overkill tooling for most needs.

0xADEADBEE 8y ago
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.
- DCoder 8y ago
  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.
tluyben2 8y ago
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.
acemarke 8y ago
CRA serves three primary purposes. 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-part-1-cesium-webpack/ 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".

linkmotif 8y ago

I just don’t see how this matters. Looking at it this way is just not interesting. This is the whole point of dependency management: making dependencies so easy that this sort of thing happens. One must ask: what’s the dependency graph for the complete build, after tree shaking etc. it’s definitely not thousands of modules. And if so—so what?? That’s the whole point!! The real issue is security, but that’s another issue. It’s remarkable you can just push code to npm without signing it. Every time I push a commit to GitHub and then release it on npm it really gives me the creeps. Fortunately we have CSPs.

gary_bernhardt 8y ago
You acknowledge security as "the real issue" in your comment. I don't know how to square that with the first sentence in your comment, "I just don't see how this matters." It matters because of security, like you said.
- linkmotif 8y ago
  Install a CSP and you’re done? (assuming we’re talking about front end code)
  - gary_bernhardt 8y ago
    That's not the kind of security problem we're talking about here. https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident https://blog.npmjs.org/post/180565383195/details-about-the-e...
    - linkmotif 8y ago
      Huh? This is an issue affecting backend JS. We are discussing front end applications.
      - gary_bernhardt 8y ago
        There's nothing special about "backend". It's normal for the client side bundle to contain many dependencies that came from NPM.

tluyben2 8y ago

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.

hombre_fatal 8y ago
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.
- tluyben2 8y ago
  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...).
- marcus_holmes 8y ago
  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.

jstewartmobile 8y ago

When you look at what a mess the web is as a platform, 1,568 dependencies is a modest amount of asphalt to fill as many potholes as it does. In JavaScript land, you need an external dependency for freaking left-pad[0]. In freer countries, that cutting-edge 1970s technology[1] is built-in. [0] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [1] https://stackoverflow.com/questions/293438/left-pad-printf-with-spaces https://stackoverflow.com/questions/293438/left-pad-printf-w...

crooked-v 8y ago
I agree. There's an effort to get at least a standard library namespace, but it's at month 8 of just deciding on the semantics of how to import: https://github.com/tc39/proposal-javascript-standard-library https://github.com/tc39/proposal-javascript-standard-library
- tasubotadas 8y ago
  Oh, God. Finally, they have at least started talking about stdlib. It's bizarre how a modern language could exist without a standard lib.

jxcole 8y ago

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.

fendy3002 8y ago
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.
gary_bernhardt 8y ago
Dev dependencies are as dangerous as production dependencies and always have been. Read this from 1984: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7... 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-event-stream-incident https://blog.npmjs.org/post/180565383195/details-about-the-e...

stevebmark 8y ago

"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.

peteforde 8y ago
Genuinely curious: how long have you been developing web apps, and what stacks/platforms did you work with previously? 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 https://www.youtube.com/watch?v=1K5SycZjGhI
- stackola 8y ago
  I've been working in web dev since 2008 and have never been happier with the ecosystem or more productive.
  - peteforde 8y ago
    Cool. Still excited to hear from @stevebmark! When you started in 2008, were you self-taught, college/university or bootcamp? No wrong answers. Have you been working primarily in JS the whole time? Did you do front-end, back-end or some blend of the two?

Scooty 8y ago

I don't really understand how headlines like this are helpful. Is there an ideal number of dependencies? How do we decide that 1568 is too high? Is it better or worse than 156 dependencies that each have 10x the LOC? How should the CRA devs address the bad big number? Rewrite all their dependencies from scratch and bundle them with CRA? Instead of guilting developers for their dependency count, maybe we should be auditing open source project dependencies or suggesting better tips for vetting dependencies.

xg15 8y ago
> Is there an ideal number of dependencies Maybe we could at least argue about the number of digits?

xiphias2 8y ago

The solution would be a node standard library project that contains the slowly moving parts of the 1500 dependencies, which means that it doesn't need too much maintainence. I don't understand why the companies that depend on webpack haven't built a project like this yet (and made sure that the important projects use that library), but I believe it's just a matter of time.

baddox 8y ago
That’s a great way to have even more competing libraries. https://xkcd.com/927/ https://xkcd.com/927/
- xiphias2 8y ago
  Where are those 15 efforts? I don't see any effort to take a hard look at combining the most used few hundred libraries into a collection of a few libraries. It's hard and boring work also.
  - baddox 8y ago
    Underscore and Lodash are obvious examples. I don't know if the project maintainers' stated purpose is specifically that, but they are clearly creating big libraries of common utilities. And, surprise surprise, two extremely common problems with frontend NPM projects are: 1) unintentionally importing the entire library instead of the few functions you use, and 2) having many different versions of the libraries in your output bundle because of other dependencies. Hence things like this exist: https://www.npmjs.com/package/babel-plugin-lodash https://www.npmjs.com/package/babel-plugin-lodash https://www.npmjs.com/package/lodash-webpack-plugin https://www.npmjs.com/package/lodash-webpack-plugin

bayesian_horse 8y ago

Javascript dependencies grow on you, quickly...

lab 8y ago

Cool beans!

EslintMustBurn 8y ago

This is entirely the fault of Babel, everything that led up to Babel, and Ruby on Rails for forcing transpilers on the world. Pyramids of doom aren't a problem, promises eat 30% of the CPU, OO training has made us lazy and stupid, and now, hello world React apps are 1.1M lines of code. Thanks, transpilers.

rymate1234 8y ago
ESLint isn't a transpiler, it's a linter It checks code formatting, it doesn't enforce a transpiler

tasubotadas 8y ago

Nice.

tga 8y ago

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.

pictur 8y ago

I don't think this will be a sustainable ecosystem. The software is even built on fast consumption now.

smackfu 8y ago

You can’t say “it is good design to have small composable building blocks” and then complain about the number of those blocks.