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.
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:
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 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.
These frameworks and libraries also have weaknesses, especially when coupled with heavy backend solutions.
Search Engine Optimisation
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!
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.
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.
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.