← All essays

Engineering · Jun 2026 · 4 min read

AMPscript or SSJS: an honest decision tree.

The two languages overlap enough to make the choice feel arbitrary. It is not. Here is a decision tree that survives contact with production.

AMPscript and SSJS both run inside Marketing Cloud. They share a runtime host, several primitive types, and roughly overlapping capabilities in the middle of the Venn diagram. In practice, the choice is rarely close.

The mistake most teams make is treating the choice as a matter of preference. It is a matter of what the code is for.

Here is the rule of thumb that has held up across every engagement we have run: if the answer is a value substituted into an email, AMPscript. If the answer is a document or an HTTP round trip, SSJS.

Where AMPscript earns its place

AMPscript was built for one job: substitute values into an email at render time, with logic. Personalization tokens. Conditional blocks. Loops over ordered rows from a Data Extension. Formatting a date. Rendering a list of order items. All of the work that happens between the send button and the SMTP handoff.

It is tightly coupled to Data Extensions. Lookup, LookupRows, LookupOrderedRows, Upsert, InsertData, all of them are first class. They are fast. They are cached. They are the fastest way to get a value from a Data Extension into a rendered email.

It is also the only language that runs inside every Marketing Cloud content surface. Content Builder blocks. Landing pages. SMS content. Push notifications. If the surface is a Marketing Cloud rendered output, AMPscript works there and SSJS may or may not.

Where SSJS earns its place

SSJS was built to fill the gaps AMPscript could not: complex data manipulation, external API calls, document assembly on Cloud Pages, and anything that needed a real language shape with functions, closures, and a proper object model.

The clearest cases are Cloud Pages that do more than render a form. An internal admin surface. A webhook receiver. A page that reads JSON from an external API, transforms it, writes the result back to a Data Extension, and returns a status page. AMPscript could do parts of that. SSJS does the whole thing without contortion.

SSJS is also the right choice inside an automation that needs conditional branching driven by an external system. A daily job that reads a Data Extension, calls an API for each row, updates the row based on the response. Doable in AMPscript. Comfortable in SSJS.

Where they overlap and how to pick

The overlap is real. You can loop over Data Extension rows in SSJS with Platform.Function.LookupOrderedRows. You can call an HTTP endpoint from AMPscript with HTTPGet. Both work. Neither is idiomatic.

The tie breaker is maintenance cost. AMPscript reads badly in isolation but every Marketing Cloud engineer can maintain it. SSJS reads better but every Marketing Cloud engineer has debugged it less. When you write SSJS in a place AMPscript would have worked, you are handing the next engineer a puzzle they have to piece together.

The other tie breaker is where the code will run. Inside a Content Builder email, prefer AMPscript even if SSJS is technically supported. Inside a Cloud Page or a Script Activity, prefer SSJS even if AMPscript could carry the load.

The maintenance cost of SSJS people underestimate

SSJS debugging is genuinely worse than AMPscript debugging. The error messages are less specific. The stack traces are truncated. A syntax error in one block frequently manifests as an entirely different error message in a different block. Marketing Cloud's SSJS runtime is a fork of Rhino from a version of the ECMAScript spec that predates almost every language feature the last decade of JavaScript engineers take for granted.

The error surface is also smaller. AMPscript exposes almost every runtime failure as a rendered error in the send log. SSJS swallows errors silently unless you wrap them in Try/Catch, and the Try/Catch pattern is inconsistently applied across most SSJS codebases we inherit.

Deploy discipline is harder. AMPscript blocks are small enough that a diff review catches most problems. SSJS blocks tend to grow because the language allows it. A five hundred line SSJS block that assembles a Cloud Page is code that will regress unless it is under real version control with real tests, and Marketing Cloud does not provide either by default.

The decision tree in one sentence

If the answer is a value substituted into an email, AMPscript. If the answer is a document, a webhook or a round trip to a system outside Marketing Cloud, SSJS. If the answer is in the middle, pick the language of the surface the code lives on and move on.

“The overlap is where the debate happens. The tie breaker is who has to maintain it in six months.”

Keep reading

Engineering · Aug 2026

SSJS and external APIs: the token hygiene checklist.

Engineering · Aug 2026

AMPscript error handling: catching the silent failures.