Comment by barrkel

If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology.

The promise is to simplify and unify things but as noted, such efforts often have the opposite effects.

"Teams are struggling with properly adopting FooTech - our FooBarTool wraps it in a beautiful package and magically solves everything with a single command and one config file"

"We should template all this yaml"

Frameworks abide by the Hollywood Principle and the Greyhound Principle:

Don't call us, we'll call you.

Leave the driving to us.

> Wrapping libraries makes a lot of sense

The best assumption to start with is that adapters are bad by default, because they are an unnecessary layer to maintain (and potentially a point of failure and bottleneck depending on what they are and do). Then, make the argument for the adapter as a guilty until proven innocent case.

If you can make a solid case for it, fine. There are many solid cases for adapters, e.g. drivers for a database or hardware.

Never write an adapter that you can handle more scalably, flexibly, and almost as easily by calling something directly.

It's the same with app, application, program, software, tool, etc.

these things are hard, maybe impossible to define.

For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.

Is an `EventEmitter` a framework or a library?

> A library is something you call. > A framework is some kind of application scaffolding that normally calls you.

I think I broadly agree with this. In essence, libraries don't impose an application-level life cycle. Frameworks, generally, do.

The rest of the article, I don't know….

The most successful, long-running app I maintain has a mini-framework that allowed me to assemble what I need piecemeal rather than relying on any off-the-shelf framework that would have been obsoleted several times over in the seventeen-year lifespan of this code.

I guess about one in three things I do in it require me to dip into my framework code to look at it, but this is mostly to remember how it works! About one in five things have required me to make a small progressive change.

Twice in its lifetime a core component has been swapped out (mailer and database library).

And twice in its lifetime, because it is beginning to converge on a general web framework, I have considered porting the code out of it and into a general framework, which might make it easier to hand over. One day, I suspect, something will break compatibility in a way that makes that the sensible route, but the code works, fast, has a pretty obvious set of abstractions, and there are implicit examples of everything it can do in everything it already does.

Almost all articles like this start out with "here is a thing I claim is a generalised problem that I am sure you should not do", that is a well-meaning but false generalisation, and is then caveated to the point where no new point is being made.

Underneath they are always: don't write bad code. If you do, learn from it.

If I'd followed the advice of this article when I started this project, I would by now have rewritten the entire thing more than once, for little gain.

Much more concise and much more sensible: consider whether your additional levels of abstraction have value.

But do mini frameworks have value? Sure they do, especially if there is setup and teardown that every function needs to do.

> A library is something you call.

> A framework is some kind of application scaffolding that normally calls you.

There is no real distinction between these two.