PHP Frameworks Discussion (beware lots of opinions)

devmazee2057282 profile image dewbiez ・1 min read

I prefer either Phalcon, or modular with independent composer packages that are not coupled to others. I did Laravel development for a while, but I couldn't seem to get the performance I wanted out of it.

What about you?


markdown guide

I don't use frameworks unless I wrote them myself. Debugging other people's sufficiently complicated code can eat too much time.


Enjoy writing everything in assembly.


You have it the other way around. Making code in a framework is like writing code in assembly. Where do you get off telling people that yaml (AKA json), ini files and phpdoc are more expressive programming languages than PHP?

Might have been a misinterpretation on either side.

Basically guy says they don't use a framework. You say that's like writing everything in assembly.

I give some reasoning why actually it's the reverse and a surprising way to look at that.

There's a lot of separation of theory and fact here.

In theory I know that frameworks can add a higher level that simplifies things.

In practice I find that's not been achieved. The old easier said than done.

Frameworks are trying to abstract things already on a pretty high level and intention is not the same as outcome.

As pointed out quite often frameworks even overflow the abstraction stack and you end up working in something like assembly again.

JSON (YAML) is lower level than JS and PHP for example. Programming in JSON is quite like programming in assembly. This is what certain frameworks I wont mention have achieved. Usually as a misguided attempt at configuration pattern which collapses under its own weight when you try to convert everything to configuration.

I think that's also an anti-pattern isn't it? The inner platform ring a bell or is that just me?


Aye. I prefer my own code over others. Probably because I already understand it as I'm building it. I do excessive documentation. Possibly too many comments.

I also try my best to keep my classes small. And when doing dependency injection, I use interfaces instead of concrete classes, so in the future if I want, I may switch to different adapters or something like that.

Some people have given me a lot of dirt because I reinvent the wheel. :P


If you can reinvent the wheel on time within budget and bug free, don't let anyone stop you. I was not allowed to use 3rd party code for a long time and I tried reinventing just the few wheels I knew I needed. 10 years later a dozen projects are running on flat tires that are painful to change or inflate.

What do you mean by "running on flat tires that are painful to change or inflate" ?

I mean the few components of a framework that I built were poorly built, too tightly coupled, hard to test, hard to make changes to without breaking something else unexpectedly. You speak like you have both the skill and time to make everything from scratch properly. That is great if you can. For the rest of us, a framework is a very good and necessary thing.

That's a fair point if you can't but you shouldn't detract from those who can. Nor from yourself. Your first attempt maybe meh but then I find idiot moves in the Symfony framework almost daily. Only you can save your codebase, try try again. Frameworks are good to have a bit of a fiddle with to get a leg up and learn from the mistakes of others but none are suited to production use or enterprise. They're just toys to play with and learn but there's a time for play and a time for work.

Most frameworks out their suffer the problems you report. Case in point, symfony doesn't even use their own stuff like DI. Most of their libs cannot be injected into and most use bad practices.

If you can't write a framework yourself after a bit of trial and error or iterative development then that raises questions. You still need to code and be it the framework or what you add on top it's one and the same. It's more like saying you can't code. A framework wont save you.

What will save you is realising you struggle with coding and the solution to that is simple. Practice makes perfect, not frameworks which try to steal the practice from you. Ignore their claims to best practices and aspire to perfect practices. So practice like the wind. Don't leave the nest and then freak out to the point you end up opting for wires. Liberate yourself from frameworks or petty put armbands, stabilisers, straitjackets and padded rooms. Frameworks are more like jails today so plan a break out. It wont be easy but in the long run it'll be worth it. Don't ground yourself.

I think i program like you.
My code is designed to be fast, terse, mostly procedural, highly readable, with as little abstractions as possible. ( this is PHP code )

The framework i use is one i wrote and is 1000 lines long and fits in one file.

My way of developing is fast for me. Maintainable for me. I've been doing this for 10 years. Yes, it looks like php code from 2009, but it looks like DAMN good php code from 2009.

It was never a problem until i started looking for jobs and laravel and symfony terminology kept coming up in interviews. I have not been able to get another job because i am not familiar with how these jails work.

I've tried to get into symfony and laravel multiple times. It just seems like a ton more code to write and way too many layers of abstraction. It's like you're not writing php anymore.

