18 ms·

React Native scares me with its dependency webs: http://npm.anvaka.com/#/view/2d/react-native http://npm.anvaka.com/#/view/2d/react-native From my experience,

by wyc 6y ago

React Native scares me with its dependency webs: http://npm.anvaka.com/#/view/2d/react-native http://npm.anvaka.com/#/view/2d/react-native From my experience, it's really great to work with and definitely saves a ton of work, but the depgraph above fills me with doubt for use in sensitive applications such as in finance or healthcare. For this reason, I've been trying out Flutter or even considering to go back to native apps. Perhaps there's some kind of middle ground where we can create a tight microkernel-like thing natively using secure enclaves and key managers, but expose an API to the "untrusted" parts of the program. This approach is not without its own downsides, such as dark patterns in a compromised UI. However, as one friend pointed out, a lot of those deps are indeed for build time only, which have different risk profiles. The depgraph of reactjs is far simpler and easier for me to understand and therefore feel trust: http://npm.anvaka.com/#/view/2d/react http://npm.anvaka.com/#/view/2d/react Does anyone know if there has been reliable research towards the security of the entire RN dependency tree? Seeing a stray dep there that has 1 maintainer on npm/GitHub who has been inactive for over a year makes me nervous. Any one of those JavaScript projects could do something nefarious deep under the hood, and this to me seems to expose a huge surface area for attackers. Here's a classic throwback to keep us on our toes :) https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

peterhunt 6y ago
Wow, that React Native dep graph is crazy! But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies. While react-native does have more dependencies than vanilla react, on first glance the list doesn't seem too crazy https://github.com/facebook/react-native/blob/master/package.json#L87 https://github.com/facebook/react-native/blob/master/package...
- filleduchaos 6y ago
  The package.json file hasn't been remotely close to representative of the actual dependency count of a JS project for years.
  - peterhunt 6y ago
    sure, but it gives you the list of packages to look at in the dependency visualizer
    - filleduchaos 6y ago
      It gives you a list of directly depended-upon packages. It doesn't give you a list of _those_ packages' dependencies, or _their_ dependencies, which funnily enough also get installed when you install your direct dependencies. Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't. So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.
      - andrewingram 6y ago
        Your last paragraph is a bit inaccurate. The dependencies are needed by people developing WITH React Native as opposed to devDependencies (which are for people developing ON React Native). So whilst you will be using the complicated graph of dependencies at some point, that isn't the same as saying they'll be shipped to end users of the app. The line between dependencies and devDependencies got blurry the second npm packages got used for more than just Node.js itself. What's really needed to remove the ambiguity is something like prodDependencies, which would be a subset of the current dependencies, but I don't know if it's really worth it.
        haskman 6y ago
        Can you clarify the difference between developing "with" vs "on" react-native?
        6y ago
