[narvidas]

As a rule of thumb, "magic" is a code smell. Libraries should be preferred over frameworks whenever possible.

A toolbelt of small utility-like composables are often easier to maintain and reason about. This results in added explicitness (i.e. less magic, fewer surprises).

Personal experience shows that the immediate efficiency gains of a framework often get diminished in the face of all the hacks people introduce later, just to work around the remaining 10% of cases that the framework did not anticipate or traded-off against.

Please note this is a comment based on personal experience and professional preference.

BOCTAOE.

[Lukas_Skywalker]

I don‘t like dismissing technologies on the basis of being „magic“, since the magic could often just as well be called abstraction, and the line between them is often personal preference.

The abstracted-away logic in a Laravel application can either be called magic or abstraction, but so can the optimizations of a database query planner.

I think often you still need to know the underlying mechanism, but it is still useful to get the innards out of the way.

[senbrow]

It's useful to get "glue" code out of the way while building, but to the point in the article it all becomes very difficult to debug and maintain once there are problems in the that layer.

Spring Boot and other similar frameworks come to mind; by forcing huge amounts of indirection you lose a lot of visibility of your call stack because the convenient "glue" code is now orchestrating everything at runtime, but that code isn't yours, and it isn't easily inspected or fixed.

[hasley]

The problem is not the abstraction itself.

The problem is that your code has to work within this abstraction and can only solve problems covered by the inventors of the abstraction.

[hasley]

In case "framework" is understood as something that calls my code and that forces me to write my code in a certain way, I totally agree.

And I think twice before I use a framework. Frameworks enforce a certain way of programming which you can never be sure to match the problems you will have to solve in the future. Libraries don't do this - at least not to the extent of a framework. Libraries are composable building blocks.

Nevertheless, there may be applications where frameworks are beneficial (e.g. GNU Radio).

[wouldbecouldbe]

I remember using Laravel a while back and it had quite some magic but it was done right and made a lot of things much easier

[chrisweekly]

I had to look up BOCTAOE (But Of Course There Are Obvious Exceptions)

"Good magic decomposes into sane primitives" highlights an essential distinction: not all magic is bad (but it's not always clear at first which kind of magic is in play).

[boxed]

> Libraries should be preferred over frameworks whenever possible

You have to define the terms.

It's not clear how your statement above isn't semantically equivalent to "prefer good over bad" or something otherwise nonsensical.