4 ms·

Actually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are

Actually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are intermixed in a single file. React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.

taytus 11y ago
In all fairness this is ancient history on the PHP world.
- mattmanser 11y ago
  That's the point that pkrumins/andreyvit are making, code where logic and presentation are mixed turn into a nightmare to maintain. And the practice is now ancient history. Apart from here it is again...
  - andreyvit 11y ago
    I explicitly do _not_ state that it applies to React, because there's no domain logic in React components. (Or at least there shouldn't be. It is certainly possible to write a spaghetti component that would do everything.)
    - gemma 11y ago
      > It is certainly possible to write a spaghetti component that would do everything. So...like PHP, then?
      - deleted 11y ago
        [deleted]
      - mercer 11y ago
        Not really. You're strongly coaxed into doing it the right way by design, which is not my experience with the old-skool PHP approach.
- aikah 11y ago
  > In all fairness this is ancient history on the PHP world. No, because PHP still work that way (hypertext pre-processor) and Yes because, PHP has frameworks that makes PHP work like other solutions (Ruby,Python,Java + frameworks), but one still need a <?php on top of a file. And again, a lot of PHP developers despise these frameworks and question their usefulness. In theory, they are right since PHP is a template language which goal is to render text content, and separation of concerns can be easily achieve without a complex framework in the case of a web application. In practice a framework makes large codebases more maintainable, no question. PHP is a strange beast. It's somehow rigid like Java, at least more rigid than most dynamic languages, it's a dynamic language, and a template language and it keeps on getting stuff from Java like languages (PHP 7). It's ironic that PHP was created because its author kind of found Perl too difficult to use for web dev, then wasn't taken seriously by pros then tried to imitate Java in some ways to feel more professional and now is on part with Perl in terms of complexity, while half of the PHP community praises over engineered codebases often found in the JEE world.
  - preinheimer 11y ago
    I have no idea how starting with <?php in a file is relevant. Should we also start mocking languages that expect a given file extension?
    - aikah 11y ago
      My point is that PHP renders text first and foremost, writing code in PHP is "opt-in" somehow. An HTML file for instance is a valid PHP file. AFAIK an HTML file isn't a valid Ruby or Python file. You don't need to tell the interpreter to kick in at first place. But that's not the main idea I tried to convey in my comment.
      - gemma 11y ago
        Right, your comment argued that "view logic, domain/business logic and database boilerplate code intermixed in a single file" is not "ancient history in the PHP world". Which it is, regardless of the `<?php` tag at the top of all the files. How a source file is processed has no impact on how programmers choose to model their applications.
spion 11y ago
See the problem with this explanation is again, it doesn't explain the reasons why this is bad. I'm not saying the reasons don't exist - on the contrary I agree they're very much real. However I don't think "view logic, domain/business logic and database boilerplate code are intermixed in a single file" qualifies as a straightforward, logical explanation. It simply doesn't answer the "why" question at all. Let me try and cover some of the reasons why. I'm sure you know about these reasons (and can probably list more), my goal is just to present an example of what I consider to be a straightforward logical explanation: If domain/business logic is mixed with view logic, then it would not be possible to reuse the same logic in a different view. These changes happen more often than anticipated: for example, a PHP project that has the view logic separated from the domain/business logic can more easily get an API (a HTML is one view, a JSON API would be just another view) Additionally separating database code from business logic lets you switch databases more easily or to give you multiple ways to access the data. For example, data may be directly fetched from an SQL database initially, then its determined that this is too slow and results need to be cached in Redis. If there is no separate code for the data access layer, you would need to locate every database query and make sure it queries the cache first. So this is what qualifies as a straightforward, logical explanation for me: lets assume the opposite statement was true, then we demonstrate how this leads to a bad situation and why its bad (more bugs, more work, and so on). Another would be doing a case study: we did X (mixed business logic and templates in this way), then when we wanted to do Y (present a different view V) we had to not only write new code (for the new view) but deal with this problem (uncouple the existing logic from the existing view). If we originally did otherwise (wrote the logic separately) this would've been the same or similar amount of work (demonstrate this) yet later we would not have to do the hairy decoupling (which took Z amount of time and caused N bugs) I think the whole industry would do much better if we focused more on actual specific examples and case studies of problems and drawbacks of different approaches rather than giving vague descriptions of the current state and claiming its "bad". Its just not helpful at all. There is so much reinventing the wheel in our profession simply because we are not communicating knowledge effectively. Frankly, most of it reminds me of religious dogma.

