[hdjrudni]

I don't know if the framework really matters that much?

Just choose anything popular and there should be plenty of help available.

I've been using Laravel for about 11 years now. I hate it, but it keeps on trucking along so I've resisted the urge to do a complete rewrite. I don't think anything is particularly slow to develop.

It's the business side of things that's the hard part.

[_1tem]

It matters a lot. I attribute my success at running a one-man business to Laravel (inspired by Rails). Having a batteries-included framework designed to support high-level business goals reduces so much cognitive load and the amount of code you need to write. Previously I had 10+ years of experience writing apps in basic Python frameworks like Flask but I would need to spend far more time writing code to implement basic features. Another thing that drastically reduces complexity is having the backend and frontend in a single codebase. In Rails that is achieved with Turbolinks and in Laravel it’s done with Livewire. It reduces code complexity by a factor of 2x at least (in practice it’s like 10x simpler compounded over years of maintenance).

[Capricorn2481]

I can't say, as a PHP dev, I'm more productive in Laravel. It's easy until you really need to know how things work. I know plenty of people are productive in it, but I think a light framework with an ORM is so much more palatable. Though I haven't completely given up on Laravel

There's such a high churn to the ecosystem and the way things are wired together, I feel like a beginner every time I use it. Volt is really bad. I need to be clear, it's really bad and adds nothing. We had a separation of concerns, then we had backend logic in Livewire components with Alpine JS, and now everything is in the view again, only with a Frankenstein of all three options. At best, its introduction is change for the sake of change, and at worst, they are trying to make deployment "complicated" to drive adoption to their paid offerings, which are marketed for managing this complexity.

It's easy to have bugs, in general, that are hard to catch due to way things are wired. I think Filament is good tech, but I had a lot of issues using Filament on Laravel 12 with Volt. There was a big impedance mismatch and figuring out why my layout was suddenly broken when navigating to the admin page, in a brand new app, was not fun. That should not be the experience. It should be obvious how things are wired together.

And while I'm definitely not a Laravel ecosystem expert, when I have an issue, I have had to explain how Laravel works to others who bill themselves as experts. I don't think it's because they're fake experts, I think it's because Laravel is so hard to "know." There's so much opaqueness with the OOP magic strings and dynamic calls that people have had to make assumptions on how the code is run. And you can maybe get far doing that. But if you're unlucky enough to run into an issue, you're at the mercy of some poorly laid out (but verbose) docs to find out why a certain bug is happening.

[_1tem]

Agreed that Volt/Mix is bad, but I haven't touched it since setting it up the first time. It doesn't bother me day-to-day.

I try to avoid hacking the framework or needing to know it's magic. The point of an opinionated framework is to just do things their way. This works for me 95% of the time. The few times I need to do something non-standard, I don't mind spending time hacking.

It sounds like you're building a lot of new projects in Laravel rather than maintaining a single one over the years.

[bhu1st]

For these same reason I hand coded a router with Psr4 autoloader which does work for my projects. Most clients I work for never ask for Laravel or anything specific, they just want the business logic working.

[Maledictus]

When I moved from PHP to Ruby (and Rails), I discovered how much fun programming can be. Ruby just optimizes for the right thing, Developer happiness.

[sethammons]

I have heard that for years and I just don't get it. Magic abounds. The test assertions and testing libraries are whole DSLs that require a separate/additional learning process with inconsistent chaining with inconsistent return types. Being able to overwrite anything in the language gives rise to things like unicode whitespace being misinterpreted as an undefined function. You can define methods by combining method names leading to wholly undiscoverable methods because "my_func_that_is_cool" is actually defined over multiple files, combining my_func and that_is_cool; saw this a lot in our chef cookbooks. Ruby requires mountains of tests (thus the DSLs). Knowing ruby and knowing rails and knowing how to test are different things.

I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.

I assert Go leads to org happiness, letting teams work together productively.

[gls2ro]

I am not trying to convince you as you are already decided and your experience and feelings are valid. I think different programming languages can fit to different people and there is no bad choice here.

For anyone else reading this and considering Ruby I have to say the followings:

1. No, there is no magic in Ruby but there is flexibility and metaprogramming. Everything that appears magic is allowed by Ruby syntax and can be traced down to a few meta programmimg features. It might be hard to get it when you see it first, but please do make sure you understand Ruby and then you will also get the magic.

2. You can choose to use Minitest (which is Rails default testing framework) instead of RSpec and Minitest is Ruby code with few methods for assertion.

3. Mocking is an important part of testing

4. In any programming language and even agnostic of any programming language knowing how to code is different than knowing how to test. The testing framework is just an abstraction that should translate your test cases into executable tests.

[Lukas_Skywalker]

I always thought it was funny that people criticize the "magic" of certain frameworks, when at its core, almost all programming is magic (since it is almost always an abstraction). And there is probably no clear distinction on where non-magic ends and magic starts.

But somehow, no one complains about having a GC instead of needing to use `malloc`/`free` or `fetch` doing the DNS query automatically.

And that's exactly _why_ I use frameworks and libraries. So I don't have to write low level code, or as one could call it, to use some magic.

[AstroBen]

Magic isn't just abstractions. Ruby magic tends towards meta-programming and making as much behavior implicit as possible (a lot of this is cultural). Things that tend to make it fun to write but hell to debug

[marcosdumay]

As much as I really hate the Ruby magic, I have to say, it's always about doing the right thing, at the right time, for the right purpose. Even more on the kind of magic Rails use.

I personally can't handle it. It's completely frustrating. Nothings documents what your system is doing, and nobody on the community seems to have an inch of clue about what exactly is happening on their computers. But you can't deny that it works, and works well... unless you need to override something due to a niche use-case.

[TiredOfLife]

Maybe that was true for PHP before 7. For me php make sense. Ruby on the other hand feels like it was made by an alien who learned human language by reading books that were shredded to pieces and glued together randomly

[alpha_trion]

If you hate it, don't torment yourself....make a business case to switch. Better developer productivity is a thing.

[gamblor956]

Developer productivity is overrated.

Billions of people deal with slow web apps that collectively waste millions of years of people's lives so that the a few developers can save a few hours of work.

We could increase global white collar productivity by 10-20% almost immediately if developers would stop valuing their productivity over the productivity of their end users.

[julik]

I have worked on quite a few Ruby web apps and built quite a few myself. Maybe 3% of the cases I encountered were about Ruby not being performant enough to do what I needed it to do. Where did the rest of the productivity of end users get lost?

Org dysfunction.

Note that those were web apps - so the user did not have to install the runtime, dependencies etc. to use the software. That is a whole other story (and not a very merry one, at least for all the scripting languages out there).

[charlie0]

I find this funny because I'm sure you can find examples where users themselves demand things that are overall less efficient. But, you're not wrong, there are efficiency gains to unlock on both sides.