I came here to say that, as someone who's used both Rails and Laravel. Basically it comes down to magical behavior, and the fact that Rails has way too much of

I came here to say that, as someone who's used both Rails and Laravel. Basically it comes down to magical behavior, and the fact that Rails has way too much of it. Syntactic sugar and DSLs are maybe fine for rolling out new projects, but become burdensome on large codebases. I was on a large project and found myself in goto hell where I literally couldn't trace through the code. It was relying on every magic trick in the book to make the code as small and cute as possible, but failed utterly to provide anchors in the code where "this happens here" or breadcrumbs connecting chunks of code. It was a giant hodgepodge of I don't know what. Really clean spaghetti code I guess. Now, Laravel has its own warts, but they aren't conceptual warts. For example, the stack traces in Laravel are way too tall, with way too many factories and patterns in the vendor code. I feel that things like the IoC container were not implemented as well as they should be. The goto hell in Laravel happens around stuff like the bootstrap process, registering service providers, queuing, etc. They made some mistakes in scattering those things around instead of handling them in one central place. Pretty much all classes provide 95% of what you need, but adding missing functionality yourself requires learning the entirety of the package (in fairness, this happens with pretty much all platforms). There's a tendency for Laravel projects to not support helper functions or custom classes in a standardized way, so sometimes it's hard to find business logic. Not nearly as hard as in Rails though. But as a whole, I'd take conceptually clean interfaces with mundane implementations and no surprises over magical behavior any day. Just to not leave anyone out - I wouldn't implement business logic in any Javascript framework. I feel that async basically makes it impossible to do it deterministically. I'm sorry that happened to Javascript and am still in mourning about it, because it had some advantages over PHP in how it treated associative array access with "[]" the same way as object member access with "." which could have been used in PHP to implement copy-on-write everywhere and really set it apart from all other imperative languages. Mistakes were made in both, and Ruby as well, that took them all in directions that I wouldn't have chosen.