What i don't get is how you can work in the PHP world today without putting yourself in framework jail like everyone else.

I've considered chucking my entire php skillset out the window and learning another language that isn't ran by architecture astronauts yet.

What say you?

I got fed up with it, left two jobs in a row, took a few months off. It can have a serious psychological impact that lingers. I just wanted to go work on the farm and shovel pig... while obnoxious developers wallow in their own php... Even in a much better environment I feel tense all the time. It's not so much the conscious impact but the unconscious impact after some time leaves a stain on your subsystems. You're anticipating attack at every moment and consciously have to expend effort to put that to rest.

The 1000 line framework is definitely a thing that's been working for me.

I'm not sure if I posted my litany of complaints about Symfony here or not but that might be eye opening because they're liars, they're horrible people...

I found an old forgotten codebase on the side not needing to be changed for a long time but that now needed changing.

Symfony has this BC promise so I should have been able to update. They have a page on this promise. I update, oops, they broke BC, very obviously.

They broke this promise because as far as I can tell they don't have real world understanding of how their own framework is used or is meant to be used. Sometimes the framework is fully responsible for HTTP, sometimes not. They changed it to always include the date header in responses rather than making it configurable based on circumstances. No doubt due to growing cases of PHP handling HTTP itself. They seem to have forgot that your webserver can happily manage HTTP for you. What next, setting all the response headers? They just have a comment, the RFC says, which means psychological they're making an obnoxious appeal to authority.

They also broke the cookie handling. It always allowed invalid cookies on input because you can't always control that but would then try to validate them when you set them from the framework so at least you don't make that mistake. The way they did this was poor without very good explicit methods but it worked. They then decided things had to be consistent and input would also be validated. They should have from the start made that an option in any case and again this is the lets blindly appeal to best practices or authority stuff.

I try to downgrade to the version of the module without these changes. They broke BC again, for their own code! After tolerating the CPU and RAM composers ultra accurate dependency resolver used their version dependency settings allows me to install a module version not compatible with the rest of their framework.

Best practices? Injecting anything is a nightmare, extending things, nope not really all that easy, configurating, forget it. I was almost tempted to just pull the module into the repo, exclude it from gitignore and fix it myself. I'm left with horrible hacks and surprise surprise, after implementing my hacks I found the same hacks in their source code fixing BC breakages and letting tests pass. As in I grepped for something I added and noticed they had something of the same name in the same type of helper class, curious, I checked it, yes, they did the same. It was more than one contributor as well which makes me think it's a community of scum.

They appear to have caused another BC break by changing the accessibility of services in DI. It's hard to make heads or tails of things. I wouldn't normally be so mad about BC breaks, just peeved but when I google for it rather than just a humble, oops, we're sorry, we messed up, here's how to fix it I find nothing but self aggrandisement.

When I searched for the DI issue there's one of they yay we're so great receive the glory of our benevolent changes making best even better than best because all our comparison operators are overridden, in fact, we just go rid of them entirely! They were then saying yes you'll have to change things in this case but they love to say something like "but we're so awesome and clever that we have a magic BC layer but you still have to change things and we still didn't break BC so nurh were so awesome". That alone is just confusing as hell. If they didn't break BC, why do I have to change things? Why are external bundles now incompatible?

The worst thing is a user commented in the release blog that surely this breaks BC. Instead someone, apparently a symfony rep, goes on about how awesome they are and that the user commenting is being all mean like. Piling in on this user that at the least has a legitimate concern. Then it turns into this little circlejerk with another user coming in and being a sycophant for the symfony guy like one of those teenage girls on the front row of the latest boyband phenomena and as far as I can tell the symfony staff are just wallowing in this adulation.

Which really gets to the point. They just want people to love then unconditionally. The quality of their code and framework doesn't really matter. It's all just a show. They have one purpose and its their own narcissistic or histrionic tendencies. They've become a religion and aren't impartial to the notion that they're infallible.

You see how nasty they are when they simply call their entire manual which is just copy and paste snippets as "best practices". When they're calling anything they do unconditionally best practices they're saying it's the best, it's impossible to do better. What a bloody arrogant claim. How do they even prove it's the best? What happens when little old me comes along and does it better (tm)? Joey does it better. That's my motto. If it's the best, why does it need to be updated constantly to receive "improvements" so to make my life just that little bit less of a symfony induced living hell?

