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