Episerver and react.js (or any other frontend framework/library)

I have some experience in combining Episerver with ReactJS and recently I was asked to host a workshop on the subject. My first move was to do some research to make sure my knowledge was up to date, but it turns out that there are not many articles or blogs on the subject. Therefore I decided to write one myself.

This is by no means a full tale of exactly how it all works, but it is a start and I hope I will have the opportunity to expand on the subject.

Falling in love

It is easy to fall in love with a certain tool, especially with one one as charming as react. It has the benefits of being rich and famous and backed up by some serious names in the business. But, as the wise men say: only fools rush in.

There are many libraries and frameworks out there that pack a pretty good punch, or perhaps, look just as sweet and endearing as react. There is the older and more experienced Angular for example, and why not check out the young and surprisingly nimble Vue or Aurelia. Ember is still also an attractive specimen on the market. Or why not opt for the classic and very robust vanilla JavaScript?

The key here, as in any relationship, is to match the prospective framework/library/tool to the rest of your toolbox. For instance, what is your developers previous experience? What is the baggage you bring into the relationship? And what is it you are actually looking for and need at this particular point in time?

I won’t go into any deeper comparison of the different libraries/frameworks just now as there are many articles available for that if you have the time to put a little effort into hunting for Mr. right, but here are a couple of articles to get you started:

Front-end Frameworks by Sacha Greif
Choosing the Right JavaScript Framework for the Job

But the thing they all have in common, other than large and enthusiastic fan-groups, is that they almost all of the time have coding simplicity and unity in mind.

When developing for the web there are a great deal of parameters to cater to. These tools are all for frontend developing, but what does your backend look like? Is it even prepared to take on any of these glossy tools? Are you ready to perhaps have to restructure your entire backend to accommodate the new demands? Are they compatible at all?

This is where it gets a little tricky when it comes to Episerver. It has a whole shebang of functionality under its hood that makes for a very robust CMS and data handling system all on its own. And it can be a bit of a challenge to make it work neatly with any of these frameworks/libraries.

The contract

The weakness, however, of Episerver is that it does not take into account the contract between the data that is sent out and how it is received by the frontend. Classically the view part of the MVC structure of Episerver is handled with razor views and jQuery.

JQuery has no opinions on how you structure your code and handles data rather randomly. It is nice in the way that it gives you full control of where you put your api calls, how you deal with rendering and manipulation of the DOM. But this can become rather messy at times, and very much depends on the skill and coherence of your developers. The result can become like a spaghetti western where you will never be quite sure where the next shot will be coming from.

That is were libraries like react come into play. React, Angular, and Ember all provide a solid way to create contracts between your data and your JavaScript/HTML. They force you into making a cleaner structure and couple your components with your JS in order to make development and even testing more cohesive and reliant on good structure.

Separating your functionality into components and modules where things that belong together, stay together, is essential. JavaScript that is directly coupled with the HTML and data makes for cleaner code and more efficient development. These frameworks/libraries help by guiding you and letting you know when things go wrong and where they go wrong without hours being spent on trouble shooting.

Framework weaknesses

These frameworks and libraries also have weaknesses, especially when coupled with heavy backend solutions.

Search Engine Optimisation

One of these is SEO. Typically when the frontend handles all of the rendering the only thing that the server can provide is an empty HTML page. The actual data is served to the frontend by the backend and the client has to wait for this to be picked up and then rendered by the JavaScript.

It is true that some search engines are kind enough to wait for the JS to execute and then index the page, but we do not know to which extent they do this.

Besides, it is not an ideal user experience when the page content keeps jumping around until the rendering has been completed and all of the data has been loaded.

Server side rendering to the rescue!

React, Angular 2, and Ember at least have support for server side rendering and it is a wise choice to implement this if you care a lot about SEO.

Server side rendering can be a bit of a hassle to set up, but once it is running, it will make for a very smooth client side experience.

Client-side MVC’s Major Bug


Routing can also become a little tricky. Episerver is strongly based on serving data depending on the exact url, whereas single page applications readily handle this on their own. Getting them to play nicely together can be challenging.

Combining Server With Client Routing In Episerver
Partial routing in Episerver

Data handling

Then there is data handling to take into consideration. Frontend frameworks generally rely on RESTful apis. If your backend is not built to handle that it can require some extra effort to make it do so. Frameworks expect JSON to be returned from the backend as well, if it does not then there could be some extra work required here as well.

Episerver user interface

This is where the shoe really squeezes, as we say here in Sweden. Episerver has its own user interface which relies heavily on WYSIWYG. If you have an admin group which is used to being able to see their output directly can become a little annoyed if the data rendering does not allow them to do so any more.

The simple truth here is that Episerver themselves do not recommend using a framework to handle this. And in any case it would require quite a deep knowledge of how on page editing works and how to hook the framework/library onto Episerver’s functionality. I do know that this has been achieved in a few projects, Lyko is one example.

A match made in heaven?

So, is the combination of Episerver and a frontend framework a match made in heaven? The short answer is no, there are a lot of hurdles to be overcome to get them to work on a deeper level throughout the entire solution.

However, on a more superficial level, and depending on how many compromises you are prepared to make, it could become a very beautiful thing in the end.

Leave a Reply

Your email address will not be published. Required fields are marked *