taytus 11y ago

In all fairness this is ancient history on the PHP world.

mattmanser 11y ago
That's the point that pkrumins/andreyvit are making, code where logic and presentation are mixed turn into a nightmare to maintain. And the practice is now ancient history. Apart from here it is again...
- andreyvit 11y ago
  I explicitly do _not_ state that it applies to React, because there's no domain logic in React components. (Or at least there shouldn't be. It is certainly possible to write a spaghetti component that would do everything.)
  - gemma 11y ago
    > It is certainly possible to write a spaghetti component that would do everything. So...like PHP, then?
    - deleted 11y ago
      [deleted]
    - mercer 11y ago
      Not really. You're strongly coaxed into doing it the right way by design, which is not my experience with the old-skool PHP approach.
aikah 11y ago
> In all fairness this is ancient history on the PHP world. No, because PHP still work that way (hypertext pre-processor) and Yes because, PHP has frameworks that makes PHP work like other solutions (Ruby,Python,Java + frameworks), but one still need a <?php on top of a file. And again, a lot of PHP developers despise these frameworks and question their usefulness. In theory, they are right since PHP is a template language which goal is to render text content, and separation of concerns can be easily achieve without a complex framework in the case of a web application. In practice a framework makes large codebases more maintainable, no question. PHP is a strange beast. It's somehow rigid like Java, at least more rigid than most dynamic languages, it's a dynamic language, and a template language and it keeps on getting stuff from Java like languages (PHP 7). It's ironic that PHP was created because its author kind of found Perl too difficult to use for web dev, then wasn't taken seriously by pros then tried to imitate Java in some ways to feel more professional and now is on part with Perl in terms of complexity, while half of the PHP community praises over engineered codebases often found in the JEE world.
- preinheimer 11y ago
  I have no idea how starting with <?php in a file is relevant. Should we also start mocking languages that expect a given file extension?
  - aikah 11y ago
    My point is that PHP renders text first and foremost, writing code in PHP is "opt-in" somehow. An HTML file for instance is a valid PHP file. AFAIK an HTML file isn't a valid Ruby or Python file. You don't need to tell the interpreter to kick in at first place. But that's not the main idea I tried to convey in my comment.
    - gemma 11y ago
      Right, your comment argued that "view logic, domain/business logic and database boilerplate code intermixed in a single file" is not "ancient history in the PHP world". Which it is, regardless of the `<?php` tag at the top of all the files. How a source file is processed has no impact on how programmers choose to model their applications.

spion 11y ago

See the problem with this explanation is again, it doesn't explain the reasons why this is bad. I'm not saying the reasons don't exist - on the contrary I agree they're very much real. However I don't think "view logic, domain/business logic and database boilerplate code are intermixed in a single file" qualifies as a straightforward, logical explanation. It simply doesn't answer the "why" question at all. Let me try and cover some of the reasons why. I'm sure you know about these reasons (and can probably list more), my goal is just to present an example of what I consider to be a straightforward logical explanation: If domain/business logic is mixed with view logic, then it would not be possible to reuse the same logic in a different view. These changes happen more often than anticipated: for example, a PHP project that has the view logic separated from the domain/business logic can more easily get an API (a HTML is one view, a JSON API would be just another view) Additionally separating database code from business logic lets you switch databases more easily or to give you multiple ways to access the data. For example, data may be directly fetched from an SQL database initially, then its determined that this is too slow and results need to be cached in Redis. If there is no separate code for the data access layer, you would need to locate every database query and make sure it queries the cache first. So this is what qualifies as a straightforward, logical explanation for me: lets assume the opposite statement was true, then we demonstrate how this leads to a bad situation and why its bad (more bugs, more work, and so on). Another would be doing a case study: we did X (mixed business logic and templates in this way), then when we wanted to do Y (present a different view V) we had to not only write new code (for the new view) but deal with this problem (uncouple the existing logic from the existing view). If we originally did otherwise (wrote the logic separately) this would've been the same or similar amount of work (demonstrate this) yet later we would not have to do the hairy decoupling (which took Z amount of time and caused N bugs) I think the whole industry would do much better if we focused more on actual specific examples and case studies of problems and drawbacks of different approaches rather than giving vague descriptions of the current state and claiming its "bad". Its just not helpful at all. There is so much reinventing the wheel in our profession simply because we are not communicating knowledge effectively. Frankly, most of it reminds me of religious dogma.