lightbulb head

Sitecore JSS: When is it the right fit for your project?

Aug 07, 2019
Suset Fernandez

The release of Sitecore Experience Platform 9.0 in October 2017 introduced JavaScript Services (JSS). JSS is a complete SDK for JavaScript developers. It provides front-end 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

But when is JSS the right fit for your project?

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 while 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.

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

So, to answer whether or not JSS is the go-to choice for a specific project comes down to choosing between SPA and MPA. Let's take a look at some of the factors you must consider while deciding:

Load Time

SPA pages are completely rendered by the user's browser. The loading time is longer because the frameworks used are heavier, and the whole site content is loaded once. SPA's are able to make even a high-powered computer slow down. Users will experience slower page-load time and an inconsistent cross-browser experience. Modern browsers will be more effective at processing the application resources while older client technology will struggle to render the application.

MPA architecture relies on the server to process the majority of data like layout, visual styles, and scripts. Servers are meant to render the whole HTML well and fast. This pattern ensures delivering a consistent experience to website visitors across browsers.

SPA's best viewed on modern browsers. MPA tends to support more legacy browsers.

If you want to deliver your website content as fast as possible to your users, independently from the devices they will use to reach your page, you should avoid rendering them on the client and opt for an MPA.

User Experience

One of the best qualities of SPA is delivering an engaging user experience by removing the extra wait time needed to do page reloads. SPA is all about cool UI/UX design displaying interactive elements with a modern and attractive look.

MPA requires a page reload when the webpage loads or sends data to/from the server in the user's browser. Every time the user visits a page, the browser has to download all the page data from the server.

SPA is more dependent on JS—and it has to be turned on in the user's browser. Otherwise, it may cause bugs and problems with app functionality that results in higher app bounce rates and lower conversion rates.

If providing the feeling of cutting edge technology is key to your application, and you are not worried about customers using old browsers or those that have JS disabled, SPA is you go-to option.

Security

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 webpage secure while it's enough to safeguard only data endpoints for SPA.

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 hashtagged 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 request with 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.

Perhaps crawling a SPA application won't be a problem in the future as search engines update their web crawlers methods. However, if SEO is crucial for you right now, MPA has an advantage.

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.

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, what makes such task harder.

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.

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, what 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 SPA.

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

Factor

JSS

Minimal client-side application behavior

no

Consistent cross-browser experience

no

Support browsers without scripting and legacy browsers

no

Rich, complex user interface

yes

Rank high on search engines results

 no

Accessibility compliant

 no

Team has deep JavaScript knowledge

yes

There is an API in place already

yes

Easier, cheaper long-term maintenance

no