Why do we not talk about it?

Marketing Cloud Server-side JavaScript is one of those topics that most people do not like talking about. Most people seem to acknowledge it exists, and then move on to another topic as fast as possible. Why? It is a very powerful language and has a plethora of uses, why does it seem to be swept under the rug?

My theory is that the stigma on SSJS is the same as the one around Email HTML. It is not regular HTML, it instead is almost its own little language that looks like HTML. It has different rules, requirements and guidelines/best practices than web HTML and has no standards or regulations.

No one liked talking about Email HTML until enough industry experts ‘blazed the trail’ and produced ‘how tos’ and resources to get people up to speed and comfortable with it. (HUGE shout-out to all those Email-Geek heroes that made email marketing what it is today)

This is where I think SSJS for Marketing Cloud needs help. No one wants to talk about it because no one wants to accidentally show ignorance or get embarrassed by passing incorrect information. I think this stems from there being no real definitive reference or tutorial, like AMPscript.guide for AMPscript. Plus, there are a lot of people that incorrectly snub SSJS saying that AMPscript is better in all areas and it makes SSJS obsolete. These people need to learn how wrong they are – each language is very powerful and shines in different situations or use-cases.

Where can we learn?

Sure there are the official documents inside of SFMC help docs, which do contain a ton of awesome information and tips and tricks. But they are not the easiest thing to read and honestly have an expectation of knowledge in certain areas that the majority of people do not have – creating confusion. Sadly, there are also some samples or references that simply are not true, incomplete, are missing reference information or just do not work like explained, which causes even more confusion.

This means that a lot of people may no longer use those docs as reference because all it does is make things ‘worse’ for them. They instead will go to places like SF Stack Exchange, Email-Geeks channels, blogs or the Success Community/Groups to research or ask their questions on specific tasks or needs.

A lot of these places and resources are super helpful, but they also provide only specific information on a specific use case. Getting the answer does not mean that you have learned the solution. This means that it is not a good reference place to learn the language or to further your knowledge on it as there will be gaps and misunderstandings.

Learning vanilla Client-side Javascript is certainly helpful, but same as learning HTML 5 in order to learn Email HTML – it can lead to confusion as certain functions/capabilities and best practices for Client-side are simply not possible in SSJS. Of course, to make things worse, there are also things in SSJS that are not possible in client JS as well.

So how the heck DO we learn SSJS for Marketing cloud? Honestly, right now its just through a ton of trial and error. You need to research piecemeal in a bunch of places, scouring documentations to try and find options that ‘may work’. Then pray you can implement or adjust it accordingly to work in Marketing Cloud. Basically, in order to advance in SSJS right now, you need to constantly mess up and fail. Which can be a great learning method (e.g. ‘Trial by fire’), but it is very inefficient, frustrating and time consuming.

Far from optimal for sure. My goal here is to put forth a couple articles to help begin this conversation and in the future put SSJS on near equal footing to AMPscript conversations.

What is SFMC SSJS?

In a nutshell, SSJS is an older version of vanilla JS that is processed on the server instead of on the client-side computer. Due to it processing on Marketing Clouds server instead of client-side, it does not work with the DOM nor does it function with external libraries.

SSJS is mostly used inside of landing pages/Cloudpages, but it does have uses inside of messaging as well as in Automation Studio Script Activities – which, without some ‘fancy footwork’, cannot use AMPscript at all.

Most of the functions/Capabilities that are native to JS (and not browser/DOM dependent) are allowed inside SSJS. Things such as:

• Arrays
• Math
• Functions
• EVAL
• Try/Catch

SSJS is separated into two ‘sections’. You have the Platform and the Core Library. I know we just stated that external libraries do not work with SSJS, but Core is a library that is created by SF and hosted on the SF servers, so it is an exception to this rule. The rule is intended to apply to ‘user-defined’ external libraries.

In a future article, I will go over Platform and Core in more detail, but below is a quick synopsis on them:

Platform SSJS: Platform is very closely related to AMPscript, containing many of the same functions and uses. There are a few differences in syntax and capabilities (*Cough* *Cough* WSProxy *Cough*) that can help decide which language is better for your use-case, but that will need to be in the next article.

Core SSJS: Core is, in a nutshell, SSJS functions that are built to do SOAP API calls. Core mostly can only be used inside of Cloudpage or landing page environments and not in messaging. Core opens the gate to be able to interact with SOAP objects ‘behind the scenes’ inside Marketing cloud through a simpler and more familiar method (to those that already have background in JS).

Hopefully this was a helpful introduction into SSJS and helps pave the way for my future articles. My next one will be a deeper dive into the ‘basics’ of SFMC SSJS and syntax. Then my next focus will be on Platform and Core and their usages (including where WSProxy fits in). Let me know anything you are interested in around SSJS and I will be happy to try and work it in.

Until next time, keep safe and healthy!