[tangentstorm]

> Even though you aren’t writing the 3P code yourself, by including it in your project you are committed to understanding it—and refreshing that understanding if you want to upgrade it.

This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try.

Obviously, a subset of really talented users eventually learn to understand the framework, but most are at its mercy.

Even then, you can't study every possible framework before choosing one to master - there are too many, and the cost of understanding the foreign code is simply too high.

So I suspect that in general, people try frameworks by taking a leap of faith, and then, sometimes, make the effort to actually understand it later - if and when it becomes necessary.

[alexpetros]

The main point I'm trying to make here is that even if you're in the "leap of faith" category, you still on some level have to understand the framework constructs (i.e. its API) in order to make use of it. If that API changes with a new version, and you want to upgrade, you're going to have to learn enough about that new API to make the upgrade.

Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.

[briantakita]

> Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.

This is a problem that grows with a large library...An api change has a higher cost than with a smaller library. Smaller libraries also tend to be easier to fully understand. Large libraries tend to be more of a "leap of faith" than small libraries.