- bigiain 6y ago
  Am I the only one who just spent 5 minutes chasing moving nodes round in that graph looking for leftpad.js?
  - searchableguy 6y ago
    Definitely not.
  - captivechains 6y ago
    it's in there, somewhere.. https://github.com/microsoft/react-native-windows/blob/master/yarn.lock#L8737 https://github.com/microsoft/react-native-windows/blob/maste...
  - ci5er 6y ago
    Why don't people copy the deb-tree to their local repo and/or pin the version that they want, so that they can be free of node terrorists? EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?
    - mlvljr 6y ago
      "if your a dad, yes, doh!"
    - nicoburns 6y ago
      This makes sense if you're releasing versioned software builds to 3rd parties. If you're running it internally (e.g. as a SaaS company) then there's much less cause to run an old versions, let alone one from 20 years ago.
      - ci5er 6y ago
        Yeah. I get that. Getting enterprise people to migrate or go off-prem for everything takes some time. And some like custom versons! I just like to snap-shot everything (including the tool chain) so that I can recreate the past out of my repository at any time for any reason. (I'm weird like that - I expect the same out of legal, ops and accounting as well) Maybe I'm old - but I don't trust Quickbooks-in-the-Cloud. EDIT: But I use 'em!
- tomphoolery 6y ago
  The longer you leave that dependency graph up, the more it starts to look like the Huddle from Inside...
- deleted 6y ago
  [deleted]
AaronFriel 6y ago
Speaking of trusting trust, I think I'd love for Node¹ to support something like OpenBSD pledge (2) and unveil (2) for imports, where once you enter into a particular package certain capabilities are disabled. I would like to be able to assert that when I import some package, it and all of the packages it recursively includes do not perform network requests, do not use the filesystem outside of some folder, and so on. A fine grained capability system for packages would dramatically improve the safety profile, and if this were built into package.json and the lockfile we could do the following: 1. Packages advertise what their default capabilities should be limited to 2. Changes in those capabilities are encoded in the package lock file, and can't be changed without the user explicitly affirming them ¹ and other langs with extensive use of package managers and micro-packages
- pier25 6y ago
  > A fine grained capability system for packages would dramatically improve the safety profile I think Deno does that (the new project by Node's original creator): https://blog.logrocket.com/what-is-deno/ https://blog.logrocket.com/what-is-deno/
  - mthoms 6y ago
    Woohoo! I just noticed Deno is at release candidate stage for v1.0.
  - jakear 6y ago
    Deno gives all packages the same permissions of the main app. So if your app can make network requests, so can every dependency you use. It’s not a great situation. I’ve brought this up to them and their response is that per-package permissions would be too difficult to implement.
    - vijaybritto 6y ago
      Yes, checking everyone at the main door is indeed easier than checking everyone at every single point of contact. It needs a vast architectural change compared to current implementation as you need to enforce those rules at runtime!
holler 6y ago
wtf! that's insane! now I'm curious to look up other oss projects I use :)
- sky_rw 6y ago
  It's turtles all the way down.
captainmuon 6y ago
I wonder why there is no effort towards reducing the dependencies, or at least vendoring the worst offenders. It would be a huge quality-of-life improvement for React developers, not to mention the improved security and reliability.
- scarlac 6y ago
  There are. A lot of components have been deprecated and are being moved out into community-maintained versions. Some major examples are: Camera library, Photo Library integrations, Date/Time picker, AsyncStorage, and more. This is a large scale effort from the dev team to decrease core size: https://github.com/facebook/react-native/issues/23313 https://github.com/facebook/react-native/issues/23313
Tade0 6y ago
I believe this is something that next-gen frameworks worked around: http://npm.anvaka.com/#/view/2d/svelte http://npm.anvaka.com/#/view/2d/svelte http://npm.anvaka.com/#/view/2d/solid-js http://npm.anvaka.com/#/view/2d/solid-js
- kiliancs 6y ago
  React doesn't suffer from this. It's React Native.
  - notJim 6y ago
    Interesting, you are right AFAICT (react has numerous packages and I'm not totally sure how they relate). http://npm.anvaka.com/#/view/2d/react http://npm.anvaka.com/#/view/2d/react http://npm.anvaka.com/#/view/2d/react-dom http://npm.anvaka.com/#/view/2d/react-dom
  - ricardobeat 6y ago
    In theory, that is. Since it doesn't include batteries, the controller, the wheels, or the antenna you're gonna end up bringing a ton of dependencies yourself to cover the missing parts (animation, state management, routing etc). Plus you're not seeing the dev dependencies, a more apt comparison would be to create-react-app.
    - Silhouette 6y ago
      Since it doesn't include batteries, the controller, the wheels, or the antenna you're gonna end up bringing a ton of dependencies yourself to cover the missing parts (animation, state management, routing etc). Or not. I've worked on plenty of applications that had few if any dependencies for those things. I'm sure many others have too. In some cases that was because we didn't need that particular functionality. Routing has little value if you're building an in-house SPA that always starts from the same dashboard anyway, for example. In other cases, it's because we're programmers and don't import entire library ecosystems to do what we could do ourselves with a few lines of code or some APIs that are already supported by all modern browsers anyway. I liked React when it first arrived, because it was a tool that was that did one useful job and did it reasonably well. I dislike the direction it's taken more recently, because it now seems to be trying to do several jobs and not doing most of them very well at all. I understand that this is partly because of the way some developers coerced React into doing things it wasn't really suitable for and the React dev team have been responding to that, but I still think value has been lost in that process.
heyoni 6y ago
In 3D, it looks like something from out of stranger things.
tptacek 6y ago
Any large financial services company you're working with is already deploying sensitive apps on Node, for what it's worth.
- swsieber 6y ago
  That's not very comforting. Banks deploy nonsensical stuff all the time (like bad password policies).
  - tptacek 6y ago
    Nothing about bank security should comfort you, but the clientside app that uses React Native should probably not be the thing keeping you up at night.
    - deleted 6y ago
      [deleted]
- lostgame 6y ago
  Not the one I work for here in Canada. Just stating that to add a counter-point.
- coredog64 6y ago
  Right, but they’re probably mirroring dependencies locally, scanning them regularly, and have a process for adding new ones that isn’t “npm works on my desktop”.
  - what-the-grump 6y ago
    Cute, no they don't. Speaking from experience. It's a shit show.
leeoniya 6y ago
batter/faster: http://npm.broofa.com/?q=react-native http://npm.broofa.com/?q=react-native
AtlasBarfed 6y ago
Well javascript's package management is designed around the micropackage. It really doesn't bode well for microservices of any large scale complexity, unless there are concentrated meganodes with limited interconnects like cities and superhighways.
- josephg 6y ago
  I think the micropackage system is great in theory; it just falls down with bloat and security. Security could at least in theory be mitigated by something like pledge. Right now every developer on the (transitive!) deps authors list effectively has full access to our production systems, and that's ridiculous. Bloat though ... I mean, if every npm module was simply a directory with a package.json file and a couple js files I'd be happy. But thats almost never true, and usually for bad reasons. I'm not sure how to fix the problem. A few years ago I worked with a guy who maintained a popular little 200 line react image component on npm. The project website was great - with example images and whatnot. Some software we worked on used his library. Our node_modules was huge, and one day I took a look to try and figure out why. It turned out his tiny module was bundling all ~10mb of example images in the package itself. He was shocked and embarrassed when I pointed it out to him. The library had thousands of stars on github at the time. Lots of people were using it but nobody had noticed and mentioned it to him. 10mb isn't that big, but this is the sort of sloppiness that really adds up over time & thousands of transitive dependancies. Would tooling fix the problem? Maybe a little, but I suspect the problem its partially cultural. A lot of the web development community suffers from a lack of ... thoroughness. Like, the expectation is if the website works and looks pretty, you've done a good job. And invisible bugs and issues get overlooked consistently. Like app bundles which silently include multiple copies of the (200k) moment timezone database. Or obvious security issues that web devs just don't know to look for. I suppose this is how juniors learn - but it feels like a very lonely place sometimes when you have skills and experience.
  - AtlasBarfed 6y ago
    That 10MB anecdote reminds me of someone that deconstructed a massive windows app and found tons of junk images, libraries, and other wasted space. Meanwhile WinAmp was sooooo tiny.
Exuma 6y ago
It was the worst experience of my development life, building a phone app with it........................ never, never, never again. If you want to know what it's like to have everything break LITERALLY every few days, use react native.
- throwaway6734 6y ago
  As someone just getting into mobile development, I've enjoyed using it significantly more than native iOS/Android. It's so much faster and more straightforward to spin up designs,
  - jiofih 6y ago
    Until your first update. I assume you didn’t work on anything that has been released?
    - tiborsaas 6y ago
      What happens when you do the first update? Have you used Expo?
      - bbutterworth 6y ago
        Its not so bad. He is referring to RN updates, e.g. from 0.61.5 to 0.62 Its annoying, but I succeeded in upgrading in one project in about 1 hour. Just basically comparing the example code diff on github. perhaps older version had more changes and weren't documented as well. irrelevant comment: I hate Expo as it fails to be a helpful abstraction on top RN.
    - 0-O-0 6y ago
      Update as in you application update or dependency update?
    - throwaway6734 6y ago
      The app was developed over a year ago and then came back to it for significant feature development. The update wasn't terrible.
fermienrico 6y ago
The web has become truly awful and it’s invading desktop apps. We need to refactor our technology stack.
- andai 6y ago
  Today I installed an Electron-based terminal emulator and started seriously questioning my life choices.
  - fermienrico 6y ago
    I have the opinion that UI should not be async - meaning if there is some processing going on, UI elements should be disabled from interaction until the function returns. If it is a web query, I think that's fine. When applications start adding queues and jobs, UI feels "springy" instead of "snappy". User is waiting for some feedback of how long something is going to take, instead the user assumes that job is done (due to lack of feedback) and tries something next - this action is now in the queue. And then user waits... wait... and all of a sudden all queued processes return. This is not human centric design.
    - iainmerrick 6y ago
      Yes! Obviously long-running operations should be asynchronous, but the assumption that all operations should be treated as long-running is wrong. Specifically, typing feedback and button feedback should be synchronous, and should be done directly in the UI loop. I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.
    - deleted 6y ago
      [deleted]
- AgentME 6y ago
scarface74 6y ago
For this reason, I've been trying out Flutter or even considering to go back to native apps. This says so much about the sad state of modern software development... When native development is a last resort.
- macinjosh 6y ago
  Why does it have to be sad? To me it is good news! Especially if it is open source. The more software we can write that isn’t specific to a platform the more free and useful software can become. It wrestles back control from google, apple, microsoft et. al and makes their closed platforms less relevant.
  - scarface74 6y ago
    "Useful" as long as you don't care about battery life, memory usage, taking advantage of features of the host platform, or the native UI. As an end user why do I care about "openness"? If I pay a premium for my platform, why would I want second rate cross platform software?
    - pikelet 6y ago
      As an end user you might not get that software at all if no one is motivated to build it.
      - dhosek 6y ago
        But junk software is still junk and not worth the trouble.
        hombre_fatal 6y ago
        Are we to presume you think that using native SDKs saves your junk software from being junk? I'm not sure how else to interpret your comment in this thread.
est31 6y ago
A bit off topic, but the visualization of the dependency graph isn't really good. There are much better ways to render DAGs: https://github.com/erikbrinkman/d3-dag https://github.com/erikbrinkman/d3-dag My favourite is the factorio research tree. It gives you a sense of depth and you can select dependencies. Maybe I'll implement it one day when I have the time.
svieira 6y ago
If you want to see something _crazy_ compare that with http://npm.anvaka.com/#/view/2d/ember-cli http://npm.anvaka.com/#/view/2d/ember-cli - 1.2K links (and ember-cli compares quite well with react-native since it ships as direct dependencies a whole bunch of CLI tools to help with _building_ an app, not just the code that you ship to the device.)
mythz 6y ago
This is thanks to many of the React dev team being strong proponents of outsourcing to micro deps for everything & remained strong supporters even after the left-pad incident. Imagine how much more enjoyable npm would've been if prominent JS devs took a sane approach to dependencies, like the TypeScript team who have no runtime deps. The resulting npm deps of hell [1] means they need to rely on complex build solutions like Webpack to manage it all. My preference these days is to avoid npm/yarn all together and just use TypeScript watch (tsc -w) for incremental updates which lets you develop modern JS using modern fx's (e.g. Vue/React) without any of the npm/Webpack complexity & only requires a vastly simpler build solution to minify/bundle all UMD deps together. [1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/ https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...
- dwaltrip 6y ago
  According to the link in the comment, apparently React has a total dependency tree with only 7 nodes, which is the opposite of what you are describing. I'm actually surprised, I thought React had many more dependencies. Edit: Removed comment related to typo, no longer relevant.
  - mythz 6y ago
    Was a typo I meant `proponents`, fixed. The core library deps isn't relevant, it's how many deps the smallest starting Create React App has that matters [1]. As mentioned by OP react-native is far worse. [1] https://news.ycombinator.com/item?id=19195148 https://news.ycombinator.com/item?id=19195148
    - realharo 6y ago
      Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building? Also, with TypeScript, Babel becomes completely unnecessary. I haven't used it in any of my React projects for years. Many templates still include it by default to match the JS version, but if you create the project from scratch without any scaffolding, there is no reason to do so.
madhadron 6y ago
> but the depgraph above fills me with doubt for use in sensitive applications such as in finance or healthcare. Fortunately, in such industries you don't have to worry about being cross platform particularly. Go write C# and WinForms (or whatever it is these days). Or use Lazarus/FreePascal if you do need to be cross platform.
lukevp 6y ago
What's your take on the way Web Assembly approaches trust of dependencies? https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
sbr464 6y ago
I think the top comment should offer a solution, not only a critique. This dependency graph includes the development environment, which I feel is an unfair assessment. Why not re-run with only the production dependencies?
- ulisesrmzroche 6y ago
  No, thats a logical fallacy. critiques don’t need to provide solutions. It does not make the critique any less valid. This sentiment gets brought up so often here, I really don’t understand the reasoning behind it.
  - deleted 6y ago
    [deleted]
- ankka 6y ago
  You build the app with the dev dependencies, so you need to trust them as well.
  - deleted 6y ago
    [deleted]
hyperbovine 6y ago
A lot of these "packages" are just silly though. Among the horde of dependencies in that web is `number-is-nan`. Behold its awesome functionality: https://www.npmjs.com/package/number-is-nan https://www.npmjs.com/package/number-is-nan Want Array#filter/map/reduce? Why that'll be three separate packages: https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-reduce https://www.npmjs.com/package/array-reduce It just seems to be the culture of the Node.js crowd to take a library, break it up into functions, and publish every. single. one. as a separate package.
- jmull 6y ago
  The purpose of that kind of package is to provide a standalone implementation of a function. To criticize this organization, you would need to understand why people find that to be valuable and show a better approach. You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.
  - e_proxus 6y ago
    Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today). I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.
    - toxik 6y ago
      The NaN library is literally just testing if the value is a number with typeof v === 'number' then tests if v !== v. This is not something you need a library for at all, big or small.
      - e_proxus 6y ago
        Yeah, this is my philosophy when developing Erlang software as well (also seems to be shared by most of that community). A few dependencies less are always worth a few functions more.
deleted 6y ago
[deleted]
m-p-3 6y ago
For those who just want a snapshot and not wait for the graph to draw https://i.imgur.com/RT6Fj4c.png https://i.imgur.com/RT6Fj4c.png

by wyc 6y ago

peterhunt 6y ago

Wow, that React Native dep graph is crazy! But as I browse it, most of the dependencies seem to be build-time, not runtime dependencies (i.e. it seems like most of them are related to Babel). The React comparison doesn't include dev dependencies. While react-native does have more dependencies than vanilla react, on first glance the list doesn't seem too crazy https://github.com/facebook/react-native/blob/master/package.json#L87 https://github.com/facebook/react-native/blob/master/package...

filleduchaos 6y ago
The package.json file hasn't been remotely close to representative of the actual dependency count of a JS project for years.
- peterhunt 6y ago
  sure, but it gives you the list of packages to look at in the dependency visualizer
  - filleduchaos 6y ago
    It gives you a list of directly depended-upon packages. It doesn't give you a list of _those_ packages' dependencies, or _their_ dependencies, which funnily enough also get installed when you install your direct dependencies. Plus I forgot to address this in my earlier comment: that visualizer only shows dependencies. By default it doesn't load any dev dependencies. You can confirm that for yourself by checking out https://npm.anvaka.com/#/view/2d/rollup https://npm.anvaka.com/#/view/2d/rollup for example - only the single runtime dependency on fsevents shows up, the dozens of dev dependencies Rollup has don't. So yes, React Native does ship that overcomplicated graph of dependencies to all its users. I'll grant that at least _some_ of the code in those dependencies gets tree-shaken out.
    - andrewingram 6y ago
      Your last paragraph is a bit inaccurate. The dependencies are needed by people developing WITH React Native as opposed to devDependencies (which are for people developing ON React Native). So whilst you will be using the complicated graph of dependencies at some point, that isn't the same as saying they'll be shipped to end users of the app. The line between dependencies and devDependencies got blurry the second npm packages got used for more than just Node.js itself. What's really needed to remove the ambiguity is something like prodDependencies, which would be a subset of the current dependencies, but I don't know if it's really worth it.
      - haskman 6y ago
        Can you clarify the difference between developing "with" vs "on" react-native?
        6y ago
bigiain 6y ago
Am I the only one who just spent 5 minutes chasing moving nodes round in that graph looking for leftpad.js?
- searchableguy 6y ago
  Definitely not.
- captivechains 6y ago
  it's in there, somewhere.. https://github.com/microsoft/react-native-windows/blob/master/yarn.lock#L8737 https://github.com/microsoft/react-native-windows/blob/maste...
- ci5er 6y ago
  Why don't people copy the deb-tree to their local repo and/or pin the version that they want, so that they can be free of node terrorists? EDIT: To be clear - maybe I am REALLY old-school, but every time we did a release, we archived our tool-chain (GCC blah blah, Make blah blah, bash blah blah), our depencies, our vendor libraries and our code, so that IF in 20 years, if we had to rebuild a particular release (12.x) for a particular client (Chase) on a particular platform (AIX), we could do so de novo. Maybe that was overkill, but in a world where everything changes, why wouldn't you snapshot everything for every release?
  - mlvljr 6y ago
    "if your a dad, yes, doh!"
  - nicoburns 6y ago
    This makes sense if you're releasing versioned software builds to 3rd parties. If you're running it internally (e.g. as a SaaS company) then there's much less cause to run an old versions, let alone one from 20 years ago.
    - ci5er 6y ago
      Yeah. I get that. Getting enterprise people to migrate or go off-prem for everything takes some time. And some like custom versons! I just like to snap-shot everything (including the tool chain) so that I can recreate the past out of my repository at any time for any reason. (I'm weird like that - I expect the same out of legal, ops and accounting as well) Maybe I'm old - but I don't trust Quickbooks-in-the-Cloud. EDIT: But I use 'em!
tomphoolery 6y ago
The longer you leave that dependency graph up, the more it starts to look like the Huddle from Inside...
deleted 6y ago
[deleted]

AaronFriel 6y ago

Speaking of trusting trust, I think I'd love for Node¹ to support something like OpenBSD pledge (2) and unveil (2) for imports, where once you enter into a particular package certain capabilities are disabled. I would like to be able to assert that when I import some package, it and all of the packages it recursively includes do not perform network requests, do not use the filesystem outside of some folder, and so on. A fine grained capability system for packages would dramatically improve the safety profile, and if this were built into package.json and the lockfile we could do the following: 1. Packages advertise what their default capabilities should be limited to 2. Changes in those capabilities are encoded in the package lock file, and can't be changed without the user explicitly affirming them ¹ and other langs with extensive use of package managers and micro-packages

pier25 6y ago
> A fine grained capability system for packages would dramatically improve the safety profile I think Deno does that (the new project by Node's original creator): https://blog.logrocket.com/what-is-deno/ https://blog.logrocket.com/what-is-deno/
- mthoms 6y ago
  Woohoo! I just noticed Deno is at release candidate stage for v1.0.
- jakear 6y ago
  Deno gives all packages the same permissions of the main app. So if your app can make network requests, so can every dependency you use. It’s not a great situation. I’ve brought this up to them and their response is that per-package permissions would be too difficult to implement.
  - vijaybritto 6y ago
    Yes, checking everyone at the main door is indeed easier than checking everyone at every single point of contact. It needs a vast architectural change compared to current implementation as you need to enforce those rules at runtime!

holler 6y ago

wtf! that's insane! now I'm curious to look up other oss projects I use :)

sky_rw 6y ago
It's turtles all the way down.

captainmuon 6y ago

I wonder why there is no effort towards reducing the dependencies, or at least vendoring the worst offenders. It would be a huge quality-of-life improvement for React developers, not to mention the improved security and reliability.

scarlac 6y ago
There are. A lot of components have been deprecated and are being moved out into community-maintained versions. Some major examples are: Camera library, Photo Library integrations, Date/Time picker, AsyncStorage, and more. This is a large scale effort from the dev team to decrease core size: https://github.com/facebook/react-native/issues/23313 https://github.com/facebook/react-native/issues/23313

Tade0 6y ago

I believe this is something that next-gen frameworks worked around: http://npm.anvaka.com/#/view/2d/svelte http://npm.anvaka.com/#/view/2d/svelte http://npm.anvaka.com/#/view/2d/solid-js http://npm.anvaka.com/#/view/2d/solid-js

kiliancs 6y ago
React doesn't suffer from this. It's React Native.
- notJim 6y ago
  Interesting, you are right AFAICT (react has numerous packages and I'm not totally sure how they relate). http://npm.anvaka.com/#/view/2d/react http://npm.anvaka.com/#/view/2d/react http://npm.anvaka.com/#/view/2d/react-dom http://npm.anvaka.com/#/view/2d/react-dom
- ricardobeat 6y ago
  In theory, that is. Since it doesn't include batteries, the controller, the wheels, or the antenna you're gonna end up bringing a ton of dependencies yourself to cover the missing parts (animation, state management, routing etc). Plus you're not seeing the dev dependencies, a more apt comparison would be to create-react-app.
  - Silhouette 6y ago
    Since it doesn't include batteries, the controller, the wheels, or the antenna you're gonna end up bringing a ton of dependencies yourself to cover the missing parts (animation, state management, routing etc). Or not. I've worked on plenty of applications that had few if any dependencies for those things. I'm sure many others have too. In some cases that was because we didn't need that particular functionality. Routing has little value if you're building an in-house SPA that always starts from the same dashboard anyway, for example. In other cases, it's because we're programmers and don't import entire library ecosystems to do what we could do ourselves with a few lines of code or some APIs that are already supported by all modern browsers anyway. I liked React when it first arrived, because it was a tool that was that did one useful job and did it reasonably well. I dislike the direction it's taken more recently, because it now seems to be trying to do several jobs and not doing most of them very well at all. I understand that this is partly because of the way some developers coerced React into doing things it wasn't really suitable for and the React dev team have been responding to that, but I still think value has been lost in that process.

heyoni 6y ago

In 3D, it looks like something from out of stranger things.

tptacek 6y ago

Any large financial services company you're working with is already deploying sensitive apps on Node, for what it's worth.

swsieber 6y ago
That's not very comforting. Banks deploy nonsensical stuff all the time (like bad password policies).
- tptacek 6y ago
  Nothing about bank security should comfort you, but the clientside app that uses React Native should probably not be the thing keeping you up at night.
  - deleted 6y ago
    [deleted]
lostgame 6y ago
Not the one I work for here in Canada. Just stating that to add a counter-point.
coredog64 6y ago
Right, but they’re probably mirroring dependencies locally, scanning them regularly, and have a process for adding new ones that isn’t “npm works on my desktop”.
- what-the-grump 6y ago
  Cute, no they don't. Speaking from experience. It's a shit show.

leeoniya 6y ago

batter/faster: http://npm.broofa.com/?q=react-native http://npm.broofa.com/?q=react-native

AtlasBarfed 6y ago

Well javascript's package management is designed around the micropackage. It really doesn't bode well for microservices of any large scale complexity, unless there are concentrated meganodes with limited interconnects like cities and superhighways.

josephg 6y ago
I think the micropackage system is great in theory; it just falls down with bloat and security. Security could at least in theory be mitigated by something like pledge. Right now every developer on the (transitive!) deps authors list effectively has full access to our production systems, and that's ridiculous. Bloat though ... I mean, if every npm module was simply a directory with a package.json file and a couple js files I'd be happy. But thats almost never true, and usually for bad reasons. I'm not sure how to fix the problem. A few years ago I worked with a guy who maintained a popular little 200 line react image component on npm. The project website was great - with example images and whatnot. Some software we worked on used his library. Our node_modules was huge, and one day I took a look to try and figure out why. It turned out his tiny module was bundling all ~10mb of example images in the package itself. He was shocked and embarrassed when I pointed it out to him. The library had thousands of stars on github at the time. Lots of people were using it but nobody had noticed and mentioned it to him. 10mb isn't that big, but this is the sort of sloppiness that really adds up over time & thousands of transitive dependancies. Would tooling fix the problem? Maybe a little, but I suspect the problem its partially cultural. A lot of the web development community suffers from a lack of ... thoroughness. Like, the expectation is if the website works and looks pretty, you've done a good job. And invisible bugs and issues get overlooked consistently. Like app bundles which silently include multiple copies of the (200k) moment timezone database. Or obvious security issues that web devs just don't know to look for. I suppose this is how juniors learn - but it feels like a very lonely place sometimes when you have skills and experience.
- AtlasBarfed 6y ago
  That 10MB anecdote reminds me of someone that deconstructed a massive windows app and found tons of junk images, libraries, and other wasted space. Meanwhile WinAmp was sooooo tiny.

Exuma 6y ago

It was the worst experience of my development life, building a phone app with it........................ never, never, never again. If you want to know what it's like to have everything break LITERALLY every few days, use react native.

throwaway6734 6y ago
As someone just getting into mobile development, I've enjoyed using it significantly more than native iOS/Android. It's so much faster and more straightforward to spin up designs,
- jiofih 6y ago
  Until your first update. I assume you didn’t work on anything that has been released?
  - tiborsaas 6y ago
    What happens when you do the first update? Have you used Expo?
    - bbutterworth 6y ago
      Its not so bad. He is referring to RN updates, e.g. from 0.61.5 to 0.62 Its annoying, but I succeeded in upgrading in one project in about 1 hour. Just basically comparing the example code diff on github. perhaps older version had more changes and weren't documented as well. irrelevant comment: I hate Expo as it fails to be a helpful abstraction on top RN.
  - 0-O-0 6y ago
    Update as in you application update or dependency update?
  - throwaway6734 6y ago
    The app was developed over a year ago and then came back to it for significant feature development. The update wasn't terrible.

fermienrico 6y ago

The web has become truly awful and it’s invading desktop apps. We need to refactor our technology stack.

andai 6y ago
Today I installed an Electron-based terminal emulator and started seriously questioning my life choices.
- fermienrico 6y ago
  I have the opinion that UI should not be async - meaning if there is some processing going on, UI elements should be disabled from interaction until the function returns. If it is a web query, I think that's fine. When applications start adding queues and jobs, UI feels "springy" instead of "snappy". User is waiting for some feedback of how long something is going to take, instead the user assumes that job is done (due to lack of feedback) and tries something next - this action is now in the queue. And then user waits... wait... and all of a sudden all queued processes return. This is not human centric design.
  - iainmerrick 6y ago
    Yes! Obviously long-running operations should be asynchronous, but the assumption that all operations should be treated as long-running is wrong. Specifically, typing feedback and button feedback should be synchronous, and should be done directly in the UI loop. I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.
  - deleted 6y ago
    [deleted]
AgentME 6y ago

scarface74 6y ago

For this reason, I've been trying out Flutter or even considering to go back to native apps. This says so much about the sad state of modern software development... When native development is a last resort.

macinjosh 6y ago
Why does it have to be sad? To me it is good news! Especially if it is open source. The more software we can write that isn’t specific to a platform the more free and useful software can become. It wrestles back control from google, apple, microsoft et. al and makes their closed platforms less relevant.
- scarface74 6y ago
  "Useful" as long as you don't care about battery life, memory usage, taking advantage of features of the host platform, or the native UI. As an end user why do I care about "openness"? If I pay a premium for my platform, why would I want second rate cross platform software?
  - pikelet 6y ago
    As an end user you might not get that software at all if no one is motivated to build it.
    - dhosek 6y ago
      But junk software is still junk and not worth the trouble.
      - hombre_fatal 6y ago
        Are we to presume you think that using native SDKs saves your junk software from being junk? I'm not sure how else to interpret your comment in this thread.

est31 6y ago

A bit off topic, but the visualization of the dependency graph isn't really good. There are much better ways to render DAGs: https://github.com/erikbrinkman/d3-dag https://github.com/erikbrinkman/d3-dag My favourite is the factorio research tree. It gives you a sense of depth and you can select dependencies. Maybe I'll implement it one day when I have the time.

svieira 6y ago

If you want to see something _crazy_ compare that with http://npm.anvaka.com/#/view/2d/ember-cli http://npm.anvaka.com/#/view/2d/ember-cli - 1.2K links (and ember-cli compares quite well with react-native since it ships as direct dependencies a whole bunch of CLI tools to help with _building_ an app, not just the code that you ship to the device.)

mythz 6y ago

This is thanks to many of the React dev team being strong proponents of outsourcing to micro deps for everything & remained strong supporters even after the left-pad incident. Imagine how much more enjoyable npm would've been if prominent JS devs took a sane approach to dependencies, like the TypeScript team who have no runtime deps. The resulting npm deps of hell [1] means they need to rely on complex build solutions like Webpack to manage it all. My preference these days is to avoid npm/yarn all together and just use TypeScript watch (tsc -w) for incremental updates which lets you develop modern JS using modern fx's (e.g. Vue/React) without any of the npm/Webpack complexity & only requires a vastly simpler build solution to minify/bundle all UMD deps together. [1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/ https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...

dwaltrip 6y ago
According to the link in the comment, apparently React has a total dependency tree with only 7 nodes, which is the opposite of what you are describing. I'm actually surprised, I thought React had many more dependencies. Edit: Removed comment related to typo, no longer relevant.
- mythz 6y ago
  Was a typo I meant `proponents`, fixed. The core library deps isn't relevant, it's how many deps the smallest starting Create React App has that matters [1]. As mentioned by OP react-native is far worse. [1] https://news.ycombinator.com/item?id=19195148 https://news.ycombinator.com/item?id=19195148
  - realharo 6y ago
    Why would create react app add more run-time dependencies? Isn't that just Babel and stuff used for building? Also, with TypeScript, Babel becomes completely unnecessary. I haven't used it in any of my React projects for years. Many templates still include it by default to match the JS version, but if you create the project from scratch without any scaffolding, there is no reason to do so.

madhadron 6y ago

> but the depgraph above fills me with doubt for use in sensitive applications such as in finance or healthcare. Fortunately, in such industries you don't have to worry about being cross platform particularly. Go write C# and WinForms (or whatever it is these days). Or use Lazarus/FreePascal if you do need to be cross platform.

lukevp 6y ago

What's your take on the way Web Assembly approaches trust of dependencies? https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

sbr464 6y ago

I think the top comment should offer a solution, not only a critique. This dependency graph includes the development environment, which I feel is an unfair assessment. Why not re-run with only the production dependencies?

ulisesrmzroche 6y ago
No, thats a logical fallacy. critiques don’t need to provide solutions. It does not make the critique any less valid. This sentiment gets brought up so often here, I really don’t understand the reasoning behind it.
- deleted 6y ago
  [deleted]
ankka 6y ago
You build the app with the dev dependencies, so you need to trust them as well.
- deleted 6y ago
  [deleted]

hyperbovine 6y ago

A lot of these "packages" are just silly though. Among the horde of dependencies in that web is `number-is-nan`. Behold its awesome functionality: https://www.npmjs.com/package/number-is-nan https://www.npmjs.com/package/number-is-nan Want Array#filter/map/reduce? Why that'll be three separate packages: https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-reduce https://www.npmjs.com/package/array-reduce It just seems to be the culture of the Node.js crowd to take a library, break it up into functions, and publish every. single. one. as a separate package.

jmull 6y ago
The purpose of that kind of package is to provide a standalone implementation of a function. To criticize this organization, you would need to understand why people find that to be valuable and show a better approach. You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.
- e_proxus 6y ago
  Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today). I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.
  - toxik 6y ago
    The NaN library is literally just testing if the value is a number with typeof v === 'number' then tests if v !== v. This is not something you need a library for at all, big or small.
    - e_proxus 6y ago
      Yeah, this is my philosophy when developing Erlang software as well (also seems to be shared by most of that community). A few dependencies less are always worth a few functions more.

deleted 6y ago

[deleted]

m-p-3 6y ago

For those who just want a snapshot and not wait for the graph to draw https://i.imgur.com/RT6Fj4c.png https://i.imgur.com/RT6Fj4c.png