I have seen a lot of libs out there, but in general I can see two directions: On the one hand, libs which are very small and focused. They do one thing, but they do it well. It's a little bit like adhering to the Unix Philosophy.

On the other hand, there are more and more big libs, which try to do more and more under the hood, basically being like a big black box you use and which does a lot for you, often even auto-magically.

What do you prefer? Why? In which situations? What do you think about prototyping using big libs, but then creating very lean applications with small libs? Would you get the time for that?

Big libs with everything I need

Minimal libs, which focus on one thing

Write your answer…

5 answers

It depends.

Some advantages of small and focused libraries:

  • Small components may be reusable. That's the big one.
  • Code size is small, so perhaps the deliverable is too (although you could probably do dead code removal as part of compilation, especially in static languages).
  • Code size is small, so it'll be easier to understand it.
  • Less code means less trust is needed, e.g. for security.
  • It encourages creating a common infrastructure that others can build on, e.g. pythons numpy or linux streams or js events.

Disadvantages:

  • Some things are hard to split, e.g. unicode support.
  • It's administration overhead - more repos, more versions, more interdependencies...
  • It's annoying to pick the parts you need. Most people will just end up using packages of many small utils.
  • Integration may be worse, e.g. a web server framework that comes with an ORM and router and template engine is more restrictive, but perhaps more symbiotic than a pluggable one.
  • Having hundreds of small libraries could be confusing for users (although with a decent package manager it needn't be).
  • Small libraries that are reused may conflict if they have different versions (although with a great package manager they might not).

It's all kind of a spectrum. Is "json encoding for all the most common types" doing one thing well? Is "all of regex" doing one thing well? Is "collection of useful stream operations"?

I considered making lexing, parsing, code generation etc separate packages for my compiler, but in the end I didn't, because they're mostly useless in isolation.

Often users can get the best of both words with packages that give a unified interface using independent components (kind of a Facade pattern).

I think in many cases, the ideal system for open source projects is like:

  • A package with shared infrastructure (usually mostly interfaces or data types). Or several if separable. Should be very stable. E.g. streams.
  • Many small inplementation packages that depend on the infrastructure. E.g. cat, grep, sed, wc... Mostly for other developers.
  • A few (nested) collection packages that fairly directly expose many independent components, possibly with a little integration logic. 90+% of end users will use this.

One more disadvantage: if all the parts are bundled, it'll be harder to change to another library, because you'll have two big dependencies, or a very big change. It'll also be harder to find a suitable replacement if the scope is large.

Reply to this…

Hashnode is building a friendly and inclusive dev community. Come jump on the bandwagon!

  • 💬 A beginner friendly place

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 >500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Register ( 500k+ developers strong 👊)

Actually you’ll need both for a healthy mix, even in smaller projects. Otherwise the application will tend to reflect to have the same disadvantages as the framework you’re using.

I prefer the smaller ones if possible. Rather simple logic ... less code, less possible bugs. :)

Small, focused helper functions that can be combined with any number of other functions, in any combination.

The downside to bundling them all together is if you only want to use one part of it, you have to start making decisions about what to do with the code you intend not to use. Tree shaking? Custom build? Import anyway? With ES modules does it make sense to have to download a giant file only to read one function from it? etc.

I think, especially with the nature of JavaScript modules, that single-function helpers are probably the most flexible.

But, you raise a good point as well, sometimes there's a theme that ties a number of helpers together around a common task, a common purpose, or a common functionality. What are ways we can package up and market sets, series, or families of plugins together in a way where they can be used independently from each other too?

Somewhere inbetween. I appreciate large do-everything libraries, but they're too large and include many many things I don't need. Small unopinionated libraries without enough things aren't very helpful either. I need a certain balance between the two.