What is Sitecore JSS? And when is it a good choice?

Sitecore JSS (now called Sitecore Headless) is a framework for developing JavaScript applications that can be used to build custom web-based UI components and plugins. It also helps developers create reusable modules in Sitecore content management system (CMS). The framework provides an API that makes it easy to use the latest version of React, as well as other libraries like D3, Bootstrap, jQuery, Axios, and Lodash. Developers can use Sitecore JSS with any client-side technology or library they want.

Sitecore JSS aims to provide a better developer experience by simplifying code reuse across different types of projects while still enabling them to leverage the power of modern frameworks. This blog will explore how Sitecore JSS works and what benefits it offers for both developers and marketers.

What Is Sitecore JSS?

Released by Sitecore in 2018, Sitecore JSS is a new tool that makes it easier for developers to build custom modules in Sitecore. Sitecore JSS is a Sitecore extension for JavaScript and CSS. It allows developers to write code in JavaScript or TypeScript, and compile it into small bundles of HTML, CSS, and JavaScript that can be loaded on-demand as the user navigates around the page.

It’s an exciting time for Sitecore because this opens up many possibilities and opportunities for developers, such as being able to add features into the system without having to wait on Sitecore’s release cycle.

In the past, developers looking to implement Sitecore could only use .NET to do it, but since JavaScript has experienced such a surge in popularity, the company realized how beneficial it could be for users to build Sitecore-based experiences using JavaScript.

All in all, JSS can be seen as a set of npm packages with:

• Core packages that abstract away the “Sitecore stuff” like talking to different Sitecore APIs,
• Framework-specific packages with components that render data managed by the core packages, and

Simple starter apps for every supported framework. What Makes Sitecore JSS So Important for Developers?

The release of Sitecore Experience Platform 9.0 in October 2017 introduced JavaScript Services (JSS) to Sitecore. JSS is a complete SDK for JavaScript developers. It provides frontend developers with a new way of working and interacting with Sitecore:

• The development can be done completely disconnected, without installing Sitecore on the developer’s computer.
• Deployments can be made to any platform that runs server-side JavaScript in a headless configuration.
• The Experience Platform capabilities (e.g. inline editing, content language versioning, personalization, testing, analytics, etc.) are fully preserved.

Without JSS, integrating frontend frameworks with Sitecore would be a huge project on its own, and chances are that even if you manage to do things right, you’d have to sacrifice some of Sitecore’s features.

JSS simplifies things for content authors and editors as they can now control the component composition and build digital experiences on their own. Sitecore JSS unlocks all the benefits of modern JavaScript frameworks and libraries such as Next’s image optimization and static site generation capabilities.

This is how a typical fully scaled Sitecore JSS development workflow looks:

Image source: Sitecore

Benefits of Sitecore JSS

Headless-ready

Among the benefits of Sitecore JSS is that it was created with headless deployments in mind. Sitecore JSS empowers developers and gives them full control of their frontend applications and deployed code without restarting the server. For marketers, this means that new features and digital experiences can be created without interruption, giving marketers more control over what they build and where that content appears.

Plus, for those already leveraging Sitecore Experience Editor, integrating JSS into the workflow enables authors to modify content using inline editing.

Better Performance

Performance is key for a fully functional website or app. A JSS app leverages the headless CMS architecture and enables companies to host their frontend in serverless computing devices to provide better response times. Also, by enabling pages to pre-render in the CDN, a JSS site is faster as there’s no need to wait for client-server communication, optimizing the end-user experience.

Flexibility and Independence

Building a Sitecore JSS application or website gives developers the freedom to use their preferred frameworks and tools like Angular, React, Vue, and even React Native for mobile development.

By using JSS, developers can start coding faster using starters and other tools in their local machines instead of doing it on a Sitecore instance. However, once developers are ready to commit those changes, they can consume that local datas using Sitecore Layout Services and connect that to the Sitecore instance, for a less convoluted approach.

Personalization

Sitecore support of both REST and GraphQL APIs enables the delivery of dynamic content, which means you can personalize your digital experiences for almost every device or browser as well as create dynamic fields that you can personalize using Sitecore’s advanced AI personalization features.

Greater Business Value

Building a website that’s not only fast to load but also fast to create is bound to give Sitecore users solid business benefits and help them achieve better conversion rates and maximum engagement. Sitecore, and the headless approach, gives users the tools to create and control content over multichannel, multi device customer journeys, giving users of every extraction the tools to do their job better and excel at what they do.

But when is JSS the right fit for your project? Let’s take a closer look.

When Is Sitecore JSS A Good Choice?

There are two general approaches to building web applications today: Multi-Page Applications (MPA) and Single Page Applications (SPA).

• MPA performs most of the application logic on the server.
• SPA performs most of the user interface logic in a web browser, communicating with the web server primarily using web APIs.

A hybrid approach is also possible, the simplest being to host one or more rich SPA-like sub-applications within a larger MPA.

However, when implementing Sitecore JSS, you will be adopting the SPA approach. Front-end developers will use one of the modern JavaScript (JS) frameworks supported by JSS ( React, Vue, Next.js, Angular, or React Native ) to implement a JavaScript application powered by Sitecore.

These are some benefits of Sitecore JSS for SPAs:

• Development and production runtime parity, including SSR during development
• Fewer confusing “modes” and deployment requirements
• No Headless SSR Proxy needed for production or integration with Sitecore tracking
• TypeScript-enabled app samples demonstrating common use cases
• Containerized template for Windows-based developers.
• Internationalization support via Sitecore language versions and Next.js internationalized routing.

Use An MPA When

• You need to build a solid, more conventional application
• You have a team or partner capable of maintaining the application
• Need a ready-made application with less customization

