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.

  • 2
    Possible duplicate of Is it considered bad practice to have PHP in your JavaScript – gnat Jul 3 '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 3 '17 at 18:26
  • 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 3 '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 3 '17 at 18:55
  • 1
    +1 Good question and good writing ("the bog of eternal stench" ;)) – Tulains Córdova Jul 3 '17 at 19:44
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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.