4 ms·

>>> The wrong way: Always use a framework on top of PHP I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many pe

by gedrap 10y ago

>>> The wrong way: Always use a framework on top of PHP I haven't been actively working with PHP for quite some time but... From what I've seen, I wish many people didn't take this advice (including the teenager me). It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Yes yes I know there are exceptions and all but, in general, that's truth. Same with frameworks. If you don't use one, you end up writing a poor one, unless all you need is a page that outputs a result of a single SQL query, or something equally trivial. I've seen plenty of 10k+ LoC applications with home made frameworks, poorly replicating open source ones, just because. >>> In the world of Python and Ruby building websites from the ground up is tiresome because neither Python nor Ruby was originally created to build websites. As a result general purpose frameworks such as Django and Ruby on Rails quickly became popular for building websites in these languages. RoR, Django became popular because it's so simple to build basic CRUD apps, which most of the applications are. Most of the stuff is done for you. Can't say the same about plain PHP. The author largely ignores the reasons why the mentioned frameworks became popular. Yes, you could make a well engineered solution from scratch. But chances are that you will not, time constraints being one of the reasons. Sorry, couldn't read further than that.

hazbo 10y ago
You make a fair point. I've seen this happen before and after a while, projects that have essentially turned into a poor framework, plus the application, can become somewhat of a pain to maintain. PHP has come a long way in the past few years and the amount of open source packages has become huge, especially since the adoption of composer. I think with that in mind, it is now easier to build and maintain PHP applications without a framework as such, but just with the components you specifically need. Like yourself, I haven't actively been working with PHP for a while either. But it's been interesting to watch what's been happening with it and it's community.
- willishq 10y ago
  I know what you mean, I once worked on a project which similar to what you describe, the problem in these instances is when the people involved in the creation of the project are no longer involved in the maintenance of the project so the project veers away from the implemented standards and becomes a smorgasbord of badly-integrated composer packages.
  - gedrap 10y ago
    That's one of advantages of frameworks - applications using them are somewhat standardized. They have similar structure, you instantly know what's the typical way to save or fetch a database record, etc. Sometimes you can do a bit better by gluing libraries, etc together, sure. But it's rarely worth the trade off.
tclancy 10y ago
That was where I stopped as well. I moved from PHP to Django about 9 (wow) years ago because I was reinventing my own ORM and very poor reusable web component set but didn't see something like RoR in the PHP world (there were some early ones but they weren't that appealing at the time). To say PHP is equivalent to Django, RoR or any of the very nice PHP equivalents is . . . I don't get it and thought maybe this was parody of parody.
throwanem 10y ago
> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Whereas, often, if you do use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in their documentation that a specific and entirely innocuous-looking schema option causes the ORM to produce a query containing a Cartesian join. You can use an ORM. Or you can write SQL, work with arrays, and keep your code and data separate. None of that is terribly difficult, and you are responsible for the results no matter what you do. If you can't trust yourself not to get basic things right, you have problems at a level that no library will solve.
- codedokode 10y ago
  The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something. This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support. ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM. ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.
  - throwanem 10y ago
    So not using an ORM is bad because you then need to understand the code in detail, but even though using an ORM is good, you then need to understand the code in detail. Gotcha. Less flippantly, I've never actually used an ORM in a typed language, and I suppose it's plausible the concept offers benefits there which aren't available elsewhere, especially if arrays of mixed type aren't permissible. It sounds like your perspective comes from heavy, perhaps exclusive, experience with such languages. Certainly I'm not sure where else one might get the idea that the ORMless style "works well only with tiny applications written by a single person", or "in a large application you have to use objects and therefore ORM". That said, what I've seen of the pervasively object-oriented model and how it's used in general leaves me with severe doubts about its value - it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. You end up with your application state torn into tiny shreds and scattered to the wind. Perhaps that's easy to reason about for some. I have not found it so.
deleted 10y ago
[deleted]
mastre_ 10y ago
> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Or you don't, instead you take the time to explore the concepts behind RDBMSes and learn good schema design, how to write good SQL, and so forth. And in the process end up with a high performance database and platform.

by gedrap 10y ago

hazbo 10y ago

You make a fair point. I've seen this happen before and after a while, projects that have essentially turned into a poor framework, plus the application, can become somewhat of a pain to maintain. PHP has come a long way in the past few years and the amount of open source packages has become huge, especially since the adoption of composer. I think with that in mind, it is now easier to build and maintain PHP applications without a framework as such, but just with the components you specifically need. Like yourself, I haven't actively been working with PHP for a while either. But it's been interesting to watch what's been happening with it and it's community.

willishq 10y ago
I know what you mean, I once worked on a project which similar to what you describe, the problem in these instances is when the people involved in the creation of the project are no longer involved in the maintenance of the project so the project veers away from the implemented standards and becomes a smorgasbord of badly-integrated composer packages.
- gedrap 10y ago
  That's one of advantages of frameworks - applications using them are somewhat standardized. They have similar structure, you instantly know what's the typical way to save or fetch a database record, etc. Sometimes you can do a bit better by gluing libraries, etc together, sure. But it's rarely worth the trade off.

tclancy 10y ago

That was where I stopped as well. I moved from PHP to Django about 9 (wow) years ago because I was reinventing my own ORM and very poor reusable web component set but didn't see something like RoR in the PHP world (there were some early ones but they weren't that appealing at the time). To say PHP is equivalent to Django, RoR or any of the very nice PHP equivalents is . . . I don't get it and thought maybe this was parody of parody.

throwanem 10y ago

> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Whereas, often, if you do use one, you end up using one, a very poor one. Sometimes you can get away with that. Sometimes you get to spend a Friday morning root-causing and reverting a production defect in a highly visible application because the developers of the extremely popular ORM you inherited failed to mention in their documentation that a specific and entirely innocuous-looking schema option causes the ORM to produce a query containing a Cartesian join. You can use an ORM. Or you can write SQL, work with arrays, and keep your code and data separate. None of that is terribly difficult, and you are responsible for the results no matter what you do. If you can't trust yourself not to get basic things right, you have problems at a level that no library will solve.

codedokode 10y ago
The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something. This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support. ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM. ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.
- throwanem 10y ago
  So not using an ORM is bad because you then need to understand the code in detail, but even though using an ORM is good, you then need to understand the code in detail. Gotcha. Less flippantly, I've never actually used an ORM in a typed language, and I suppose it's plausible the concept offers benefits there which aren't available elsewhere, especially if arrays of mixed type aren't permissible. It sounds like your perspective comes from heavy, perhaps exclusive, experience with such languages. Certainly I'm not sure where else one might get the idea that the ORMless style "works well only with tiny applications written by a single person", or "in a large application you have to use objects and therefore ORM". That said, what I've seen of the pervasively object-oriented model and how it's used in general leaves me with severe doubts about its value - it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. You end up with your application state torn into tiny shreds and scattered to the wind. Perhaps that's easy to reason about for some. I have not found it so.

deleted 10y ago

[deleted]

mastre_ 10y ago

> It's similar to ORM. Often, if you don't use one, you end up building one, a very poor one. Or you don't, instead you take the time to explore the concepts behind RDBMSes and learn good schema design, how to write good SQL, and so forth. And in the process end up with a high performance database and platform.