10

I really hate PHP frameworks.

I also often write my own frameworks but propriety. I have two decades experience doing without frameworks, writing frameworks and using frameworks.

Virtually every PHP framework I've ever used has causes more headaches than if I had simply written the code.

Let me give you an example. I want a tinyint in my database.

> Unknown column type "tinyint" requested.

Oh, doctrine doesn't support it and wont fix. Doctrine is a library that takes a perfectly good feature rich powerful enough database system and nerfs it to the capabilities of mysql 1.0.0 for portability and because the devs don't actually have the time to create a full ORM library. Sadly it's also the defacto for certain filthy disgusting frameworks whose name I shan't speak.

So I add my own type class. Annoying but what can you do.

I have to try to use it and to do so I have to register it in two places like this (pseudo)...

Types::add(Tinyint::class);
Doctrine::add(Tinyint::class);

Seems simply enough so I run it and see...

> Type tinyint already exists.

So I assume it's doing some magic loading it based on the directory and commend out the Type::add line to see.

> Type to be overwritten tinyint does not exist.

Are you fucking kidding me?

At this point I figure out it must be running twice. It's booting twice. Do I get a stack trace by default from a CLI command? Of course not because who would ever need that?

I take a quick look at parent::boot(). HttpKernel is the standard for Cli Commands?

I notice it has state, uses a protected booted property but I'm curious why it tries to boot so many times. I assume it's user error.

After some fiddling around I get a stack trace but only one boot. How is it possible?

It's not user error, the program flow of the framework is just sub par and it just calls boot all over the place.

I use the state variable and I have to do it in a weird way...

> $booted = $this->booted;parent::boot();if (!$booted) {doStuffOnceThatDependsOnParentBootage();}

A bit awkward but not life and death. I could probably just return but believe or not the parent is doing some crap if already booted. A common ugly practice but one that works is to usually call doSomething and have something only work around the state.

The thing is, doctrine does use TINYINT for bool and it gets all super confused now running commands like updates. It keeps trying to push changes when nothing changed. I'm building my own schema differential system for another project and it doesn't have these problems out of the box. It's not clever enough to handle ambiguous reverse mappings when single types are defined and it should be possible to match the right one or heck both are fine in this case. I'd expect ambiguity to be a problem with reverse engineer, not compare schema to an exact schema.

This is numpty country. Changing TINYINT UNSIGNED to TINYINT UNSIGNED. IT can't even compare two before and after strings.

There's a few other boots I could use but who cares. The internet seems to want to use that boot function. There's also init stages missing. Believe it or not there's a shutdown and reboot for the kernel. It might not be obvious but the Type::add line wants to go not in the boot method but in the top level scope along with the class definition. The top level scope is run only once.

I think people using OOP frameworks forget that there's a scope outside of the object in PHP. It's not ideal but does the trick given the functionality is confined to static only. The register command appears to have it's own check and noop or simply overwrite if the command is issued twice making things more confusing as it was working with register type before to merely alias a type to an existing type so that it could detect it from SQL when reverse engineering.

I start to wonder if I should just use columnDefinition.

It's this. Constantly on a daily basis using these pretentious stuck up frameworks and libraries.

It's not just the palava which in this case is relatively mild compared to some of the headaches that arise. It's that if you use a framework you expect basic things out of the box like oh I don't know support for the byte/char/tinyint/int8 type and a differential command that's able to compare two strings to see if they're different.

Some people might say you're using it wrong. There is such a thing as a learning curve and this one goes down, learning all the things it can't do. It's cripplesauce.

