Your Customers Hate JS (they just don't know it)

These days, it’s easy to choose JS based tools to build your new marketing site. There could be many reasons:

• You want the latest and greatest framework built on React.

• You want tools that you’ll be able to hire for.

• You want the flexibility of personalizing, a/b testing, and live editing. (WHILE STAYING IN BUDGET)

• It makes sense to use the same tech that your product team uses so that there is flexibility between your product and marketing development teams.

• Live preview editing is really slick and is easier to implement in React or similar client side frameworks.  Your CMS probably already has an SDK.

* Clarity: We are distinguishing between tools that make it easy to ship JS to the client by default, vs tools that make that a more distinct choice. Think NextJS vs Astro, but you could replace those with the tools of your choosing.  To be clear, we use and love NextJS… when it’s the appropriate tool for the job.

It’s scary to choose an alternative solution.  New experiences test our comfort levels and become natural barriers to change.  It’s easier to see the costs associated with the choice, time and budget chief among them.  

This might dissuade you from choosing the most UX-friendly tech stack, the one that will delight your users and, in turn, your marketing and analytics teams. So, let’s explore what you might gain by making a different choice.

It's fair to consider our personal experiences and the costs associated with stepping out of that comfort zone, but who do you want to optimize for? When we’re talking about a marketing site, I would argue that our priority users are:

1. End users

2. Everyone else (Editors, Marketers, Developers, etc.)

Sometimes we get caught in the trap of optimizing for the editor, the marketing team, or a client’s internal team because those are our colleagues and friends.  We want their lives to be as easy as possible, we love delivering good news (look at how friendly this budget is!), and they’re the people that we get the most immediate feedback from.  Maybe we even look at their productivity gains when we optimize for editor experience and correlate that to gaining more customers.

While these points should be considered, and can be true, optimization for an internal team should not be at the expense of the end user or customer’s experience.

JS is the most expensive asset we ship to the client, even while browsers and processors get more powerful.  And it’s really easy to ship too much. 

That’s not just me saying it. Addy Osmani’s The Cost of JavaScript series has been saying it for years.

In particular, React, Nextjs, Gatsby, Vercel, & Netlify have made building and deploying sites built on JavaScript really easy.  But those tools have historically defaulted to bundling and shipping JavaScript to the client in order to manage the UI in the browser.  Yes, this is empowering.  A lot of complicated features can be built by small teams.

It has also led to a lot of marketing sites being built with tools that are potentially better suited to single page applications.  And in turn, marketing sites that might be fairly static are still forcing user devices to execute JS in order for the site to render and be interactive. 

Yes, server components will make this better.  I’m excited that we won’t have to ship JS for every component to the frontend, but let’s consider some standard ideas for how a marketing team might want to connect with their potential customers:

1. Personalized Content: Let’s collect data on what our users are interested in and personalize content for them

2. A/B Testing: Let’s A/B test some copy so we know what resonates best

3. Interactive Feature: Let’s have cool feature X that gets our potential customers interacting with the brand

4. Live Editing Tool: Let’s implement a Live Editing tool for our editors so they can edit pages in the context that the data will be displayed in, not some form that makes the output hard to imagine.

When we default to using JS frameworks to build marketing sites, we often take JS solutions to these problems:

1. Personalize content?  Easy, I’ll bucket a user into a group, set a cookie, and make an api call on the frontend to render the most relevant content w/JS

2. A/B testing?  No problem, I’ll bucket a user into a group, set a cookie, and render either one message or another on the frontend and collect data on which experience leads to more conversions

3. Interactive feature?  That’s a simple react component.

4. Live editing?  Our CMS does that well, we’ll just bolt on their live preview SDK to our react components and we’re good to go.

Every single solution moves code execution into the browser, paving the way for larger JS bundles, CLS problems, and delays in time to interactive. The solutions could be the right tradeoff for some of those ideas.  But is it the right tradeoff for all of the ideas?

Are some of those solutions that I came up with potentially ill considered and naive? Sure, but they are cheap and near at hand to so many of the solutions and capabilities that many in the industry have gained experience with.  In my experience, they’re also not uncommon solutions to the problems given.

When talking to stakeholders, more complex often means more expensive.

Your goal is not to build websites for your internal teams; it is to acquire customers.  When working on a marketing site, your development team functions as a growth engineering team. We need to strive to balance all the things that we think are helping us understand our customers, with the goal of actually giving them the best experience.

I believe that codebases for sites built using React are, on average, more complex, more difficult to optimize, and more difficult to maintain than those that primarily use HTML and CSS, with some basic JavaScript for interactivity. They are also highly permissive to JavaScript solutions when it might be better to ask the question, “is there another way that I can do this”?

Building great end user experiences has proven time and time again to improve how likely customers are to engage and convert.  It’s critical to invest the time and energy upfront to understand what experience will provide the best value and ROI.  In my opinion, it’s worth considering when you need to lean into JavaScript, and when you don’t.

This entire post was actually originally born out of reading a paper that indicated that device usage is the primary contributor to a site's marginal impact on carbon output. If the network's energy consumption is essentially fixed concerning your site, then the only thing that significantly matters is the impact on user devices. JS is easily the most expensive asset we ship to users in terms of energy consumption. By reducing the amount of JS sent to user devices will minimize their energy usage and consequently their carbon footprint.

Enhanced user experience results from the browser doing less work, leading to better performance and improved core web vitals, in particular TTI and INP. By optimizing the amount of JS sent to user devices, we can ensure that the browser can load and render pages more efficiently, providing users with a faster and more responsive experience. This not only improves performance but also enhances the overall user experience by reducing wait times and making interactions smoother and more enjoyable.

Article by Jesse Day, Technical Director, Adapt USA