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"

> Is it an argument against wrapping frameworks, or wrapping libraries?

I think English is not OP's first language, framework here basically means wrappers.

> 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.

Frameworks abide by the Hollywood Principle and the Greyhound Principle:

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

Leave the driving to us.

Let me introduce you to development on Apple platforms, where "framework" is literally the term for all libraries since the NeXT days.

imo it's better to just figure out the definition in the current context, than try to force your own definition unto others. You can't anyway.

> 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 framework is some kind of application scaffolding that normally calls you.

This. A framework relies extensively on inversion of control. It provides the overall software architecture of an application, and developers just inject the components called by the app to customize some aspects.

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.

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

Is an `EventEmitter` a framework or a library?

The word "concept" here is doing extreme amounts of heavy lifting here.

If I had to bring the point home I'd say that the author himself committed the very mistake he is warning against in that very sentence.

Frameworks define conventions and non-language features (language feature=data structures, callable functions, etc) that cannot be expected to be understood by simply reading the existing code and therefore need to be learned explicitly by reading the documentation of the framework. Frameworks are allowed to bend rules and expectations, because you're supposed to learn and be aware of them ahead of time.

This directly applies to the irresponsible use of the word "concept". The meaning of what he was trying to convey cannot be understood based on simply reading the sentence.

> 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.