Comments
  • 3
    i love laravel 🤕
  • 0
    @Scriptero Laravel is built upon nameless components and really a far cry from being a decent framework as well.

    I'm still not sure if it has it's head up its own ass as much as the unspeakable one.

    I think its one saving grace is that out the box it's more tailored to basic web development scenarios though does still have a habit to clobber you with opinionated trash.

    It makes some decisions that could be described as less of a headache.

    On the other hand eloquent isn't a walk in the park either. Just yesterday I wanted only a created date field and not an updated date field but nope can't have it without screwing around. Buy one date field get another free!

    If it has another saving grace it's that so far as far as I can tell it's easier to avoid the malarkey if you want to.

    But between being punched in the face a hundred times a minute or fifty times a minute I'd much rather not being punched in the face at all.
  • 0
    This is the fucking reason why I built my own PHP framework! It works exactly as I need it to work, either for REST API's or general web applications.
  • 1
    @RANTSMACPANTS

    Yes.

    Eg:
    https://github.com/doctrine/dbal/...

    Thing is - while I agree with you, I can understand why an ORM layer won't support this.

    The sheer mass of extensions, different behaviour, faulty behaviour, aliases and / or different naming is insane.

    I am not aware of any ORM who does truely support the DBMS specific interpretation and extensions... But to be honest, I would not use it if it exists.
  • 1
    I'm sorry but you are a PURIST who just doesn't want to accept that something isn't working to your liking.

    And that's okay.

    But what is not okay - posts like this - will get people away from frameworks. I've been there. At a time where we had Zend and CI as major ones - people told me to stay away and create my own. I did that. It was working just fine, except development time.... When I got into a normal one that fitted my needs (and still does to this day, 6 years running strong) - time in which I develop things became so small that days with native code seems like waste of time.

    Yet, before you bash me - everyone has different styles and opinions. Since I've been in both camps - I can clearly say that it was a required experience. It just didn't fit my needs :)
  • 1
    I'm in the same boat, I use a framework I've built because I don't need the 100+ features I'll never use that wasted cpu and memory being loaded.

    Not to mention the constant lies and claims of speed (looking at you laravel).

    While using a framework is a matter of opinion, knowing why using frameworks for the sake of it is bad for programming as a whole requires a certain level of experience with the actual language on its own.

    As PHP developer, I've had this debate many a time with $framework developers. Like when they insisted on using one dependanxy after another because all the composer packages they wanted were too slow for the task... And I simply implemented the use of scandir() and it the task would complete in seconds.

    It blew their mind.
  • 0
    @stonestorm To be fair, I am using laravel and honestly - had no issues. Why? Well.... I don't search for packages if I know that I can use pure php to do the task faster.... Searching for packages just because it's a package - is stupid as hell....

    But overall, I see your point, and yes, there are some cases where it's beneficial to go raw php :)
  • 0
    @potata I'm simply a programmer who can program. I can program a system that supports tinyint. Frameworks can't. This is not a matter of mere preference either. It's objectively inefficient low grade software.

    It's absolutely alright to give people some idea what they might expect going down the framework route and to steer them away from it. What's interesting about PHP jumbo frameworks is that many of them are linked to commercial ventures and do very well with people like you going around enforcing absurd restrictions such as you're not allowed to discourage people from using frameworks.

    It's this that makes people especially angry. Attempting to weasel in one way or another that people have to use a framework with in this case a false counter balance. You're saying fine I have a potato on one side of the scales but it's not permissible to cause any new potatoes dug up to end up on that side of the scales.
  • 1
    @RANTSMCPANTS Well, you see, if you can do it better - just do it :) Somehow I can't really see many frameworks rising above even code igniter level and that's pretty low... Somehow when people solve one issue - there's another.

    But, from your comment, I'm sorry but it's really really clear that you are trying to blame without really looking into both stories.

    Your argument that you can code better than framework? Awesome, but is it secure enough? I highly doubt. Sorry. OSS has advantage there.

    Oh, they are making money? That's a lame argument...

    ---

    And to be fair, I'm not discouraging them from avoiding frameworks. Fuck no. I'm discouraging them from creating their own bike without knowledge how even a wheel works. Sorry but people shouldn't jump into RAW stuff without knowledge. And here is the main argument why we won't ever agree :)

    btw. I have no hard feelings, sorry if I hurt yours or made you angry, it's just that I've heard enough of this over my days :)
  • 1
    The main thing for using a framework like Laravel is the development speed and the beautiful, easy syntax it gives you. I never used something better than the routing system with middlewares from laravel, it supports everything you need. They even have a first-party package eco system with passport auth, valet or vapor ...

    Try do auth, middlewares, orm, routing etc. yourself. TTM 10x higher than with a good, well documented framework.
Add Comment