It’s clear to see why this is the state we’re in. There are a handful of main categories of client-side JS injections popular these days, each providing a unique and compelling value prop:

Ad-Tech

The ROAS you can achieve using retargeting are compelling, and successfully running a retargeting campaign means you need to pipe information to some external third party about what people are doing on your site, not only at page-load time, but also as people use your website. Apart from retargeting, ad platforms that offer real-time bidding or intelligent optimizations can benefit from conversion data to learn about which audiences convert best.

As a publisher, delivering ads and tracking their performance can be a surprisingly sophisticated job. There are so many ad-tech tools that do something cool and integrate with other ad-tech tools in a myriad of (generally hacky) ways. By boiling the implementation task down to just “paste this snippet” during the sales pitch, it’s easy to move the process along.

Further, project management in the ad-tech space can be at times overwhelmingly dominated by business weenies, who don’t sufficiently understand the risks of the underlying technical decisions being made. Since it’s so easy to make a business case for these tools, and it’s relatively natural to package them as injectable JS, the sales process driving their adoption has been a home-run. Once it’s sold to the higher-ups, there’s not much a developer can do to kill the deal and everybody just hopes the economic arrangement is enough to incentivize the JS-injector to be well-behaved.

When we experimented with AdRoll on FranchiseHelp, we found that the inclusion of it alone contributed to the injection of resources from 12 distinct origins!!

Tracking tags

When building analytics tools, that data needs to get piped somewhere else so you can ask questions of it. Google Analytics has been massively successful at achieving reach. We found in an analysis of ProductHunt websites, GA was included on 84% of websites, giving Google an unparalleled view over the entire internet. Allegedly, Google doesn’t use this data for their own purposes, but come on…

At least I trust Google with my life already. Other, newer tools like Kissmetrics and Mixpanel have also been really successful; they offer a really compelling set of features, they’re fast and slick, but I know very little about who is behind these companies.

At Metric, we’re migrating away from turnkey solutions like these and running more of our own analytics software through the Metric Collector project.

Rich APIS

Sometimes the features an external JS library provides are rather sophisticated, involving rich sets of components and asynchronous data requests to external services. A great example of these are maps APIs, which have complex mechanisms in place for efficiently loading and rendering tiles.

Due to the amount of sophistication that would be required to get all of the different pieces in place, leveraging something more full-featured like a JS snippet, which can do essentially whatever it wants, is pretty useful.

JSON-P APIs also fall into this category, as they allow the injection of arbitrary JS as a means to bypass CORS policies. While the intended purpose is to deliver data, they can be as dangerous as any other type of JS injection.

External Embeds

The open web has been pretty great at finding ways to syndicate content. You can’t go far without finding an embedded YouTube video inline on your favorite websites. Embeds are used for all sorts of things, like data widgets, content promotion, and so on. Sometimes, these live in iframes and are safely isolated from the parent page, but so many people just use Javascript to do it.

We elected to use Javascript back when we were working on AddressReport to power our embeddable data widgets which were designed to enhance home listings across the internet using our data. We ultimately chose to do so for the purpose of flexibility, which I think is compelling to a lot of companies building embeds.

I expected to receive a lot of pushback about that decision, but not a single partner raised any objections whatsoever about security. When speaking with the team over at Breezometer, who offer a similarly packaged embed, they told me I was the first person to ever even mention the concern to them. I’m convinced most people are totally unaware of this risk!

Reusable Components

There are plenty of not-for-profit open-source projects out there with fully inspectable codebases you can dive into* and deliver safely from your own CDN. But there’s a growing trend in building out reusable components that are monetized by charging a licensing fee. An appealing way to monitor and enforce those licensing contracts is to deliver the components using JS snippets.

*But you probably won’t; hopefully somebody else will, right?

These have the advantage of simplicity (so easy for a manager to simply write, “paste this snippet” and call it a day). When I get these requests, I usually go into this whole spiel, but I’ll admit I occasionally acquiesce if I’m feeling particularly tired, only to regret it later when our webpages are slow.

What frustrates me about these is that the features they offer rarely justify hosting the Javascript externally. Though they may be bound to a licensing agreement, there’s no real benefit on our end in keeping them separate from our typical asset pipelines! Sometimes, the situation is so bad (calling you out HelloBar), that the main thing they offer can be reproduced with a few lines of HTML and CSS!