3

I see code like this sometimes (mixed PHP and JS in this case, but could be any server-side language):

<script>
  var data = <?php echo $bigDataStructure ?>;
  // then lots more pure js with no php mixed in which can access the data variable
</script>

Which seems like an appropriate way to pass data from a server-side scripting language to the JS that will run on the client (ignoring the fact that a global var named data is itself an eye-watering notion).

But I also sometimes see code like this (mixed JS and ColdFusion in this case):

<script>
  if ($('#firstName').val() === <cfoutput>#query.firstName != "" ? query.firstName : query.nickName#</cfoutput>) {
    <cfif userHasPermission>
      $('#userForm').validate();
    <cfelse>
      $('#readOnlyNotice').show();
      disableForm();
      <cfif settings.auditEnabled>
        recordAccessAjax();
      </cfif>
    </cfif>
  }
</script>

where the actual final version of the JS logic is dynamic. This, to me, feels like we're nearing the bog of eternal stench. Red flags galore. I could see (and have seen) this willy-nilly mixing get out of hand and create maintenance issues and debugging headaches.

What I'm wondering is whether there's a specific design pattern this violates? Or are there specific arguments that could be made against such dynamic code that I could present as reasons for moving away from the practice?

Note: another question asks whether it's a bad practice. Here, I assume that it is a bad practice and am looking for specific reasons why. The answers on the other question mainly focused on answering "is it bad?" and added suggestions of other ways to code the OP's example.

Grant Miller
  • 143
  • 2
  • 2
  • 11
jinglesthula
  • 305
  • 1
  • 8
  • 2
    Possible duplicate of [Is it considered bad practice to have PHP in your JavaScript](https://softwareengineering.stackexchange.com/questions/126671/is-it-considered-bad-practice-to-have-php-in-your-javascript) – gnat Jul 03 '17 at 18:10
  • @gnat that one asks if it's considered a bad practice. This question asks about design patterns the practice violates, and about specific arguments against the practice, so I think this one builds off the other. Kind of an "is it bad?" "yes - ok, why?" followup. – jinglesthula Jul 03 '17 at 18:26
  • I edited to indicate the distinction between the two questions – jinglesthula Jul 03 '17 at 18:34
  • 1
    The proposed duplicate does answer your “*why* is this a bad practice?” question: (a) “Try decoupling the two languages by making data their only interface – don't mingle the code.” (b) “What you're supposed to do is comprehend what Seperation of Concerns and Progressive Enhancement mean. This basically means you have dynamic HTML and static JavaScript” (c) “escaping inside a javascript context is not as simple as you would hope […] risk of a XSS bug slipping through” (d) “just for organizational purposes, this can get very annoying. It's bad enough to mix html and php (in my opinion).” – amon Jul 03 '17 at 18:54
  • 1
    You answered your own question when you said, "I could see (and have seen) this willy-nilly mixing get out of hand and create maintenance issues and debugging headaches." This is exactly why it is a bad practice. – scriptin Jul 03 '17 at 18:55
  • And there is no such thing as "violation of a design pattern". You either use them (appropriately or not) or you don't (appropriately or not). – scriptin Jul 03 '17 at 18:56
  • @scriptin But you can certainly incur in an anti-pattern. – Tulains Córdova Jul 03 '17 at 19:43
  • 1
    +1 Good question and good writing (_"the bog of eternal stench"_ ;)) – Tulains Córdova Jul 03 '17 at 19:44
  • @amon "Try decoupling" is suggesting a remedy, not answering why it's bad. "Comprehend separation of concerns and progressive enhancement" is the same. "Not as simple as you would hope" answers why but is mighty vague. "For organizational purposes" is better. XSS risk is orthogonal (though related). "bad enough...(IMO)" doesn't speak to why. The main point is that the OP in both cases asks different questions (even if some answerers on the other question supplied a few bits of "why"-ish material). – jinglesthula Jul 03 '17 at 20:17
  • @scriptin "get out of hand" is very general. I'm really looking for specifics. If I'm to convince the ship to change course, saying what I did above would only prompt the question about measurable benefits or clear and specific well-validated principles being violated. I intuitively feel it's a bad approach, but am looking for help articulating more concrete specifics. – jinglesthula Jul 03 '17 at 20:21
  • Put another way, if I commented on or downvoted the answers on the other question because they didn't say *why* it's bad, I'd mostly likely be told to ask "why" as a separate question. – jinglesthula Jul 03 '17 at 20:27

2 Answers2

3

The question here is "why" is this a bad practice.

The number one reason is the empirical observation over many years that it leads to software that is difficult to understand, maintain and change. These systems are colloquially call big balls of mud.

As a result of these experiences, a number of principles were developed to ensure that it is avoided.

John Scattergood
  • 176
  • 4
0

This is a problem that I never fully understood until I began working with the C# MVC framework. It's not necessarily "bad practice" but using the MVC model making programming much easier, not only to read but to write.

Read more about the MVC framework with PHP here.

Bender Bending
  • 169
  • 5