Sorry, I don't accept this very mechanical definition; not only is it a needlessly narrow one, it's downright meaningless in some paradigms, such as when implementing coroutines via continuations, but that doesn't mean you can't have frameworks in Scheme. Conversely, we could describe tuplespaces (a la Linda), or many event- or interrupt- driven systems (like an Ethernet port), as an inversion of control, but whether they're frameworks or not would be an open question, and indeed in the end almost everything happening inside a modern computer consists of one element calling back to another, up and down a stack.

Heck, it's not even true of some of those specifically called out in the article above. For example, I've written programs that use Rails as a library - or rather, suite of libraries - of functions and classes to be called, but anyone suggesting that Rails is somehow "not a framework", on the flimsy grounds that it did not dictate the flow of control, is gonna get some funny looks at morning standup.

But the greater problem is that narrow, mechanical definitions omit purpose, and talking about software without purpose being front-and-center becomes rapidly theological. If you're wondering what I mean by that, look up the wikipedia article for "Software framework", scroll through its desultory talk page, and recognize the inevitability of the boilerplate it got stuck with: "This section is written like a personal reflection, personal essay, or argumentative essay that states a Wikipedia editor's personal feelings".

I‘d say Rails is a combination of framework and libraries.

Some parts (ActiveSupport, the part that simplifies e.g. date calculations) are clearly libraries. They can be used outside of Rails as well, because they totally ignore the shape of your other code.

Other parts (ActionPack, the component that calls your code depending on the incoming web request) are working like a framework. Your code must adhere to their requirements, otherwise it won‘t work.

I think it might be better if instead of trying to redefine libraries and frameworks we instead used the terms impure application(frameworks) and pure application(libraries). That would make it evident as to which libraries are actually tainted with impure work and need to be redefined as impure.

When you extend this pure/impure idea all the way throughout the computing eco-system, it quickly becomes apparent that something went wrong a long time ago, and every-time, instead of untangling the mess that is pure and impure into their own buckets, we find a way to run a framework in a framework.

What is an Operating System? What is a container? What is k8s? What is a Programming Language? What is a browser? What is a website? What is next?

I'm not saying that I gave the perfect definition of a framework. But if anything the original definition is even worse or less meaningfull.

Also, it is certainly possible to have a mix of a library and a framework where parts use IOC and others don't. Maybe that's try for Rails (never used it) and that's where your confusion comes from?

> this very mechanical definition

One of the most useful definitions I found was from Luciano Ramalho, the author of Fluent Python (and so many other cool things). According to his insight, a framework is something that calls your code. A library is something your code calls. Frameworks are more rigid things that force structure on your functionality. If the structure it imposes is good, then your code will be good.

Their scope is also tailored to the languages they support. As you pointed out, different languages will have different needs.

I don't agree with this simplistic distinction between framework and library. There are plenty of libraries that call back into user code. A better definition might be that a framework imposes an entire 'application model' on you, and trying to step outside that predefined model is at your own risk, while a library is a much smaller and flexible building block (also a building block for frameworks).

But there's a large gray zone between these two, and eventually the distinction is also often quite pointless in the real world.

Another, a bit less gray zone, distinction is that you can have only one framework in your program, but can use multiple libraries.

In the Java world, at least, you can absolutely have multiple frameworks in your program.

You can have multiple programming languages in a program, so of course you can have multiple frameworks.

I think the last sentence is really true. And yes, there are libraries that call back into user code, which makes them framework-like in this regards.

> A better definition might be that a framework imposes an entire 'application model' on you, and trying to step outside that predefined model is at your own risk

This is the kind of definition were 50% will call something a framework and the other half will call it a library then. Not sure if that is really helpful.

This kinda suggests that most node modules are in fact frameworks, in that they accept callbacks.

Callback hell however, is not something I'd associate with a framwork

Yeah, if this is not just an once-off async callback (where you could just use a promise) but somthing more complicated, then this is indeed more framework-like and for me would be a reason to try to avoid it.

> then where does "abstracting things" and "framework" start and end?

It doesn’t. If you abstract things enough there is your framework.

The only things I’ve seen that were truly without a framework were raw php files that did everything contained within that single file. And even these had headers that combined some common functionality.