3 ms·

I'm not insulted. The concern is valid. Its range of application is just so fringe as to make this a near-academic discussion. I recently tried using a small J

I'm not insulted. The concern is valid. Its range of application is just so fringe as to make this a near-academic discussion. I recently tried using a small JS module to identify a file's mime-type. It pulled in 68MB of dependencies. And that's just one of many things an actual application will need. W.T.F. So I agree, this is not the problem we need to tackle right now.

corytheboyd 6y ago
Wow mind sharing that package name? That’s insane I’m curious what they’re even doing
- bromuro 6y ago
  Probably he was installing the dev dependencies.
  - corytheboyd 6y ago
    Either that, the package legitimately has that many recursive dependencies, or the original commenter is hyperbolizing.
romwell 6y ago
I agree with what you say; my choice of words was not perfect.
AussieWog93 6y ago
>this is not the problem we need to tackle right now I mean, it's clearly not the problem _you_ need to tackle right now, but it's a real problem that other people need to tackle. There are still people hand-rolling broken CSV parsers, manually re-implementing basic STL containers and other stupid "lightness" even when it doesn't make sense. This is not an academic discussion.
- romwell 6y ago
  Is the perceived "lightness" an issue there, or good old NIH syndrome? 'cause a handrolled CSV parser vs. a third party one is often not a lightness issue; you're using a library either way, and your own library is not necessarily lighter. The article was not even talking about that. The "lightness" approach in your examples would be sticking to arrays instead of using containers, or using Java serialization back when it was introduced (language feature, no extra weight!) instead writing to CSV, which requires a parser. I feel like you are taking about a different problem here, and the problem TFA addresses is indeed academic. (Edit: the author of the article shies away from giving example. The only example -- in-house gettext alternatives -- was definitely not a lightness concern where I've seen it; consider that i18n framework in Android isn't simply gettext for reasons that have nothing to do with TFA)
Chris2048 6y ago
Needlessly criticising software envs / prog-langs should be avoided as it causes needless flame-warring; but I think software such as Node/NPM have serious bloat/security issues that need to be criticised, and by extension stuff built on Atom. Any software build has to consider dev-time vs software-size, but I think the reason NPM is so popular for apps is not because it truly saves time, but because it uses existing web-dev technology, which ultimately means the technology is used in a context it wasn't designed for (and a lot of it was janky design-by-committee stuff even then) and various tricks/hacks/magic/shims are used to make it work. Hopefully there are moves towards more WebASM in the future? But that still requires sane frameworks, or even better - libraries.

corytheboyd 6y ago

Wow mind sharing that package name? That’s insane I’m curious what they’re even doing

bromuro 6y ago
Probably he was installing the dev dependencies.
- corytheboyd 6y ago
  Either that, the package legitimately has that many recursive dependencies, or the original commenter is hyperbolizing.

romwell 6y ago

I agree with what you say; my choice of words was not perfect.

AussieWog93 6y ago

>this is not the problem we need to tackle right now I mean, it's clearly not the problem _you_ need to tackle right now, but it's a real problem that other people need to tackle. There are still people hand-rolling broken CSV parsers, manually re-implementing basic STL containers and other stupid "lightness" even when it doesn't make sense. This is not an academic discussion.

romwell 6y ago
Is the perceived "lightness" an issue there, or good old NIH syndrome? 'cause a handrolled CSV parser vs. a third party one is often not a lightness issue; you're using a library either way, and your own library is not necessarily lighter. The article was not even talking about that. The "lightness" approach in your examples would be sticking to arrays instead of using containers, or using Java serialization back when it was introduced (language feature, no extra weight!) instead writing to CSV, which requires a parser. I feel like you are taking about a different problem here, and the problem TFA addresses is indeed academic. (Edit: the author of the article shies away from giving example. The only example -- in-house gettext alternatives -- was definitely not a lightness concern where I've seen it; consider that i18n framework in Android isn't simply gettext for reasons that have nothing to do with TFA)

Chris2048 6y ago

Needlessly criticising software envs / prog-langs should be avoided as it causes needless flame-warring; but I think software such as Node/NPM have serious bloat/security issues that need to be criticised, and by extension stuff built on Atom. Any software build has to consider dev-time vs software-size, but I think the reason NPM is so popular for apps is not because it truly saves time, but because it uses existing web-dev technology, which ultimately means the technology is used in a context it wasn't designed for (and a lot of it was janky design-by-committee stuff even then) and various tricks/hacks/magic/shims are used to make it work. Hopefully there are moves towards more WebASM in the future? But that still requires sane frameworks, or even better - libraries.