Framework or Library

What is the difference, and should we care?

A framed view of the French National Library
A framed view of the French National Library

Libraries

A library (“bibliothèque” in french, but most french people say “librairie” which actually means “bookstore” in french, but matches the english pronunciation of “library”) is a set of functions for general purposes (like underscore.js) or specialized ones (like moment.js).

Using a library is performing a imperative call to it

Proprietary calls

As a dependency, however, they require you to call their proprietary API, thus “locking” your code with them (or even possibly a version of them), so that a library call should rather look like this:

In reality your code depends on library’s API
The more you call the library, the more your code is “polluted” with proprietary calls

Single point of dependency

To limit such a dependency however, you can hide it behind a wrapper:

Using an adapter keeps your calls library-independent

Business API

Hopefully, as the late David J. Wheeler used to say:

Referring API interface instead of implementation allows to keep app code independent
  • callers will depend on that API declaration ;
  • the adapter will have to implement it (note that this would also ease mocking libraries when testing).

Frameworks

Frameworks (“quadriciels” in official french, but everybody says “framework”) are different, as they provide a different type of service: they offer to manage things for you, instead of letting you devise what to do.

Handing over control

To do so, they implement the backbone (the “frame”) of an application, and let you fill the blanks. But those blanks are left in defined places and have defined shapes.

  • the app starts with the framework: you have to hand over the steering wheel.
  • since the framework drives the app, you’re not the one making calls anymore: instead, you will be called back by the framework when appropriate.
“Don’t call us, we’ll call you”, a.k.a. the Hollywood principle

Contracts

Of course nothing prevents you to manually call some code of your own, a third-party library or even some framework API, but at your own risks. This may or may not work as you expect. Frameworks have rules that you are supposed to follow and, should you break them, the framework could not be accounted responsible for any failure.

Every component is required to comply with the framework’s contract.
Insulation of framework components make hardly a difference

Framework libraries

Libraries can also comply with frameworks. Instead of providing an API, they provide components implementations for a given framework.

Standard frameworks

Anybody can imagine the tremendous cost of porting the same library (and its subsequent versions) on each of those frameworks.

The web component is just part of the framework component’s view
Web components can be inserted as tags even in simple web apps

Conclusion

Frameworks and libraries are very different third-party options:

  • frameworks provide you application blueprints with built-in services but enforces predefined contracts to call your code. As such, they imply a strong dependency.
  • libraries won’t help you design your application, but can be called only when you need them. You can devise a design that limits dependency to them.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store