4 ms·

I am not big fan of PHP frameworks. But there is a thing - you are either using framework or inventing one. Currently I am using homemade sort-of-framework for

I am not big fan of PHP frameworks. But there is a thing - you are either using framework or inventing one. Currently I am using homemade sort-of-framework for my pet projects. It has one big advantage - there is no need to learn API from external documentation as I am building it along my needs. I also learn a lot about reinventing wheels.

nkozyra 6y ago
> you are either using framework or inventing one. I disagree, unless you consider using a language to be inherently creating a framework. Frameworks are generalizations, intended for flexibility. Their abstractions exist, typically, to shield a developer from the lower level stuff. If you're writing plain ol language of choice code to do a specific thing, it's none of that. People can look at your code and see, oh, he's using built in cookie management and headers and standard language database calls. It's readable, non abstracted code.
- justanotherc 6y ago
  Maybe, but non-abstracted code is not DRY, becomes difficult to maintain, and is time consuming to write. So a good programmer will start to abstract those things, and at that point you're going down the road of creating your own framework.
  - nkozyra 6y ago
    Employing DRY does not mean a framework. Reusable functions do not implicitly suggest a framework. I think you're defining it way too broadly.
jkoudys 6y ago
It's more a difference in weight and opinion. Laravel carries a lot with it; symfony nearly as much. But you could install composer and install the parts you like and not need everything shipped together. I agree you're normally inventing a framework, but I left the article feeling like there's a false dichotomy between monoliths and pure PHP as a framework. For what I do, throwing up Slim, Guzzle, and Doctrine works well. You could make the argument that any one of those individually is a "framework", or that collectively I've made a new framework in 3 lines of composer.json by combining them. Point is many (and the article suggests) see framework or no framework as some massive all-or-nothing choice, when picking the parts you want, even after you've built your system out, us also an option.
Jaruzel 6y ago
I do the same for my non-professional stuff. When I started learning PHP, I approached it the same way I do with every new language, I add a second file and use it for generic functions. I do it the native way inline as part of the main program flow, and then whilst ad-hoc refactoring (as I learn the language a bit better) I break out repeated chunks of code as a callable function and put in the second source file. I then re-use that second file for my next app in that language. Over time, I end up with my own personal framework. If I realise that I have a complicated function in my framework for which an inbuilt function or command exists (that I wasn't originally aware of) I'll refactor again and remove that function from my framework. Doing it this way just made sense to me. The first time out with a new language is quite slow, but once I know what I'm doing, I have a bunch of useful functions on tap for each new project. It's a massive time-saver and conforms to the DRY principle. Is what I'm doing 'a framework' really? I don't know, but to me its my workflow and I like it. I also write PHP in a 'code behind' sort of way, with all HTML in separate template files, but I think that's a step too far for most PHP people ;)
- justanotherc 6y ago
  So you just have one giant file full of unrelated procedural utility functions that you include to your new projects?
  - Jaruzel 6y ago
    Ah no, I strip out the unused functions once the project is finished - I can always put them back in if needed later on from another copy. Tbh, I simplified slightly - depending on the language, I can have many support source files full of functions, separated based on function type - so networking, IO, calcs etc.
trey-jones 6y ago
Composer was a gamechanger honestly, though it took a while to really come to fruition. Now you don't need a big all-in-one framework that does 50 things you don't need. You can pull dependencies ala carte and get a whole lot done.

nkozyra 6y ago

> you are either using framework or inventing one. I disagree, unless you consider using a language to be inherently creating a framework. Frameworks are generalizations, intended for flexibility. Their abstractions exist, typically, to shield a developer from the lower level stuff. If you're writing plain ol language of choice code to do a specific thing, it's none of that. People can look at your code and see, oh, he's using built in cookie management and headers and standard language database calls. It's readable, non abstracted code.

justanotherc 6y ago
Maybe, but non-abstracted code is not DRY, becomes difficult to maintain, and is time consuming to write. So a good programmer will start to abstract those things, and at that point you're going down the road of creating your own framework.
- nkozyra 6y ago
  Employing DRY does not mean a framework. Reusable functions do not implicitly suggest a framework. I think you're defining it way too broadly.

jkoudys 6y ago

It's more a difference in weight and opinion. Laravel carries a lot with it; symfony nearly as much. But you could install composer and install the parts you like and not need everything shipped together. I agree you're normally inventing a framework, but I left the article feeling like there's a false dichotomy between monoliths and pure PHP as a framework. For what I do, throwing up Slim, Guzzle, and Doctrine works well. You could make the argument that any one of those individually is a "framework", or that collectively I've made a new framework in 3 lines of composer.json by combining them. Point is many (and the article suggests) see framework or no framework as some massive all-or-nothing choice, when picking the parts you want, even after you've built your system out, us also an option.

Jaruzel 6y ago

I do the same for my non-professional stuff. When I started learning PHP, I approached it the same way I do with every new language, I add a second file and use it for generic functions. I do it the native way inline as part of the main program flow, and then whilst ad-hoc refactoring (as I learn the language a bit better) I break out repeated chunks of code as a callable function and put in the second source file. I then re-use that second file for my next app in that language. Over time, I end up with my own personal framework. If I realise that I have a complicated function in my framework for which an inbuilt function or command exists (that I wasn't originally aware of) I'll refactor again and remove that function from my framework. Doing it this way just made sense to me. The first time out with a new language is quite slow, but once I know what I'm doing, I have a bunch of useful functions on tap for each new project. It's a massive time-saver and conforms to the DRY principle. Is what I'm doing 'a framework' really? I don't know, but to me its my workflow and I like it. I also write PHP in a 'code behind' sort of way, with all HTML in separate template files, but I think that's a step too far for most PHP people ;)

justanotherc 6y ago
So you just have one giant file full of unrelated procedural utility functions that you include to your new projects?
- Jaruzel 6y ago
  Ah no, I strip out the unused functions once the project is finished - I can always put them back in if needed later on from another copy. Tbh, I simplified slightly - depending on the language, I can have many support source files full of functions, separated based on function type - so networking, IO, calcs etc.

trey-jones 6y ago

Composer was a gamechanger honestly, though it took a while to really come to fruition. Now you don't need a big all-in-one framework that does 50 things you don't need. You can pull dependencies ala carte and get a whole lot done.