| ▲ | anonymous908213 7 hours ago |
| Node doesn't have any particular relation to NPM? You don't have to download 1000 other people's code. Writing your own code is a thing that you are legally allowed to do, even if you're writing in Javascript. |
|
| ▲ | jacquesm 7 hours ago | parent | next [-] |
| Yes, and you can code in assembly as well if you want it. But: that's not how 99% of the people using node is using it so that it is theoretically possible to code up every last bit yourself is true but it does not contribute to the discussion at all. An eco-system, if it insists on slapping on a package manager (see also: Rust, Go) should always properly evaluate the resulting risks and put proper safeguards in place or you're going to end up with a massive supply chain headache. |
| |
| ▲ | anonymous908213 7 hours ago | parent [-] | | Writing code yourself so as not to cultivate 1000 dependencies you can't possibly ensure the security of is not the same as writing assembly. That you even reach for that comparison is indicative of the deep rot in Javascript culture. Writing your own code is perceived as a completely unreasonable thing to be doing to 99% of JS-devs and that's why the web performs like trash and has breaches every other day, but it's actually a very reasonable thing to be doing and people who write most any other language typically engage in the writing of own code on a daily basis. At any rate, JS the language itself is fine, Node is fine, and it is possible to adopt better practices without forsaking the language/ecosystem completely. | | |
| ▲ | jacquesm 7 hours ago | parent [-] | | > That you even reach for that comparison is indicative of the deep rot in Javascript culture. Sorry? No, I'm the guy that does write all of his code from scratch so you're entirely barking up the wrong tree here. I am just realistic in seeing that people are not going to write more code than they strictly speaking have to because that is the whole point of using Node in the first place. The Assembly language example is just to point out the fact that you could plug in at a lower level of abstraction but you are not going to because of convenience, and the people using Node.js see it no different. JS is a perfectly horrible little language that is now being pushed into domains where it has absolutely no business being used (I guess you would object to running energy infrastructure on Node.js and please don't say nobody would be stupid enough to do that). Node isn't fine it needs a serious reconsideration of the responsibilities of the eco-system maintainers. See also: Linux, the BSDs and other large projects for examples of how this can be done properly. | | |
| ▲ | notpachet 7 hours ago | parent [-] | | I feel like there are merits to your argument but that you have a larger anti-JS bias that's leaking through. Not that there aren't problems with Node itself, but as many people have pointed out, there are plenty of organizations writing in Node that aren't pwn'd by these sorts of attacks because we don't blindly update deps. Perfect is the enemy of good; dependency cooldown etc is enough to mitigate the majority of these risks. | | |
| ▲ | jacquesm 7 hours ago | parent | next [-] | | > I feel like there are merits to your argument but that you have a larger anti-JS bias that's leaking through. Familiarity breeds contempt. | | |
| ▲ | notpachet 6 hours ago | parent | next [-] | | The truth is typically somewhere in the middle. I feel you though. I'm that way with Ruby/Bundler. | |
| ▲ | user34283 2 hours ago | parent | prev [-] | | What's the problem? I think JS is great. It's simple, anybody can use it. TypeScript is excellent too. The structural type system is very convenient. It's not going to replace Rust in cases where performance is essential or where you want strict runtime type checking or whatever, but for general use and graphical applications JS seems like a great pick. I often hear people complain about JS, but really, how is it any worse than say Python? | | |
| ▲ | jacquesm 42 minutes ago | parent [-] | | > I often hear people complain about JS, but really, how is it any worse than say Python? That's not the flex you think it is. |
|
| |
| ▲ | acheron 4 hours ago | parent | prev [-] | | Reality has an anti-JS bias. |
|
|
|
|
|
| ▲ | paradite 7 hours ago | parent | prev | next [-] |
| npm has been the official package manager for node since forever (0.8 or earlier iirc). I think even before the io.js fork and merge. |
|
| ▲ | AIorNot 7 hours ago | parent | prev [-] |
| So your supposed to write your own posthog? be serious |
| |
| ▲ | anonymous908213 7 hours ago | parent | next [-] | | Yes. If your shop is serious about security, it is in no way unreasonable to be building out tools like that in-house, or else paying a real vendor with real security practices for their product. If you're an independent developer, the entirety of Posthog is overkill, and you can instead write the specific features you need yourself. | | | |
| ▲ | exasperaited 7 hours ago | parent | prev | next [-] | | I tell people this over and over and over: every time you use a third party dependency, especially an ongoing one, you should consider that you are adding the developers to your team and importing their prior decisions and their biases. You add them to your circle of trust. You can't just scale out a team without assessing who you are adding to it: what is their reputation? where did they learn? It's not quite the same questions when picking a library but it is the same process. Who wrote it? What else did they write? Does the code look like we could manage it if the developer quits, etc. Nobody's saying you shouldn't use third party dependency. But nobody benefits if we pretend that adding a dependency isn't a lot like adding a person. So yeah, if you need all of posthog without adding posthog's team to yours, you're going to have to write it yourself. | | |
| ▲ | reconnecting 6 hours ago | parent [-] | | > I tell people this over and over and over: every time you use a third party dependency, especially an ongoing one, you should consider that you are adding the developers to your team and importing their prior decisions and their biases. You add them to your circle of trust. Thanks! Now, I will also tell this to developers. |
| |
| ▲ | dkdbejwi383 7 hours ago | parent | prev [-] | | If they have a HTTP API using standard authentication methods it's not that difficult to create a simple wrapper. Granted a bit more work if you want to do things like input/output validation too, but there's a trade-off between ownership there and avoiding these kinds of supply-chain attacks. | | |
| ▲ | jacquesm 7 hours ago | parent [-] | | > Granted a bit more work if you want to do things like input/output validation too, A bit? A proper input validator is a lot of work. | | |
| ▲ | dkdbejwi383 7 hours ago | parent [-] | | If you aim for 100% coverage of the API you're integrating with, sure. But for most applications you're going to only be touching a small surface area, so you can validate paths you know you'll hit. Most of the time you probably don't need 100% parity, you need Just Enough for your use-case. | | |
| ▲ | jacquesm 7 hours ago | parent [-] | | That's an excellent way to get bitten. | | |
| ▲ | dkdbejwi383 7 hours ago | parent [-] | | I'm not sure how you mean. To my understanding, there's less surface area for problems if I have a wrapper over the one or two endpoints some API provides, which I've written and maintain myself, over importing some library that wraps all 100 endpoints the API provides, but which is too large for me to fully audit. |
|
|
|
|
|
