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

Kill Your Dependencies

mikeperham.com

Post reply on HN
Print view View original

221–229 of 229 posts

Re: Kill Your Dependencies

#221

Post by EvanPlaice »

mbrock wrote: post #129
jermo wrote: post #81

Earlier quoted context omitted.

The downside is that you bring in another layer of indirection and, as a result, greater cognitive load for yourself. Mycode -> facade -> library Navigating code becomes more cumbersome and stack traces longer. I do like this approach too but it isn't free.

That reminds me of another thing I'd like to tell library writers: please think of your stack traces as somewhat public, because I always end up 40 layers deep trying to debug something and it's just painful. Hopefully a facade will introduce a small constant number of stack frames... Anyway, with something like Lodash for JavaScript, I'd even want to "facade" that into a project-specific utilities thing. Right now w…

A facade should only add one layer of indirection.

As for project-level management of external dependencies the tooling can be used to provide a facade for imports. I'm not sure about Webpack but JSPM already does this using a config.js file that maps all of the dependencies to readable import names, sans version numbers so the site doesn't break on future updates.

Ideally, once ES6 modules are used more widely it would be great to see libs start to adopt the facade pattern to provide finer granularity of control without deep linking into a project's source.

Re: Kill Your Dependencies

#222

Post by sargas »

allendoerfer wrote: post #12

To me, this seems more like an argument for optimizing beyond your own stack. Don't kill your own dependencies. Your app uses to much memory? Improve a dependency, you have now improved other peoples apps, too. Your app uses to much dependencies in total? Try to get all your first-level dependencies to standardize on the best http-client. (Which he is partially doing with his post.) Dependencies may have problems, bu…

I agree 100% with this.

I used to bring in dependencies with the "don't reinvent the wheel" mentality. Then I realized how much trust I'm giving to the authors of all dependencies I pull in. Now I tend to do my best to understand the dependencies I bring so I can improve them if I can.

The only problem I find with this decision is when I make an improvement/fix a bug on a dependency, and the project is either inactive or the authors don't give a crap about your work.

Re: Kill Your Dependencies

#223

Post by Aloha »

joesb wrote: post #200
Aloha wrote: post #194

Earlier quoted context omitted.

Allocation of that memory still costs /something/ even if ram is so plentiful as to be free.

Making your own library also costs something, which are probably more scarce than RAM.

no disagreement - better to use someone elses - but if your using one tiny part of a gigantic library of functions, it may be more cost effective to find a better (smaller) library, or write your own.

Re: Kill Your Dependencies

#224

Post by allendoerfer »

sargas wrote: post #222
allendoerfer wrote: post #12

To me, this seems more like an argument for optimizing beyond your own stack. Don't kill your own dependencies. Your app uses to much memory? Improve a dependency, you have now improved other peoples apps, too. Your app uses to much dependencies in total? Try to get all your first-level dependencies to standardize on the best http-client. (Which he is partially doing with his post.) Dependencies may have problems, bu…

I agree 100% with this. I used to bring in dependencies with the "don't reinvent the wheel" mentality. Then I realized how much trust I'm giving to the authors of all dependencies I pull in. Now I tend to do my best to understand the dependencies I bring so I can improve them if I can. The only problem I find with this decision is when I make an improvement/fix a bug on a dependency, and the project is either inactiv…

    The only problem I find with this decision is when I make an improvement/fix a bug on a dependency, and the project is either inactive or the authors don't give a crap about your work.
True, but I think a temporary fork, which will eventually be merged back in, is still better than your own code with its own bugs.

Re: Kill Your Dependencies

#225

Post by EvanPlaice »

aidenn0 wrote: post #192

Slightly related, I was packaging up a webapp in docker, and one thing the application did was form-fill PDFs. I had been using pdftk to do this, but it turns out pdftk is written in gcj, and gcj pulls in a lot for its runtime libraries. I wrote a small program using the mupdf libraries and cut the size of my docker image by over 400MB.

Congrats, you just violated the GPL. You were already violating the proprietary license if you're using his for commercial purposes without paying.

Not all free software is free.

Re: Kill Your Dependencies

#226

Post by aidenn0 »

EvanPlaice wrote: post #225
aidenn0 wrote: post #192

Slightly related, I was packaging up a webapp in docker, and one thing the application did was form-fill PDFs. I had been using pdftk to do this, but it turns out pdftk is written in gcj, and gcj pulls in a lot for its runtime libraries. I wrote a small program using the mupdf libraries and cut the size of my docker image by over 400MB.

Congrats, you just violated the GPL. You were already violating the proprietary license if you're using his for commercial purposes without paying. Not all free software is free.

Actually mupdf uses AGPL, and so the program I wrote and linked with mupdf is also under AGPL.

Re: Kill Your Dependencies

#227

Post by aidenn0 »

EvanPlaice wrote: post #225
aidenn0 wrote: post #192

Slightly related, I was packaging up a webapp in docker, and one thing the application did was form-fill PDFs. I had been using pdftk to do this, but it turns out pdftk is written in gcj, and gcj pulls in a lot for its runtime libraries. I wrote a small program using the mupdf libraries and cut the size of my docker image by over 400MB.

Congrats, you just violated the GPL. You were already violating the proprietary license if you're using his for commercial purposes without paying. Not all free software is free.

I just saw the commercial redistribution clause for pdfTK if that's what you're talking about. It does not affect me since this was not a commercial application, but it would seem to me that that clause itself is a violation of the GPL, since pdfTK links to GPL software and it is also a contradiction of a separate place on the site that claims the same software is licensed under the GPLv2. Preventing commercial redistribution is not compatible with the GPL.

Re: Kill Your Dependencies

#228

Post by superuser2 »

endemic wrote: post #149
LukeB_UK wrote: post #137

I disagree, and this quote I've seen floating around the internet sort of sums the idea up to me (albeit with a music analogy): > I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned…

I don't think that's what he's advocating: he's just saying that every dependency you have is another thing you have to worry about, so why not try to limit them as much as possible? Obviously it's impractical sometimes, and that's OK, as long as you understand the consequences.

Every line of code you write is something you have to worry about. Every dependency you use is something that (in theory) other people are also worried about.

Re: Kill Your Dependencies

#229

Post by jononor »

sargas wrote: post #222
allendoerfer wrote: post #12

To me, this seems more like an argument for optimizing beyond your own stack. Don't kill your own dependencies. Your app uses to much memory? Improve a dependency, you have now improved other peoples apps, too. Your app uses to much dependencies in total? Try to get all your first-level dependencies to standardize on the best http-client. (Which he is partially doing with his post.) Dependencies may have problems, bu…

I agree 100% with this. I used to bring in dependencies with the "don't reinvent the wheel" mentality. Then I realized how much trust I'm giving to the authors of all dependencies I pull in. Now I tend to do my best to understand the dependencies I bring so I can improve them if I can. The only problem I find with this decision is when I make an improvement/fix a bug on a dependency, and the project is either inactiv…

If you try an fix a kib
Post reply on HN