Use A SPA When

• You’re building a browser-based app
• Your team is familiar with JavaScript, TypeScript, or Blazor WebAssembly development
• Your application must already expose an API
• You want to deliver a rich UX/UI

Things to Look Out for With The SPA Approach

Even though SPAs are strong, reliable, and capable of providing cutting-edge customer experiences, there are some pitfalls to be aware of when building an SPA.

Potential Security Hazards

JS doesn’t perform code compilation so it becomes accessible to malicious users. By using cross site scripting, they are able to deliver dangerous JS scripts to other users. It needs extra work by proficient developers to make it secure.

In contrast, MPA requires making every web page secure while it’s enough to safeguard only data endpoints for SPA.

For Better Search Engine Optimization (SEO)

One of the frequently-named disadvantages of SPA is SEO. To ensure a high ranking on search engines it’s best to have a web application with steady content with separate shareable and bookmarkable URLs. There are tools available, but it is still quite a task to rank SPA higher on a search engine.

The reason for this is mostly due to the algorithms of web crawlers used before SPA was introduced. Search engine web crawlers visit every URL from your website, index the pages, and then go on and visit other links found on those pages. Web crawlers could not execute JS, and therefore, upon an attempt to visit the SPA hash tagged URLs, the crawler wouldn’t go anywhere. To solve this problem now when visiting URLs with hashtags, web crawlers request a new page from your servers. This requires the extra effort of responding to such requests with a content page specifically assembled on the server to feed the crawler. The pages you will be feeding to a crawler won’t be the same your visitors see.

The key to solving this with a SPA is to have your content also available at a fully-qualified URL that is in your sitemap.xml. That way, Google searches it. It doesn’t have to be the one that users see, however, when they come to your homepage. They may still see your SPA, but you just have to provide pages that Google can index with the content on it. This is a good use of the CMS because you are reusing your content across two mediums.

To Allow for Accessibility

Building accessible applications requires extra steps in development and testing regardless of the architecture. On SPA the task is bigger since your page completely changes the DOM structure with CSS transitions and animations. Asynchronous rendering of content can be difficult for screen readers to accurately interpret. Screen readers incur in focus behavior inconsistencies during the page transitions, even when ARIA and role attributes have been defined. JS library-specific components and modules may not meet accessibility best practices and focus-based event handlers can interfere with keyboard accessibility.

If accessibility is among your application requirements, you must consider this as a deciding factor favoring MPA. Making a SPA accessible, although possible, will significantly increase the number of development and testing hours in your project.

To Cut Development Costs

SPA development isn’t cheaper or easier than MPA. SPA typically takes more effort to ensure application usability. Developers must spend time implementing features that already exist in the browser. For example: restoring the scroll position, keeping the page meta title in sync with the content, handling URLs, etc. Additionally, most IDEs don’t support SPA, so developers have to use a browser’s tools for debugging, which makes such a task more difficult.

Another factor to consider while calculating implementation costs is how familiar your team is with JavaScript. If your team has mostly back-end developers who aren’t used to working with the client-side technology used to implement SPA, there is going to be a learning curve that is going to affect their productivity and your project cost.

On the other hand, in cases where you must support a web API to be used by other clients, like a mobile app, a SPA can leverage the same API. So, using the SPA approach will be cheaper than reproducing the logic in server-side form.

To Increase Maintainability

To implement SPA you will use JS frameworks like React, Vue or Angular. This means your website content will be available only to the browsers supported by the selected framework. Before taking this path you must consider that the framework maintainer’s goals might differ from yours. For example, React maintainers notify their users about possible cross-browser issues, which means you’ll be on your own to support a user using an unsupported browser. Angular has proven to evolve rapidly. Newer versions have little to do with the previous ones and aren’t compatible leaving you with poor options:

1. Rewrite your application to use a newer version, supported by the framework maintainers.
2. Find developers that can maintain your legacy code.

There is less risk when you have an MPA where a small portion of the site isn’t rendered because of a JS error. A JS error can compromise the whole site when you use an SPA.

The following decision table summarizes some basic factors to consider when deciding if JSS is a good fit for your project:

Factor	JSS
Minimal client-side application behavior
Consistent cross-browser experience
Support browsers without scripting and legacy browsers
Rich, complex user interface
Rank high on search engines results
Accessibility compliant
Team has deep JavaScript knowledge
There is an API in place already
Easier, cheaper long-term maintenance

The Future of Sitecore

The Sitecore SaaS-based DXP journey is underway. On the 7th of April 2021, Sitecore announced the successful integration of its niche acquisitions:

• Boxever: Customer data platform
• Moosend: Marketing automation platform
• Four51: Headless eCommerce platform
• Reflektion: Digital search platform

Dave O’Flanagan, Chief Product Officer at Sitecore had this to say about Sitecore's future plans, “Ambitious brands have outgrown the one-size-fits-all vendors, and they will not settle for piecemeal point solutions – they need a stack of best-in-class features that work in harmony together – and this is what Sitecore delivers.”

Sitecore aims to empower brands to leverage its latest SaaS offerings to build a modern, scalable, and MACH-powered DXP—and this is made even more possible with the headless architecture that Sitecore JSS offers.

Implement Sitecore JSS With Oshyn

Sitecore is, undoubtedly, one of the most powerful CMSs in the market. However, implementing Sitecore can be difficult if your company doesn’t have the experience or the expertise to build a bug-free, functional site.

Oshyn is a Sitecore partner with the muscle and the expertise necessary to help you implement Sitecore JSS so you can build a blazing-fast JavaScript site that’s optimized for performance and that’s also future-proof and compliant. Learn more about our Sitecore services.