Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

Post reply on HN
Print view View original

91–100 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#91

Post by zuzun »

herpderperator wrote: post #16

When this webpage loads, it briefly flashes in plaintext before loading CSS - at least in Chrome. This is unusual since it has the CSS stylesheet in the head which I thought would block until it's fully loaded. Does anyone know what's going on with that?

I guess render-blocking isn't really a thing, the HTML spec only describes script-blocking and is light on the rendering aspects. Now most web pages have styles and scripts and since styles block scripts, you usually perceive styles as render-blocking. But this web page doesn't have any scripts, so the browser reaches DOMContentLoaded right after parsing the HTML and does the first paint while the request for the style is still in flight.

At least that's my theory. You could test this by inserting an empty tag into the , which should delay DOMContentLoaded until the style arrives and prevent the flash of unstyled content.

Re: Always Review Your Dependencies, AGPL Edition

#92

Post by pythonist »

And also very important to watch for changes of your dependencies, as they can be quite dynamic. A single review too early or too late in the development process may have misleading results. Watching for commit changes is too time consuming, so watching for releases is a bit easier, especially if you use something like https://newreleases.io or other similar sites.

Re: Always Review Your Dependencies, AGPL Edition

#93

Post by lolc »

iforgotpassword wrote: post #76
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whet…

I tried vanilla JS three years ago. It got so tedious after just one page that I decided to try and use Elm instead. I have not regretted it once. In contrast to the hacky Npm ecosystem, Elm feels like I'm working with somebody who values my mental sanity a great deal.

Re: Always Review Your Dependencies, AGPL Edition

#94

Post by krapp »

pas wrote: post #87
iforgotpassword wrote: post #76

Earlier quoted context omitted.

I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whet…

Modern JS is TypeScript. Also Yarn is very handy. (Fast, simple, correct.) If you need leftPad, maybe just "vendor" it manually.

Modern JS is the current ECMAScript standard. Typescript is not "modern JS", any more than Coffeescript was, any more than the compile-to-js language that will probably replace it in a week.

You're confusing the tool for the language the tool operates on, akin to claiming modern C++ is Visual Studio.

Re: Always Review Your Dependencies, AGPL Edition

#95

Post by jaredklewis »

iforgotpassword wrote: post #76
cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

I'm not a web dev, not a JavaScript fan, but out of pure curiosity I've been playing with the idea of doing my next side project in node, just to get an idea of what modern Js feels like. But the whole dependency hell, left-pad and the likes are a real turnoff. So what I'd probably end up with is coding in pure Js without a package manager or "build system". Basically like you did PHP in the 90s. The question is whet…

It’s slowly expanding, but JS has an anemic standard library. The node platform adds a little, but yo’re still miles away from a typical standard library like Java or python.

If you want to have 0 dependencies, you will have to write a lot of code to do things that would just be a line or two in most other languages.

Re: Always Review Your Dependencies, AGPL Edition

#96

Post by henvic »

Slightly related: I have created this useful tool called vendorlicenses that allows you to check and concatenate licenses on Go programs (to give credit on a CLI "legal" command).

It will only work if you are vendoring your packages though (and you should!).

https://github.com/henvic/vendorlicenses

Re: Always Review Your Dependencies, AGPL Edition

#97

Post by correct_horse »

debiandev wrote: post #89
sansnomme wrote: post #4

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

This is a reason for Debian to exists. Licenses cannot be reviewed automatically in a reliable way. Debian developers review the licenses and store them in a machine-parsable file.

Are you saying that standard licenses cannot be checked for compatibility automatically? Or that arbitrary homebrew licenses cannot be checked automatically?

Re: Always Review Your Dependencies, AGPL Edition

#98

Post by lmm »

cygned wrote: post #41

I try to convince my team that the node.js ecosystem has gotten into a stage where it cannot be used for security/financial applications because the sheer amount of dependencies pose an inherent threat. I advocate for Go because of the tendency to less and easier reviewable dependencies. Nobody except me seems to see a problem there, despite me being able to point out specific security incidents. I am wondering if I…

Dependencies are cattle, not pets. There's nothing wrong with having zillions of them; what you need is good tools to manage them in bulk.

In the JVM ecosystem, projects are only allowed in the Maven Central repository if they have their license documented in a machine readable fashion there; it's then trivial to check what licenses you're depending on (and there are several plugins available for doing so). I'm amazed other ecosystems don't offer the same.

Re: Always Review Your Dependencies, AGPL Edition

#99

Post by js4ever »

krapp wrote: post #94
pas wrote: post #87

Earlier quoted context omitted.

Modern JS is TypeScript. Also Yarn is very handy. (Fast, simple, correct.) If you need leftPad, maybe just "vendor" it manually.

Modern JS is the current ECMAScript standard. Typescript is not "modern JS", any more than Coffeescript was, any more than the compile-to-js language that will probably replace it in a week. You're confusing the tool for the language the tool operates on, akin to claiming modern C++ is Visual Studio.

One thousand yes to this!
Post reply on HN