[kwhat4]

This is one of the primary reasons most people hate PHP. Let me ask a simple question: What does the documentation for your homegrown framework look like? Having worked for several organizations that decided to roll their own framework in PHP, it is an absolute nightmare. No one else knows how it works or how to use it and it usually comes with no documentation. Furthermore, you don't get any updates or bug fixes unless you write them, taking time away from working on the project that is being held up by your homegrown solution. There are plenty of fast, low bloat, PHP frameworks to choose from: Phalcon, Slim, Luman and Silex just to name a few. I guarantee they all have better documentation and support. If you need some custom functionality, extend one of these existing solutions to suit your needs. Please, please stop reinventing the wheel for production code.

[helldritch]

I agree with everything you've said, with the exception that it doesn't fit our usecase.

We run and maintain several Symfony applications, we're very familiar with frameworks, how they work, their strengths and weaknesses.

This was a carefully considered route:

We wanted to be writing PHP code with high performance and strict response time requirements, as such:

* Symfony was instantly ruled out.

* We knew we would struggle to do this with raw PHP but didn't want to retrain the team to learn a new language (our thinking being we would likely write something inferior and insecure).

* We considered Phalcon and Swoole and ultimately decided on Swoole as we found Phalcon a bit too opinionated. That being said, Swoole's documentation isn't great so we've had to internally document it. (We will probably push a few documentation PRs for swoole-src when we're done).

* We didn't trust a big framework to have zero memory leaks, which is a key issue for long running Swoole processes, since it's not a typical issue for the single-use PHP processes we are used to.

With regards to documentation, it's very well documented (with documentation explaining the reasoning behind each class, usage, pitfalls and how it fits in to the larger application, and documentation for the wider ergonomics of the application, debugging, performance considerations, etc), with a 96% test php-unit coverage for the Framework.

Your concerns are very well received and are concerns we have had from the beginning. Constant vigilance and a deep respect for my co-workers is what keeps this little project on the straight and narrow.

[tiborsaas]

What were your constraints in performance? I'm surprised Laravel is considered slow.

Have you considered sticking to it and applying some caching layer on top of it?

[chipotle_coyote]

I would actually argue there's a good chance the person you're replying to is "doing it right":

- they're using Composer packages

- they're using the fairly well-documented, popular Fastroute for routing

- they're using the well-documented, PSR-11-compliant PHP-DI dependency injection container

- they're using the well-documented Swoole for async programming

In other words, they're rolling their own framework not from scratch, but on top of well-understood components that largely follow -- and largely require programs that use them to follow -- what's considered to be "best practice" in the PHP world.

I get that there's a lot of crap PHP out there, historically, and that frameworks have helped dramtatically reduce that. But it turns out you don't actually have to start with a framework in order to write well-structured, well-commented PHP code -- you just have to have a commitment to doing it.

I'm working on my own PHP microproject right now and I'm pretty flagrantly violating some "PHP the Right Way" conventions; the project doesn't even Composer and -- horror of horrors -- the autoloader isn't technically compliant with PSR-4. I'll pause for everyone to recover from the fainting spell. I don't think anyone else is going to ever have to maintain this -- but I'm also pretty sure that when I'm finished, it will actually be more understandable and maintainable than some Symfony and Laravel projects I've worked on in the past. It's not the fault of those frameworks that people build inscrutable undocumented modules on top of them, but it still happens.

And frankly, I understand why someone can appreciate Symfony and Laravel and friends and still say, "Wow, that's... just... a whole lot." (If you initialize a new Symfony 5 project, before you have written a single line of your own, your project is already at around 160K lines of code.) And they can look at microframeworks, especially modern we-must-comply-with-all-PHP-FIG-mandate ones, and say, "That isn't a whole lot, yet it kind of feels weirdly heavyweight for what comparatively little it does."

> Please stop reinventing the wheel...

You learn a lot by reinventing a wheel. Sometimes what you learn is that a lot of the existing wheels are actually monster truck tires, tank treads, or jet skis.

[juangacovas]

Friend of mine. Slim framework not updated anymore. Cannot make it work in recent php versions, so a fragment of a big corp needs to be maintained and isolated. I know, happens everywhere

[chipotle_coyote]

If you mean the framework named Slim, its last point release, according to their web site, was less than a month ago, and it says that the minimum PHP version requirement is 7.2. It's possible your friend isn't able to upgrade the application to a supported version of Slim?