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?
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.
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 development can be done completely disconnected, without installing Sitecore on the developer’s computer.
- 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.
This is how a typical fully scaled Sitecore JSS development workflow looks:
Image source: Sitecore
Benefits of Sitecore JSS
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.
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.
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.
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 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.
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:
- Rewrite your application to use a newer version, supported by the framework maintainers.
- 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:
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
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.
Frequently Asked Questions
What is Sitecore JSS?
What is Sitecore headless JSS?
Is Sitecore a headless CMS?
Yes, Sitecore comes with an enterprise-grade headless CMS that offers omnichannel support, powerful personalization, and API-first content delivery capabilities.
What is Sitecore headless development?
Sitecore Headless Development uses a Sitecore instance as the back-end and a rendering host as the front-end, making it easier to build, scale, upgrade, and maintain Sitecore solutions.