AMPscript vs SSJS: A Practical Division of Responsibilities

The argument about AMPscript and SSJS is usually framed as a preference. It is not. They are good at different things, and the accounts that stay maintainable are the ones where someone made an explicit rule about which goes where.

What AMPscript is good at

Inline personalisation, lookups against a handful of rows, conditional content in an email, and simple form handling on a landing page. It is terse, it is fast enough, and — importantly — the next person to open the email will be able to read it.

What SSJS is good at

Anything with structure: loops with real control flow, error handling, JSON, calling an API and doing something sensible with the response, and manipulating collections before you render them. If you find yourself simulating an array in AMPscript, you have already crossed the line.

The rule I use

• Rendering decisions in the message: AMPscript.
• Data preparation and anything talking to an external system: SSJS.
• Never mix the two inside one block just to save a variable.
• If a page needs both, do the SSJS work first, write results into variables, and let AMPscript render.

<script runat="server">
  Platform.Load("Core", "1.1.1");
  try {
    var rows = Platform.Function.LookupRows("Sample_Orders", "ContactKey", "SAMPLE-001");
    Variable.SetValue("@orderCount", rows.length);
  } catch (e) {
    Variable.SetValue("@orderCount", 0);
  }
</script>

The try/catch is the point. AMPscript's failure mode in a send is often a broken email; SSJS at least lets you decide what a failure looks like.

Performance, honestly

For most sends the difference between the two is not what makes your job slow. Row count is. A lookup inside a loop is expensive in either language, and the fix is a better data extension, not a cleverer script.

The most expensive code in a Marketing Cloud account is usually the code nobody can safely delete. Optimise for that.