3 ms·

For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has be

For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database schema? Difficulty: Impossible, because raw SQL strings are scattered everywhere, including on other systems. Want to add/modify a new internal CRUD form? Gonna be several hours of work to RE what the last guy did to keep things consistent, while tiptoeing into the SQL to not break anything. With a proper framework, this is a 5 minute task and a few LOC into the "admin interface". It works, and you can do a lot with just a few php files and a basic Linux system, but there are downsides.

unfocussed_mike 5y ago
There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.
- alophawen 5y ago
  I had a 10 year career doing PHP, in the last year or so I also enjoyed Laravel and built 10 or so sites with it. It did many things right. Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and I have been working with Go since and are very happy with it. This was Laravel 5 days and I'm sure much has changed. I completely adored the laracasts made by Jeffrey Way. I wish every framework had a guy like that do produce learning materials.
  - tored 5y ago
    Frameworks helps developers to move in the right direction, and that is a good thing, however when you have used a framework long enough you start seeing the cracks. Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic. * magic classes - using PHP magic methods for everything, the actual class is usually empty and things happening elsewhere. * magic files - put a file with the correct name in folder somewhere and things happen * magic configuration - put a hard coded string in some config file and you change the entire behaviour of the app. * magic layers - if you follow the execution path with the debugger you spend the majority of time circling around in different layers and very little time in your own code. All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.
    - klysm 5y ago
      > All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks. I think that’s because that kind of code has a much higher maintenance burden. It’s much more difficult to get up to speed on what’s going on in complex magical code. But you can probably trust a framework that’s achieved critical mass to make reasonable decisions and stay alive for a while.
- pphysch 5y ago
  Yeah I would love if these places had a solid Laravel deployment, but they sadly don't. And if I'm gonna deploy a new framework greenfield, I'll just go with Django since Python has more mindshare in my industry.
tored 5y ago
All of these problems are created by the developers. I have created many on-the-fly mini-PHP frameworks to use within existing legacy code bases to avoid all of this. Easiest way to avoid manually requiring files is to use classes with the auto loader. Done. The second easiest solution is to have different constants that has the full path to a directory and then just you use the correct constant when doing a require. No relative paths required. You can even have one require constant per file if that is your game. Raw sql is fine, just don’t scatter it in every file, instead put sql in specific repositories, e.g ArticleRepository, and do all article queries in there. Now it is easy. An ORM actually creates more problems when refactoring because entities are spread out everywhere. If you use something like Phpstorm IDE it can help refactor raw sql too. Problem is that many developers doesn’t think this thru and even worse they accept the situation and don’t do anything about even if they can. Instead they go to forums and complain. I’m sorry but I have zero tolerance for that.
- pphysch 5y ago
  A decent ORM framework provides all those things out of the box, and I disagree that the ORM creates more problems than its worth. It is a fine tool to accelerate development.

unfocussed_mike 5y ago

There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.

alophawen 5y ago
I had a 10 year career doing PHP, in the last year or so I also enjoyed Laravel and built 10 or so sites with it. It did many things right. Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and I have been working with Go since and are very happy with it. This was Laravel 5 days and I'm sure much has changed. I completely adored the laracasts made by Jeffrey Way. I wish every framework had a guy like that do produce learning materials.
- tored 5y ago
  Frameworks helps developers to move in the right direction, and that is a good thing, however when you have used a framework long enough you start seeing the cracks. Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic. * magic classes - using PHP magic methods for everything, the actual class is usually empty and things happening elsewhere. * magic files - put a file with the correct name in folder somewhere and things happen * magic configuration - put a hard coded string in some config file and you change the entire behaviour of the app. * magic layers - if you follow the execution path with the debugger you spend the majority of time circling around in different layers and very little time in your own code. All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.
  - klysm 5y ago
    > All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks. I think that’s because that kind of code has a much higher maintenance burden. It’s much more difficult to get up to speed on what’s going on in complex magical code. But you can probably trust a framework that’s achieved critical mass to make reasonable decisions and stay alive for a while.
pphysch 5y ago
Yeah I would love if these places had a solid Laravel deployment, but they sadly don't. And if I'm gonna deploy a new framework greenfield, I'll just go with Django since Python has more mindshare in my industry.

tored 5y ago

All of these problems are created by the developers. I have created many on-the-fly mini-PHP frameworks to use within existing legacy code bases to avoid all of this. Easiest way to avoid manually requiring files is to use classes with the auto loader. Done. The second easiest solution is to have different constants that has the full path to a directory and then just you use the correct constant when doing a require. No relative paths required. You can even have one require constant per file if that is your game. Raw sql is fine, just don’t scatter it in every file, instead put sql in specific repositories, e.g ArticleRepository, and do all article queries in there. Now it is easy. An ORM actually creates more problems when refactoring because entities are spread out everywhere. If you use something like Phpstorm IDE it can help refactor raw sql too. Problem is that many developers doesn’t think this thru and even worse they accept the situation and don’t do anything about even if they can. Instead they go to forums and complain. I’m sorry but I have zero tolerance for that.

pphysch 5y ago
A decent ORM framework provides all those things out of the box, and I disagree that the ORM creates more problems than its worth. It is a fine tool to accelerate development.