Share One of the things we wanted to do better with Mercury was improve the user experience, for instance by using more client-side technology and optimizing our use of browsers. This led us to find a client-side technology that would best fit our requirements.

These days, the amount of JavaScript frameworks is overwhelming, but in the end, we went for Facebook’s React. In this article we explain why. 


React JS is a JavaScript framework for developing complex User Interfaces. It is developed by Facebook and has gotten a lot of publicity and momentum in the last couple of years. The first version of React was open sourced in 2013 and is currently being used by sites like Netflix, AirBnB, Twitter and Facebook itself. Why are more and more of these sites going for React?

Reusable components

Unlike many JavaScript framework such as Angular and Ember, React is focused only on the View part of MVC. With MVC the model represents the data, the controller contains the logic like retrieving the data, and the view transforms the model into something presentable like HTML.

Added to this, these frameworks offer all sorts of other facilities like Dependency Injection, services for communicating with the server, etc. React only knows components. Views are implemented with components and these components contains both the logic and the markup.

In MVC frameworks the logic is separated from the markup. The controller contains the logic, and the transformation from data to HTML is usually implemented by templates. According to the React philosophy the logic and the markup are too tightly coupled to keep them separate. Because the presentation logic is not spread out over multiple objects, React components greatly facilitate reuse.


Simple & fast

Performing updates is one of the reasons User Interface code becomes so complex. As an example, consider deleting or adding a record to a list. The code needs to call the server to delete the record, but also remove or add the list from the UI. There is a lot of complex UI code for all these specialized scenarios.

Also, because the state is not centralized, you have to deal with state synchronization, which is complex and can cause bugs. It is a lot easier to just refresh the data from the server after a mutation and then re-render the whole list. React makes this especially easy by automatically re-rendering a component when its state changes. You only have to write the code that changes the state as well as the UI code that renders the result based on the state.

Normally re-rendering the UI for every change would be expensive and cause performance problems, but React has a solution for this.


DOM (Document Object Model) operations are slow. The DOM is the browser API that you can use to dynamically modify the HTML in the browser. Most of the (client-side) performance problems are caused by inefficient DOM operations. Re-rendering components after every little change is the surest way to introduce performance problems.

To solve this, React introduces a Virtual DOM. Instead of directly using the DOM, React components use this Virtual DOM. React has an event queue on the background that compares the current Virtual DOM with the previous one every nth milliseconds. Based on the difference it will generate update (patch) statements that are executed against the real DOM, resulting in highly efficient DOM operations. This way developers don’t have to write complicated update operations, but still have super-fast JavaScript code. But the Virtual DOM has another important advantage.

Both on the client and on the server side

React is “isomorphic.” This is a new buzzword in the JavaScript world and means that the same code can be executed on the client side and on the server side. This unconventional method makes it possible to execute the JavaScript components on the server and send back the initial HTML to the browser.

The advantage of this is that the HTML is better optimized for search engines. Modern search engines are getting better at parsing JavaScript, but some more than others. Until this is resolved, it’s still best practice to serve plain old HTML. Another advantage of serving this initial HTML is preventing the so called FOUC (Flash Of Unstyled Content).

When most of the rendering is done in the browser, the server will first serve un-styled HTML. When the browser has received the HTML, it will interpret the JavaScript, which results in styled HTML. Especially on slower devices, like mobile devices, this can result in a flash of un-styled content. By doing the rendering on the server first, it will directly serve styled HTML and no FOUC will occur.


Sitecore is the content management system on top of which Mercury is built. To understand why we chose React, we provide some background information about some of Sitecore’s technical characteristics.

Everything is an item

Sitecore is mostly data oriented. When you open Sitecore’s content editor, you will see a hierarchical tree of items. Items are based on templates and templates themselves are also items. Templates define the fields that make up an item. Next to the data, an item also contains presentation details.


Presentation details determine how an item will be presented in the UI. This consists of a layout and a set of renderings. The layout defined the global HTML of the page. This layout can contain placeholders and named locations within the HTML that are containers for the renderings. A rendering contains the presentation logic that transforms a piece of data to HTML.

In figure 1 you can see a page with two renderings: FullPage & Wishlist. FullPage is placed in the body placeholder. FullPage itself also contains a placeholder, namely content in which the WishList rendering is placed. When a rendering is added to the presentation details, it will optionally show a popup in which the rendering can be configured. Renderings are configurable and reusable. Now that we know how Sitecore works, let’s see why React is such a good fit.


Sitecore <3 React

Sitecore renderings transform data to HTML. As you can see in figure 2, in most MVC JavaScript frameworks this logic is split between the view and the controller. The user interacts with the view, the view passes this on to the controller and the controller communicates with the server and transforms this into a model that is used by the view.

Multiple components are involved in this operation. In case of a Sitecore rendering we already have the data and somehow, we need to make this available in the JavaScript controller. With some hacks, you will be able to get this working, but the two concepts just don’t seem to fit really well.

React components, however, seem to have the same responsibility as a Sitecore rendering: transforming data to HTML. And in the case of React, this functionality is all grouped in a single component. This makes it a lot easier to invoke the component from within our Sitecore rendering with the data that is already available to us. As an example, in Mercury this looks like the following:

@Html.React("Mercury.components.RecentlyViewedProducts", Model.Products)

Here we invoke a specific React component that is used to display a list of recently viewed products. The first argument is the name of the React component and the second is the list of recently viewed products that should be displayed. The React component only transforms the products into an HTML representation.

In the case of Mercury, our Sitecore renderings are generally super thin and only invoke the corresponding React component. Sitecore websites are usually front-facing websites, where search engine optimization and performance are super important. With the ReactJS.NET open source project, the React components can easily be rendered on the Sitecore server. This greatly improves the initial performance of the website and fully optimizes it for search engines, despite its complex user interface.

Blue skies

Although the combination of Sitecore and React brings a lot of advantages to the table, there are some caveats. The learning curve of React is quite steep. It requires a certain way of thinking, which can take some time to develop. Also, debugging Javascript on the server is very hard. Currently, there is no proper tool for this.

To minimize the amount of server debugging, we develop and test the React components in the browser first. This has worked really well for us. One thing to be aware of is the Experience editor. This is the Sitecore WYSIWYG editor and is really important for the Sitecore experience. If the React component contains a lot of fields, it will not be editable in the Experience editor. Most of the times this can be solved by keeping the React components themselves as small as possible. Another thing we do is detect the editor in our MVC views and render additional fields in the Experience editor, so that they can be changed by the content editor.


These days, users expect more and more of their online user experience, so using modern Javascript frameworks is inevitable. React components are perfectly suitable for implementing Sitecore renderings.

Thanks to the possibility of also rendering the components on the server there is no negative impact on the SEO values of your site. Rendering the components on the server also prevents the so-called Flash of Unstyled Content, making your site performant, even on slower mobile devices. React has a steep learning curve, so we would not recommend using it if there are no explicit requirements for an interactive UI.

However, when you do need an interactive UI (do you ever not need one?) we would say React is the way to go on the Sitecore platform.

Related articles

Articles related to this topic

Share a Tweet
React is isomorphic. This is a new buzzword in the JavaScript world and means that the same code can be executed on the client side and on the server side #SITECORE # REACT  Share
React components are perfectly suitable for implementing Sitecore renderings. #SITECORE # REACT  Share