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

121–130 of 229 posts

Re: Kill Your Dependencies

#121

Post by skybrian »

mwcampbell wrote: post #112
skybrian wrote: post #96

Earlier quoted context omitted.

Tree shaking is helpful but not enough. It makes dependencies more fine-grained and binaries smaller by removing some false sharing. But library maintainers still have to be careful about true sharing, where a function calls another function, which in turn pulls in something big (like a lot of data stored in a constant). You need both tree shaking and a community dedicated to keeping code small. Javascript has the la…

You're right; tree-shaking doesn't eliminate all instances of dependency bloat. Come to think of it, I've even seen a counter-example in C++. On Windows, a hello-world application using the wxWidgets GUI toolkit is ~2.4 MB, even statically linked. I think the problem, or at least part of it, is that the WindowProc implementation uses a big switch statement to handle all of the Win32 window messages that wx supports.…

Yes, UI frameworks are especially prone to this. Anywhere you have generic "display arbitrary thing on the screen" functionality, it logically depends on all the code you might need to fulfill that promise for arbitrary input.

Custom HTML tags typically can have arbitrary children, so the issue inevitably comes up. The reason a normal web page can be small is because the browser has already been downloaded.

Re: Kill Your Dependencies

#122

Post by jbergknoff »

alexose wrote: post #119
BinaryIdiot wrote: post #25

This is a great read that can be applied to node.js very much. I've seen apps that include 10, maybe 20 dependencies but when you flatten out the full dependency tree? Thousands. It's incredible and if one of those dependencies screws up semantic versioning or just screws up in general it can be a nightmare to debug and fix. This is why every 1.0 product I work on I include every dependency that speeds up my developm…

The worst offender, IMO, is request. I've seen more than a few projects pull it in just to make a single HTTP call. Just look at its package.json: https://github.com/request/request/blob/master/package.json

Yes, the npm "request" module is extremely bloated and badly written, to boot. https://www.npmjs.com/package/needle is a good alternative.

Re: Kill Your Dependencies

#124

Post by hassy »

alexose wrote: post #119
BinaryIdiot wrote: post #25

This is a great read that can be applied to node.js very much. I've seen apps that include 10, maybe 20 dependencies but when you flatten out the full dependency tree? Thousands. It's incredible and if one of those dependencies screws up semantic versioning or just screws up in general it can be a nightmare to debug and fix. This is why every 1.0 product I work on I include every dependency that speeds up my developm…

The worst offender, IMO, is request. I've seen more than a few projects pull it in just to make a single HTTP call. Just look at its package.json: https://github.com/request/request/blob/master/package.json

I'd argue the offending party is the library pulling in Request for making a few simple HTTP calls.

Request itself in my opinion is a great piece of work, it does pretty much anything one would want to do with an HTTP client.

Re: Kill Your Dependencies

#125

Post by twic »

Does any of this sound familiar:

- Test gems loading in production.

That does not sound familiar! Is this a thing which happens with Rails?

Re: Kill Your Dependencies

#126

Post by nona »

twic wrote: post #125

Does any of this sound familiar: - Test gems loading in production. That does not sound familiar! Is this a thing which happens with Rails?

No, but sometimes people are a bit careless in their Gemfile I guess.

Re: Kill Your Dependencies

#127

Post by maxxxxx »

pcwalton wrote: post #51
maxxxxx wrote: post #44

Earlier quoted context omitted.

The keyword is "well-tested, heavily used library'. Especially in the web area I see a lot of imported libraries from github or wherever for doing simple things. In the end you end up with dozens of dependencies you don't know how and when to update. My rule of thumb is if the stuff we need can be reduced to a few functions, it's better to copy so you at least know which code you are using and don't have thousands of…

Copying doesn't make anything better; it just insulates you from upstream bug fixes. If copying is better than adding a line to your Gemfile or whatever, then that's a usability bug in your package manager. The entire reason for package managers' existence is to provide an easier-to-use, more reliable alternative to copying.

Copying gives you stability. I work in a regulated environment so every change has to be scrutinized. Updating a library like jQuery is a big deal. If you use 10 libraries of decent size you will most likely rarely update them because it's too much work and risk.

By isolating out parts you actually need you have a better chance of making updates with reasonable effort.

Not saying this is for everybody but a lot of dependencies can be a killer.

Re: Kill Your Dependencies

#128

Post by kyzyl »

pcwalton wrote: post #97
ktRolster wrote: post #87

Earlier quoted context omitted.

It doesn't matter. If I were Einstein, and von Neumann disagreed with me, I would take that seriously, even though I were a super-genius etc.

I do take it seriously. I'm no super-programmer. Rob Pike is a better programmer than I am. I just disagree with him on this one thing.

Deference to authority is a funny thing eh? I find that in life, and especially in running my business, I pretty frequently lock horns with people who disagree with me on account of a seemingly differing opinion of some other Experienced Person(R). It's like, such and such person has lots of experience in the industry, therefore they know the answer to this specific question better than you do, regardless of anything. When I hear these appeals to authority I always think that if I were actually sitting across the table from this Very Smart Person--as opposed to the person citing them--and they were willing to listen, we would probably end up in agreement. Like you say, the person might be WAY smarter than me in general, but... LOOK AT THE FUCKING DATA.

There's a reason smart people are good at solving problems, and it's not because they always defer to what other people 'know' to be true!

Re: Kill Your Dependencies

#129

Post by mbrock »

jermo wrote: post #81
mbrock wrote: post #45

Earlier quoted context omitted.

There's an important kind of compromise that isn't discussed as often: using an external library but behind an interface of your own design, an "anti corruption layer". If the external dependency is limited to one small bridge in your application, then it's so much easier to see what parts of the dependency you actually depend on, to upgrade the dependency when its API inevitably changes, to replace it entirely if it…

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 we're on an old major version of it and upgrading would require changing hundreds of locations. When very many files in a project mention the same external dependency, that seems like a recipe for future sadness.

Re: Kill Your Dependencies

#130

Post by jowiar »

Aeolos wrote: post #64
jowiar wrote: post #55

Earlier quoted context omitted.

Also, this is probably the single biggest difference for me when working with a static vs. dynamically typed language. With Static Typing, there's a "translate the dependency's types into the application's types" step that pretty much screams "put a seam here!". With Dynamic Typing, it's a bit less loud.

That's pretty much a C/C++ problem though. I don't think I've ever had to translate types in C# or F#.

I was referring to that, with Scala, I like to avoid leaking the innards of a JSON serialization library in the code for an API client, instead returning domain objects. Whereas with, JS or Python, the initial approach is to sling around the blob of JSON.
Post reply on HN