I've started complaining recently that symfony actually turns PHP into a compiled language. That's because symfony is so slow it needs to be compiled so that it'll run at a halfway decent speed. They then call it a fast framework. They hid this by renaming the symfony:compile command to cache:clear which secretly actually compiles or recompiles symfony. It's basically make clean && make.

A heck of a coincidence, but I was also recently looking through some legacy writings in the task manager from developers long left. One of them commented that you have to do thing:cache:generate because apparently the cache command doesn't other generate caches. Of course it doesn't, it compiles symfony.

These are just recent or specific problems with symfony. Every time I have to deal with it, it's one problem or deficiency after another. Almost every day. It's not just the learning curve. They stuff really sucks. It's not making things simpler, it's making me now have to jump through ten hoops instead of one to get sometimes the simplest things working.

I always make technical complaints but at this point I've been pushed to the edge of realising it'll never technically shine and it'll never be a good framework because the people behind it are just awful. If people lie or deceive about the problems, how are they going to be solved?

We all try to be nice and blame things like people just haven't learnt stuff or just blame the tech but there comes a point where I think we just have to be plain honest, the people suck, that's it, move along until we find nicer things or nice people so that things can become nicer. I don't like bagging on people but after taking an evidence based approach it's the only conclusion I'm left with. If there's one thing worse than the framework, it's the people that make and maintain it.


CodeIgniter 4 just reached first public beta stage too.


The PSR-FIG is just some marketing blog selling opinions. It's not your boss and they're not a meaningful engineering standards body. You are the developer, not the PSR people. You should not be allowing unauthorised parties access to your codebase through you. Sounds like you've been socially hacked.

The first few PSR or so tends to just broadly recite common knowledge among seasoned PHP developers of basic practices to avoid headache, like not accidentally initiating output thanks to extraneous whitespace in an include meant to only include library functions. There's nothing special They're one of the many blogs to point out those things.

Standards around autoloading is quite important and really the only essential thing PSR does. I wouldn't say it does anything amazing but at least goes far enough to have some mitigation of the proliferation of conflicting autoloaders, that is every library shipping its own. The PSR autoloading isn't special. It's actually the autoloader I first implemented as an eager early adopter of PHP 5.3. Yes, I invented the thing that PSR is famous for, the autoloader. PSR ripped off my invention.

Outside of that PSR is just a blog made by a bunch of people who think that all PHP developers suck and should be kept on a leash with framework developers running the show.

This might shock you but even PHP is not PSR compliant. As far as PHP is concerned PSR-FIG can get stuffed and as far as I'm concerned PSR-FIG can go die in a fire for all I care.

It's all the dictators in php web development that make me want to jettison my 10 years of php programming skills. It seems like there's a new abstraction or practice every quarter that you must adhere to.

It just sucks all the fun out of programming. Period.


Following PSRs is not required, nor does it make it any better in my opinion.

Not following PSRs does not make it worse of a framework.


It's a weird one.

On one hand you can never be certain any standard fits all cases, and you know the more creative developers want to do their own flavour thing.

On the other, it was much easier to tell the whole team here to just follow the damn PSR-1 / PSR-2 instead of everyone re-inventing their own weird slightly different visual coding style. Minus the spaces over tabs of course, but that's a whole another can of worms :D

All in all I probably agree more with having standards over not having one, so yeah, looking quite forward to what they've done.

Haven't checked PSR's out for a while, have they done something security based, ie don't output user input without escaping html tags first, etc?

I do prefer PSR over none as well. But I'm just trying to keep an open-mind and not dissing a framework just because it doesn't follow the standards.

I'm not too bothered about it either, but people who do like it, for them it might be much higher in consideration priority than for you or me.

And to get more people on board with new version, it's good thing that they've considered it.


Oh sure, you can't make Security PSR-101 and push all the responsibility to framework. Most of the time frameworks are as secure as they can get and all the issues come from however coders do their stuff, or probably 50% of the time, how servers are set up, which has nothing to do with code at all.

Said that, people like to follow simple checklists. And PSR-1 and PSR-2 are about "style" and some parts have nothing to do with actual coding, so secure "style" could potentially be documented same way.

I know there are few of these kicking about, and there are more general language agnostic lists, but PSR has a bit of authority in PHP community, so if they did it, I think it would get bigger following, even if it's just virtually copying already existing check lists.

Also, I am yet to meet a PHP developer who prefers spaces over tabs.

Me too now, moved to another company that fully hours for psr-2 🤓


With PSR adoption CI4 does indeed look like a much better contender. I'll keep my eye on this release.


For php I have worked with Symfony and 10 years of spaghetti. PHP (as of 7.2) will not be super high performance by itself, especially if http response time is your measure of performance. Symfony gives you a lot of structure backed by excellent docs but you pay the price in performance and some flexibility. For internal web apps Symfony is perfect since performance is not a high concern and the structure it gives makes maintaining the code quite easy.

The only way I have gotten PHP to be very high performance (at least with non-trivial pages) is using PHP-pm with Symfony in which I have managed to achieve around 5-10ms response time locally. Now I have not spent the time to figure out how to get rid of all of the errors with PHP-PM, so I would suggest doing your own research before considering it as an option.


Sounds interesting. I heard that Symfony 4.1's routing system is now the fastest one available.


That is what the Symfony blog claims. Though it didn't seem like the routing was the slow part, but every millisecond counts.

Yeah. It's usually the database. It's why I just use straight up PDO, I can optimize the queries themselves rather than relying on ORMs that are quite possibly inefficient.

Where I work we have a massive internal app which we have recently plugged Symfony into to give some much needed structure. Within the Symfony context we use a mix of ORM and raw sql. For simple select queries and insert/update we use the orm, but for more complex select queries we stick with raw sql. Our fight is maintainability and reversing all of "just get it done" code over the years.


I wrote my own router, and I was able to get roughly 1-5ms loads, locally.


Honestly, I'm a novice in this arena. I tried Laravel for some time for fun projects but never had it really well. Nowadays for a whole application development I'm using the Slim framework and so far I've been liking it a lot :D


Yeah, Laravel's pretty good. I don't know about Slim, haven't used it.


I suggest you give Slim a shot, you can get started with something cool pretty quickly. And is not just for quick prototyping it can extend up to build a full backend application.


Laravel, though Symfony is catching up as a second favorite. Granted that I work on projects that value continuous delivery over performance, Laravel's out of the box offerings is pretty much perfect.


Laravel is really nice, but I just don't need the bulk of it. I prefer writing my own stuff.


Symfony. For a long time it pushed for quality while sacrificing (or not caring enough for) developer experience, but they have changed that since a year or two ago. It is progressively more easy to use and modular by nature, so you need only use the code you want to. It can be as big or as small as you need it to be.


Yii/Yii2 is a solid framework; taking a lot of queues from Ruby on Rails and Laravel. Convention with a little configuration; modular, and pretty well documented.

Phalcon, to me, is trying to solve a problem that does not exist. Framework logic execution is very rarely the cause of an applications slowness. Network, disk, custom logic; if the app is slow, it is one of those three sources.


Aye, usually it is. But I don't use Phalcon that much anymore. I'm either re-inventing the wheel myself, or going modular via Composer packages.


Modular via packages is the win; I personally hate re-inventing the wheel. Most bagn for the buck (or bang per hour of effort). What has been some of the biggest problems you have run into use the modular approach?

Uh, nothing much really. Probably the time it takes to setup the boilerplate. Because I'm not coming with stuff shipped out of the box for everything I need to make just about any typical web application, I have to plan what libraries I'll be using, and if it's a new one, then I have to learn it.

Although the benefits of customization for me overrules the development time. And if I get really good packages for configuration, and development(Phinx as an example for a migrations library).

To me, going modular is can be far better as I can only include what I need, and customize the project however I like. And a lot of the times it increases performance, because I'm not coming shipped with the whole set of packages when I don't need half of them.

But I still like re-inventing the wheel. I learn a lot from it, I find it fun and I might make something amazing that hasn't been invented before or something. Things are always being invented(in technology, science, etc) ... I understand if people don't like the re-inventing the wheel thing because that means they have to write it, put a lot of work into, debugging, tests, updates, etc. I don't see why we shouldn't stop inventing software.

Granted a lot of a software can just be basically re-built and slower(and just worse is general) than already existing software. If you're a "get it done and make some money" person, then it's quite perfect for you to not re-invent the wheel.

But I don't dis re-inventing the wheel, I encourage it.


I have never used CakePHP. However I did use Phinx which is a part of CakePHP as far as I am aware.