Benefits and Challenges of Isomorphism in Single-page Applications: Case Study and Review of Gray Literature

Aleksi Huotala, Matti Luukkainen and Tommi Mikkonen^*

Department of Computer Science, University of Helsinki, Helsinki, Finland
E-mail: aleksi.huotala@alumni.helsinki.fi; matti.luukkainen@helsinki.fi; tommi.j.mikkonen@jyu.fi
$^{*}$ Corresponding Author

Received 05 July 2022; Accepted 25 January 2023; Publication 13 March 2023

Abstract

An isomorphic web application shares code between the server and the client by cleverly combining suitable parts of server-rendered applications and single-page applications.

In this article, we study the benefits and challenges of isomorphism in single-page applications in terms of a gray literature review and a case study. The case study was conducted as a developer interview, where developers familiar with isomorphic web applications were interviewed. The results of both studies are then compared and the key findings are compared together. The results show that isomorphism in single-page applications brings benefits to both the developers and the end-users. Isomorphism in single-page applications is challenging to implement and has some downsides, but they mostly affect developers. Implementing isomorphism enables sharing code between the server and the client, but it increases the complexity of the application. Framework and library compatibility are issues that must be addressed by the developers.

Keywords: Isomorphic web applications, single-page applications, JavaScript, web programming, server-side rendering, isomorphism.

1 Introduction

The increased popularity of the World Wide Web (WWW) has lead to the development of software for the web [39]. Asynchronous JavaScript and XML (AJAX) started to gain traction almost 20 years ago, which led to the introduction of the XMLHttpRequest (XHR) application programming interface (API) [32]. The XHR API can be used to fetch data asynchronously on the client-side [32]. The interest to merge XHR with hypertext markup language (HTML) and JavaScript made web applications evolve from static HTML web pages into complex JavaScript applications. Developers are continuously looking for ways to improve the performance and user experience of their web applications. They also value the developer experience, which they aim to improve by using new software libraries and tools.

The single-page application (SPA) was introduced in 2002 [6]. A SPA is a JavaScript application, which does not reload the page if the user navigates in it [25]. With the release of Angular.js1 and Backbone.js2 in 2010, web applications have become more dynamic and can serve richer content to the end-users. This, however, has introduced some problems regarding site performance and black search engine optimization (SEO) [33]. In some cases, web crawlers fail to index SPAs correctly [33]. SPAs might also be slow to load on mobile devices because the page is rendered with JavaScript code. Older devices, which do not support JavaScript, cannot run JavaScript SPAs. The proposed solution for the performance and SEO-related issues of SPAs is the isomorphic web application architecture [33].

Isomorphic web applications combine the best parts of statically generated websites and SPAs [18]. An isomorphic web application first renders the initial page server-side and sends it to the browser. The browser then attaches event handlers and the document object model (DOM) handlers to the initial page markup, which is called hydration [15]. After hydrating the application in the client, the application behaves like an SPA [33]. This all happens in full transparency for the client, where the user browsing the site might not even notice that the application has switched from a static markup web page to an interactive JavaScript application.

Isomorphic web applications share code between the server and the client [33]. The code that runs in both environments is called Universal JavaScript [31]. Isomorphic web applications provide good performance and user experience for the end user. From the developers’ point of view, the isomorphic web application architecture leads to increased complexity. The isomorphic web application architecture also has a steep learning curve.

In this article we study the benefits and challenges of isomorphism in single-page applications. To study the benefits and challenges of isomorphism in single-page applications, a gray literature review and a case study were conducted. The case study was conducted as a developer interview, where developers familiar with isomorphic web applications were interviewed. The results of both studies are then compared and the key findings are compared together. The work is based on an earlier Master’s thesis, which contains the details of the full study [42].

The results show that isomorphism in single-page applications improve the performance, user experience, and SEO of the application. The maintainability of the application is improved, because code can be shared between the server and the client. On the other hand, the application’s code can get duplicated which leads to increased complexity. Developers must take the library and framework into account when developing isomorphic web applications. Data fetching and state management are architectural challenges of isomorphic web applications. Isomorphic web applications can be hard to grasp in the beginning, and it might be not worth the trade-off of increased complexity to implement isomorphism in single-page applications.

The structure of the article is as follows. First, in Section 2, we provide the necessary background for the work. Next, in Section 3, we present our research approach and research questions of the work. Section 4 introduces the gray literature review and case study. In Section 5, we present the results of the study. Section 6 provides an extended discussion regarding the results. Finally, in Section 7, we draw some final conclusions.

2 Background

In this section, we introduce isomorphic web applications, single-page applications (SPAs), server-side rendering (SSR), state management, and search engine optimization (SEO).

Figure 1 Single-page application architecture [42].

2.1 Single-page Application

A single-page application black(SPA) is a web application that does not reload the page, if the user navigates in it [25]. SPAs work by embedding the source code of the application into a JavaScript file, which is downloaded by the browser for execution. Single-page applications adopt AJAX to the structure of the entire application [32]. The architecture of single-page applications is illustrated in Figure 1.

AJAX was introduced in the 1990s to make web applications behave more like desktop applications [30]. AJAX can be used to fetch data without actually reloading the web page [30]. It makes desktop applications more dynamic and responsive [30].

The single-page application functions as follows:

1. The server responds to the user’s request with the initial HTML page markup.

2. The user’s browser downloads other assets, such as executable JavaScript code and Cascading Style Sheets (CSS) files.

3. After the assets have been downloaded, the JavaScript code is executed. The JavaScript code will mount the application into the initial page markup.

4. After all AJAX requests for fetching data have been completed, the page has finished loading.

There are many JavaScript front-end frameworks that can be used to develop single-page applications. The most popular front-end frameworks of today are listed in Table 1.

Table 1 Comparison of downloads and GitHub stars of front-end frameworks, as of 9 October 2022 [4]

	Downloads (Monthly)	GitHub Stars
Vue.js	3,667,163	33,218
Next.js	3,233,198	94,081
Backbone	611,535	27,933
Angular	584,483	59,372
Gatsby	422,137	53,667

2.2 Server-side Rendering

Server-side rendering (SSR) is a technique used to render web pages on the server, rather than on the client [38]. Single-page applications render the initial page on the client side using JavaScript, which requires JavaScript support from the web browser. Backbone.js, React.js, Angular, and Vue.js all support server-side rendering out of the box. Therefore, an existing single-page application could be transformed into a server-side rendered application [3, 27]. The architecture of server-side rendered applications is illustrated in Figure 2.

Figure 2 Server-side rendered application architecture.

Figure 3 Isomorphic web application architecture [42].

When the user makes an hypertext transfer protocol (HTTP) request to the server-side rendered application, the server starts to generate static HTML. The event handlers and component identifiers, which React.js uses internally are also inserted as element attributes in the HTML elements.

2.3 Isomorphic Web Application

An isomorphic web application is a web application that shares the application’s code between the server and the client [29]. Executing the same code in different environments requires polyfills for the environment-specific dependencies. A polyfill is a piece of code that emulates an API, so it can function in a different environment [37].

Isomorphic web applications combine the best parts of single-page applications and statically generated websites [18]. In Figure 3, the isomorphic web application architecture is shown. As illustrated in Figure 3, the application’s state is shared between the server and the client. The code of the application is bundled into a JavaScript file, which will be downloaded by the browser.

The server constructs the initial HTML markup by using the application’s state and user interface (UI) code. The server can also do HTTP requests to external APIs. The data from HTTP responses are then processed and inserted into the initial HTML markup. The application’s state is encoded and injected into the HTML template, which can later be accessed by the client.

The final operation the client needs to do is to hydrate the application [18]. Hydration means attaching existing event handlers and DOM handlers to the HTML document [15]. In this phase, the application’s state generated by the server will be decoded. After hydration has been done, the isomorphic web application functions like any other single-page application [18]. If the hydration fails, the application might not function correctly; the UI might flicker, output errors in the browser’s developer console or be otherwise completely unusable.

2.4 State Management

State management in isomorphic web applications is a mandatory practice for synchronizing the state between the server and the client. The server hosting an isomorphic web application needs to send the application’s state to the client at the end of the request. The server must also ensure that the state between the server and the client is coherent, or the hydration process will not work properly. By using the same state management solution in the server and the client, the developer can reuse the same state management code. For example, the actions and dispatchers could be used in both environments.

Several tools and libraries exist for state management. Perhaps the best known example is Redux,3 a library to help manage application state in a centralized fashion. This makes applications behave consistently, independently of them run in the client, the server, or native. Axios,4 often associated with Redux, is an isomorphic state management framework, which relies on JavaScript promises in its implementation. This way, the state will eventually be synchronized. TanStack Query5 is a system that supports synchronizing data between clients and servers declaratively, proposing always-up-to-date auto-managed queries and mutations in application state. Finally, used by over 500k developers, Meteor6 is a comprehensive framework for building web applications, with a centrally managed state being one of the components offered by the framework. Which system to use in one’s own application depends on the needs at hand. Moreover, embedding state management in a particular web application can require additional work, based on the selected technologies.

2.5 Search Engine Optimization

Search engine optimization (SEO) is the process of improving the search performance of a website, by using crawlers and spiders to collect data from web pages [11, 23]. The collected data can include keywords, meta tags, and links to other pages on the website [23].

Tools such as Google Webmaster Tools,7 Google Analytics,8 and Bing Webmaster Tools9 give valuable insight into websites’ search performance [5]. These tools gather statistics about user interactions, click counts, and search queries, which were used to find the page in the search results [5]. That information can be used as a base to optimize the website’s search performance, either by on-page or off-page SEO techniques [5].

On-page SEO is made on the website and its markup [5]. Meta tags are located in the HTML document’s head section, and hyperlinks can appear anywhere on the web page [23]. Articles, headers, sections, and other semantic elements tell the crawlers, which kind of content the page contains.

In contrast to on-page SEOs, off-page SEOs are used outside the website [5]. Off-page SEO is usually made after the on-page SEO, to further enhance the SEO [5]. Examples of off-page SEOs include backlinks creating meaningful content, which boosts the page’s reputation, page views, and archiving the page to some online directory, such as the Internet Archive10 [5].

3 Research Approach

To study the benefits and challenges of isomorphism in SPAs, a concept-centric gray literature review described by Webster and Watson was conducted [40]. In the process of conducting the gray literature review, we followed the gray literature review guidelines set by Garousi et al. [16]. We also conducted a case study where we interviewed a group of developers. Together, the results of the gray literature review and the case study are compared to identify the key benefits and challenges of isomorphism in SPAs.

We decided to conduct a gray literature review because there is not that much scientific literature available about isomorphic web applications. Many books about isomorphism and isomorphic web applications were found, but the books mostly focused on the technical implementation of isomorphic web applications. In this work we wish to study the benefits and challenges developers say about isomorphism in SPAs, and how these benefits and challenges affect the end-users.

In this work, we aim at answering the following research questions:

• RQ1: What are the benefits of isomorphic web applications?

• RQ2: What are the challenges of adopting isomorphism in single-page applications?

4 Gray Literature Review and Case Study

4.1 Gray Literature Review

In the following, we introduce a gray literature review we conducted on the benefits and challenges of isomorphism in SPAs. We have chosen four websites for the literature review, which are Reddit,11 Medium,12 Dev.to13 and Hackernoon.14 The selected websites are popular among web developers, based on Google search results. The popularity among web developers was one inclusion criteria for our website selection.

4.1.1 Search query

The search query used to search for the gray literature was crafted in a way that it focuses on experiences, opinions, or thoughts about isomorphic web applications and universal JavaScript. We included articles that contain javascript, web, and either isomorphic or universal. To focus on articles about experiences, opinions, or thoughts, we included articles, which contain either experience, opinion, or thoughts. To stop the search process, we used the evidence exhaustion stopping criteria described by Garousi et al. [16].

site: website_url

javascript

AND

(isomorphic OR universal)

AND

web

AND

(experience OR opinion OR thoughts)

Table 2 Quality assessment metrics used in the inclusion and exclusion phase of the gray literature review [42]

No.	Metric	Scoring
M1	The reputation of the author’s organization	$1.0$ if the publisher is a reputable company
M2	Author’s association to a reputable organization	$1.0$ if the individual author is associated with a reputable company
M3	Author’s other articles in the field	$1.0$ if the author has published other work in the field
M4	Author’s expertise	$1.0$ if the author has expertise in the area, e.g. from their work history
M5	Stating the aim in the article	$1.0$ if the article had a clearly stated aim
M6	Stating the methodology in the article	$1.0$ if the article had a stated methodology
M7	Count of high-quality references	$1.0$ if the article had references to e.g. books or documentation
M8	Stating the limits of the work	$1.0$ if limits are clearly stated
M9	Covering a specific question in the article	$1.0$ if the article covered a specific question
M10	Referring to a particular population	$1.0$ if the article referred to a specific population
M11	Balance of the author’s article	$1.0$ if the article was balanced in presentation
M12	Objectivity and subjectivity	$1.0$ if the article is objective
M13	Self-advertising or the amount of bias in the work	$1.0$ if the article was not biased and self-advertising
M14	Data that support the conclusions	$1.0$ if the article clearly had data that supported the conclusions
M15	Visible date in the article	$1.0$ if the article had a visible date
M16	Linking to, or discussion about other gray literature	$1.0$ if related gray literature or formal sources were linked in the article
M17	Unique or enriching research	$1.0$ if the article had a unique point of view or added something unique to the research
M18	Strengthening or weakening of the current position	$1.0$ if the article manages to strengthen the current position of isomorphic web applications
M19	Number of backlinks	Normalized number of backlinks, acquired from ahrefs Backlink Checker Tool [2]
M20	Number of social media shares	Normalized number of social media shares, that were acquired from each article
M21	Number of comments	Normalized number of comments, that were counted from each article
M22	The credibility of the work (blog, video, thesis, article, etc.)	$1.0$ for high-credibility sources: books, magazines, theses and white papers. $0.5$ for moderate credibility sources: annual reports, news articles and Q&A sites. $0.0$ for low credibility sources: blog posts, presentations, emails and tweets

Table 3 List of metric values for the gray literature articles

Article Metric	A1	A2	A3	A4	A5	A6	A7	A8	A9	A10	A11	A12	A13	A14	A15	A16	A17	A18	A19	A20
M1	0	1	0	0	0	0	0	1	0	0	0	0	0	0	0	0	0	0	1	0
M2	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
M3	0	0	0	1	0	1	0	0	0	0	1	1	1	0	1	1	1	0	0	0
M4	1	1	1	1	1	1	1	1	1	1	1	1	1	0	1	1	1	1	1	1
M5	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
M6	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
M7	0	0	0	0	0	1	0	0	0	0	1	0	0	1	1	1	0	0	1	0
M8	1	1	1	1	1	1	1	0	0	1	0	1	1	1	0	1	1	0	0	0
M9	0	0	0	0	0	0	1	1	1	1	0	1	1	1	0	1	1	1	1	0
M10	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
M11	1	1	1	1	1	1	1	0	1	1	1	1	1	1	0	0	1	1	1	1
M12	1	0	0	1	0	0	1	0	1	1	1	1	0	1	1	0	1	0	1	1
M13	1	0	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
M14	1	1	1	1	1	1	1	1	0	1	1	1	0	1	1	0	1	1	1	1
M15	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
M16	1	0	1	0	0	0	0	0	0	0	0	0	0	1	0	0	1	0	0	0
M17	1	0	1	0	1	1	1	0	1	1	1	1	1	1	1	1	1	1	0	1
M18	0	0	0	0	0	0	1	1	0	1	1	1	1	1	1	1	1	1	1	0
M19	0.000	0.983	0.033	1.000	0.000	0.388	0.000	0.004	0.217	0.008	0.058	0.042	0.013	0.017	0.029	0.313	0.021	0.000	0.000	0.000
M20	0.015	0.647	0.059	0.309	0.000	0.191	0.000	0.000	1.000	0.324	0.029	0.000	0.044	0.118	0.015	0.618	0.559	0.000	0.000	0.000
M21	0.370	0.148	0.148	0.000	0.074	0.148	0.000	0.000	0.333	0.000	0.074	0.037	0.000	0.000	0.000	0.000	1.000	0.000	0.000	0.000
M22	0.0	0.5	0.0	0.0	0.0	1.0	0.0	0.5	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.5	0.0	0.0	0.0
Score	0.608	0.558	0.556	0.605	0.503	0.669	0.636	0.523	0.570	0.651	0.644	0.685	0.593	0.688	0.593	0.633	0.822	0.545	0.636	0.500

Table 4 List of articles selected to be used in the gray literature review [42]

#	Article
A1	Why Everyone is Talking About Isomorphic / Universal JavaScript and Why it Matters [24]
A2	Isomorphic JavaScript: The Future of Web Apps [7]
A3	Isomorphic (Universal) JavaScript [17]
A4	Why You’ll Always Need Isomorphic JavaScript [22]
A5	Next-gen Web Apps with Universal JavaScript [20]
A6	An Introduction to Isomorphic Web Application Architecture [19]
A7	Isomorphic Web Applications [13]
A8	Why and How Coursera Does Isomorphic Javascript: A Fast and Snappy Quiz [10]
A9	JavaScript SEO: Server Side Rendering vs. Client Side Rendering [8]
A10	What on earth is an isomorphic application? [21]
A11	Client Side Rendering Vs Server Side Rendering in React.js & Next.js [1]
A12	Why do we love Isomorphic/Universal rendering? [34]
A13	You Might Not Need Server Side Rendering [36]
A14	An Overview of Server Side and Isomorphic Async Rendering [26]
A15	Isomorphic JavaScript is Dead… Long Live Isomorphic JavaScript! [41]
A16	Break Down Isomorphic and Universal Boilerplate: React-Redux server rendering [9]
A17	The benefits and origins of Server Side Rendering [35]
A18	Isomorphic JavaScript: What is it and what can I do with it? [14]
A19	Why you should render React on the server side [28]
A20	Server-side rendering (SSR) for an SPA project [12]

4.1.2 Inclusion and exclusion criteria

The inclusion criteria for the gray literature was to include all relevant articles to the topic, which contained personal experiences, opinions, or thoughts about isomorphic web applications and universal JavaScript. We also conducted a quality assessment for the gray literature.

In the gray literature quality assessment process, we ranked each article based on the authority of the producer, methodologies, objectivity, novelty, impact, and outlet type [16]. To form the list of quality assessment metrics, we looked at the Quality assessment checklist of gray literature for software engineering by Garousi et al. [16]. We modified the assessment checklist to suit our needs, and ended up with 22 metrics that we used to rank the articles. These metrics are listed in Table 2. Metrics M1 to M18 have a value of $0$ or $1$ depending if the article matches the criteria or not. Metrics M19 to M21 are normalized between $0.000$ and $1.000$ , and the last metric M22 has a value of $0.0$ , $0.5$ or $1.0$ depending on the tier of the gray literature article. The formula we used to compute the final score for the article was

\frac{Sum of all metric values}{Total number of metrics} .

For each gray literature article candidate, we used the above formula to calculate a final score between $[0.0, 1.0]$ . A score of $\geq 0.500$ was required for the gray literature article to pass the validation. Not all articles contained personal experiences, opinions, or thoughts or were relevant to the topic or passed the gray literature quality assessment process. The final score for gray literature articles that passed the criteria are listed in Table 3.

After we performed the search on the four websites and going through the results, a total of 42 articles were selected in the initial phase. When we filtered out the articles, which did not contain experiences, opinions, or thoughts, we were left with 26 articles. Six out of 26 articles did not pass the gray literature quality assessment process, so we were left with 20 articles to be used in the gray literature review. The articles selected for the gray literature review are listed in Table 4.

4.1.3 Extracting data

As the approach of this study was to conduct a concept-centric literature review, we call each unit of data a concept [40]. The format of the concept used in this work is shown in Table 5.

Table 5 The data extraction format, which was used in the data extraction process of the study [42]

Article ID
Concept
Experience, opinion, or thought

To extract data from the articles, each article was carefully read through and key points made by the article’s author(s) were written down. After the reading process was complete, we grouped the key points by their category and made a note, if the key point is expressed as a reason, benefit, or challenge. The final results were compiled into a concept matrix, which shows each concept and the corresponding articles where they were mentioned in.

Table 6 List of developers, who were interviewed in the second phase of the study [42]

ID	Role	Experience working with isomorphic web applications
I1	Developer	4.5 years
I2	Developer	3 years
I3	Developer	5.5 years
I4	Developer	6 years
I5	Developer	6 years

4.2 Case Study

Next, we introduce the case study that was conducted as a part of the study. In the second part of this research, we conducted a case study to compare how the gray literature review and the developers from the case study tell us about the benefits and challenges of isomorphism in single-page applications. A group of developers from a Finnish technology consulting company were selected to participate in this study. The five developers who participated in this study are characterized in Table 6.

4.2.1 Case description

To search for developers to take part in the case study, we sent an interview invitation to the Finnish technology consulting company’s internal discussion forum. In the message, we briefly described the study, its goals, and our research approach for the case study. The choosing criteria for taking part in the interview was that the developer had worked with isomorphism and isomorphic web applications before. We did not narrow down the developers by their experience of the technology. After a while, we contacted the developers who had expressed their interest in taking part in the study and scheduled the video interviews.

Table 7 Initial developer interview questions [42]

#	Question
1	When did you first hear about isomorphic web applications?
2	How did you first learn about isomorphic web applications?
3	How much experience do you have in developing isomorphic web applications?
4	Describe isomorphic web applications with your own terms.
5	How much experience do you have in developing isomorphic web applications?
6	Describe isomorphic web applications with your own terms.
7	What would be the main challenges in transitioning to isomorphic web applications?
8	What do you feel about isomorphic web applications overall?
9	What are the benefits of isomorphic web applications?
10	What are the reasons for adopting isomorphic web application architecture?
11	What are the challenges of developing isomorphic web applications?
12	What is the developer experience of developing and working with isomorphic web applications?
13	What effects have isomorphic web applications had?
14	Have there been any surprises?
15	Would you develop isomorphic web applications in another case?
16	Is there a topic that was not addressed in the questions?

4.2.2 Data collection and units of analysis

The data was collected as a developer interview. The interview questions were formed in a way that covers both research questions of this paper. The questions selected for the first interview are listed in Table 7.

After the first interview was held, we noticed some overlap in the questions. For example, when asking about the benefits of isomorphic web applications, the same answer could be applied to the reasons for adopting isomorphic web applications as well. Because of this, we removed question #10 from the interview questions.

To get a better understanding of the downsides of isomorphic web applications, we added a question “What are the downsides of isomorphic web applications?”. Questions #7 and #8 were asked from both the developer’s and end user’s points of view. The final interview questions, which were used for developers (I 2)–(I 5) are shown in Table 8.

Table 8 The final interview questions, which were used in the last four interviews [42]

#	Question
Q1	When did you first hear about isomorphic web applications?
Q2	How did you first learn about isomorphic web applications?
Q3	How much experience do you have about developing isomorphic web applications?
Q4	Please describe isomorphic web applications with your own terms.
Q5	What would be the main challenges in transitioning to isomorphism from an existing application?
Q6	What other challenges exist in developing isomorphic web applications?
Q7	What are the benefits of isomorphic web applications?
Q8	What are the downsides of isomorphic web applications?
Q8	What is the developer experience of developing and working with isomorphic web applications?
Q9	Have there been any surprises?
Q10	What effects have isomorphic web applications had?
Q11	What do you feel about isomorphic web applications overall?
Q12	Would you develop isomorphic web applications in another case?
Q13	Is there a topic that was not addressed in the questions?

4.2.3 Data analysis

Each interview was held in English on the Google Meets platform and recorded for transcribing. Before we started recording the interview, consent from the developer was asked. We also gave an introduction of how and where the interview would be used.

Questions Q5–Q11 were the main interview questions that focused on answering the two research questions of this study. In addition, questions Q1–Q4 and Q12–Q13 from the final interview questions were used to get an overview of the developers’ experience and a general feeling of working with isomorphic web applications. The last interview question (Q14) was asked at the end of the interview to catch any topics the developers would have liked to discuss in more detail. This question also allowed us to ask question-specific things, if we felt like we wanted to know more about specific topics. At the end of every interview session, the developers had time to give feedback about the interview. After the interview session was over, we transcribed the video interviews into English. We then sent the transcribed interview text to the developers for them to check for any spelling or contextual errors, which might have occurred when transcribing the video interview.

Some answers were refined in another format, which was more suitable for the study’s context. In some parts of the interviews, we asked focusing questions because there was a lot of variation in the developers’ answers and their formats.

5 Results

The results of both the gray literature review and the case study are included in this section. First, we go through the gray literature review. Then, we go through the results of the case study. Finally, we compare the results of the gray literature review and the developer interview.

5.1 Gray Literature Review

Next, we show the results of the gray literature review. We answer the two research questions that we introduced in Section 3. The benefits and challenges of developing isomorphic web applications from the gray literature review are listed in Table 9.

Table 9 The concept matrix, which mentions the benefits and challenges of developing isomorphic web applications. The gray background separates the challenges from the benefits [42]

Article

Improved performance

Improved SEO

Better user experience

Code sharing

Easier to maintain

Old device support

Increased complexity

Harder to maintain

Steep learning curve

Slower initial response

Increased server load

Code duplication

Bundling assets is harder

State management

-

-

-

-

-

-

-

-

-

A10

-

A11

A12

-

-

A13

-

A14

-

A15

-

A16

-

-

A17

-

A18

-

A19

A20

-

-

Total

5.1.1 What are the benefits of isomorphic web applications?

16 articles out of 20 mentioned that isomorphism in single-page applications improves the performance of the application. This was one of the most observed benefits in this gray literature review.

‘‘Pages are served as rendered and faster initial page loading (less JavaScript files and file sizes)’’ (A3)

One article stated that the overall performance of the application is still improved, although the initial page response is slower:

‘‘Although an isomorphic application will be slower in responding an initial page compared to a client rendering application (as it fetches data and renders more markups on the server side before responding), overall completion time to the final user interface is faster because data access on the server side is much faster than client-side API requests.’’ (A4)

In addition to rendering the page server-side, a method called “above-the-fold stylesheets” was mentioned as one method of improving the performance of the application even more:

‘‘To achieve better initial page load times your best option is to render the application on the server. This way you can simply have the server return the fully compiled initial view as an HTML document, so a user doesn’t have to wait for the JavaScript to download and execute before displaying useful content. We can even enhance this further by inlining above-the-fold stylesheets (so called critical CSS) so we don’t have to wait for CSS files to load’’ (A5)

Improved SEO was the other most mentioned benefit, with 16 articles out of 20 mentioning it.

Googlebot15 has an isolated environment for network requests, which is a reason why isomorphic web applications improve SEO:

‘‘In order to index content that JavaScript apps render on client-side, Googlebot must run those JavaScript apps inside a full browser environment and capture the rendered DOM. This involves complex browser compatibility issues. Because JavaScript apps can make AJAX requests for further rendering, Googlebot must have a policy that controls apps’ network access. These are why getting your JavaScript app indexed properly by Googlebot is still challenging.’’ (A4)

In case the search crawlers can crawl the page directly, it also leads to improved SEO:

‘‘If the server renders the whole page, search engine crawlers won’t have to resort to executing JavaScript but can crawl your pages directly. This should drastically improve your PageRank.’’ (A5)

For some search crawlers, the crawlers run their own version of the browser engine. In the case of isomorphic web applications, it reduces the amount of polyfills the application is required to send in the JavaScript bundle:

‘‘Search crawlers are now able to parse and execute JavaScript. Googlebot, in particular, is a PhantomJS 16 script that runs as Chrome 41. This is why SSR/isomorphic makes sense since you won’t be sending down the unnecessary polyfills to all your users just so that Google bot can render your page.’’ (A12)

Better user experience was mentioned in nine articles, being the third most mentioned benefit of isomorphic web applications:

‘‘By rendering important parts of the application with the real data on the server side, an isomorphic application can show a meaningful initial page. On the other hand, client rendering application can’t show any meaningful information until it fetches all external data it needs. In the meantime, only thing a user will see is a loading indicator.’’ (A4)

Along with improved performance and search engine optimization, code sharing was the fourth most common benefit mentioned six times in the gray literature review:

‘‘...using the same code on both platforms. This is commonly referred to as Universal JavaScript and can be achieved by creating a set of abstractions that decouple our application logic from the underlying implementation. Effectively you can write your application logic in such a way that it won’t matter if it runs in the browser or on the server.’’ (A5)

An isomorphic web application is easier to maintain, a benefit mentioned in four articles:

‘‘Having the same library on both the server and browser allows for better development and code reuse, which leads to happier software engineers and less time spent maintaining the code.’’ (A1)

Only one article stated that isomorphic web applications have better old device support than a traditional SPA:

‘‘As rendered pages are served, it is not a problem to support old devices’’ (A3)

5.1.2 What are the challenges of adopting isomorphism in single-page applications?

In the 20 articles we reviewed, there were many fewer challenges than benefits mentioned in the articles.

Increased complexity was mentioned in nine out of 20 articles stating it as a challenge of isomorphic web application development.

Both the browser and the server have to execute the same code identically:

‘‘In order to build a Universal JavaScript application, each part of the stack has to support it. The challenge lies in getting the same code to execute identically in the browser context and in Node.js. While the Node environment is quite flexible and supports most of what you’d expect of a back-end system, the browser is a much more restricted environment. To achieve isomorphism in terms of limiting code duplication, we need wrapper libraries so we can use the same API to talk to both the browser and Node.js’’ (A5)

One article stated that some application code will end up duplicated:

‘‘While the ideal case can lead to a nice, clean separation of concerns, inevitably some bits of application logic or view logic end up duplicated between client and server, often in different languages’’ (A2)

Implementing isomorphism requires additional logic, which increases the complexity of the application:

‘‘Lots of logic should be handled in server-side. Handling HTTP requests, routing, rendering, styling, and module loading can be difficult and external libraries would be needed in server-side rendering. They should be handled in the same way both in server-side and client-side.’’ (A3)

Three articles stated that an isomorphic web application is harder to maintain. The increased amount of source code was one reason, which makes isomorphic web applications harder to maintain:

‘‘It’s possible to server-render your site with Java or Ruby and then transition to a single page app, but it isn’t commonly done because it requires duplicating large portions of code in two languages. This has a high cost in the maintenance of an app.’’ (A6)

In another article, isomorphic web applications ended up causing more problems than solutions:

‘‘I had to grow and maintain a large codebase over time. In many cases, the ‘‘tricks’’ I used to make my code ‘‘isomorphic’’ ended up causing more problems than they solved.’’ (A15)

Adopting SSR made the maintenance of the application more time-consuming:

‘‘Adopting SSR means that we are adding a new service layer into front-end clusters. The position could be right after the proxy server and in front of our representational state transfer (REST) API servers. This made the architecture a bit more complex and the maintenance a bit time-consuming.’’ (A20)

The steep learning curve of developing isomorphic web applications was mentioned in three articles:

‘‘...the learning curve is distressingly steep’’ (A16)

Two sources stated that isomorphic web applications have a slower initial response. In one article, time to first byte (TTFB) is said to be higher, but the perceived page load is faster:

‘‘TTFB is higher though perceived page load time is faster.’’ (A12)

When pre-rendering applications on the server, it leads to increased server load. This was mentioned by a single article:

‘‘In isomorphic/SSR with React.js, the server throughput impact is large. renderToString is synchronous central processing unit (CPU) bound-call, which holds the event loop, which means the server will not be able to process any other request till the function call completes.’’ (A12)

Code duplication was a challenge mentioned only by one article:

Concerns regarding asset bundling in isomorphic web applications were mentioned in two articles, saying that bundling assets is harder:

‘‘In using Webpack, achieving ‘‘parity’’ between server and client-side bundles can get messy.’’ (A13)

State management is important for the isomorphic web application to function properly. It was mentioned by one article:

‘‘On the server, you save the state of the application and then provide this state to the browser. The browser uses this state to bootstrap the SPA version of the application. Without this isomorphic handoff, the user must wait for the server-rendered page to load, and then wait longer for a complete re-render of the content in the browser.’’ (A6)

5.2 Case Study

The results of the case study are presented next. We apply the same result formalization from the gray literature review, which was described above. The results of the case study are summarized in Table 10.

5.2.1 How the developers got familiar with isomorphic web applications

Most of the interviewed developers have been in a project that used isomorphism. One developer told that they first heard about isomorphism when they were looking to improve the performance of their application:

‘‘As the application grew, we were looking at how to improve performance for the initial load. It involved a great deal of data and showing a lot of it. I found out that it’s possible to render the whole thing on the back-end, just serve the HTML and later on tell React.js to hook into this data’’ (I4)

One developer discovered isomorphism when they were going through the application’s code:

‘‘I was going through code and I came across a solution, which I hadn’t seen before.’’ (I2)

Blog posts were the source for one developer where they first heard about isomorphism:

‘‘I didn’t know about isomorphism until I saw a blog post about it.’’ (I3)

5.2.2 How much experience the developers have about isomorphic web applications

All developers who we interviewed have years of development experience in isomorphic web applications. The experience each developer has about isomorphic web applications is listed in Table 6.

5.2.3 How the developers described isomorphic web applications

Developers gave different definitions for isomorphic web applications. One developer answered that isomorphic web applications are about reusing the same code between the server and the client:

‘‘It’s an approach where you reuse the same rendering code on the client-side and the server-side.’’ (I1)

One developer stated that isomorphic web applications are applications that are not tied to the browser environment:

‘‘It’s more about having the application not being tied into the browser. You have an application that can run without the browser (server-side) and it produces a state that you can transfer somewhere else and hydrate it.’’ (I3)

5.2.4 Benefits of isomorphic web applications

The improved performance was mentioned by all five developers. Time To Interactive (TTI) was mentioned as one metric for measuring improved performance:

‘‘We monitored and saw an immediate performance increase. TTI dropped dramatically when we shipped ready HTML.’’ (I4)

There was one mention that performance is given with isomorphic web applications:

‘‘Performance is kind of given with isomorphism.’’ (I1)

Improved search engine optimization is one of the benefits of isomorphic web applications that was mentioned by five developers:

‘‘All kinds of crawlers will have an easier time crawling what’s on your page. We know Googlebot does JavaScript execution, but other bots like Facebook and Twitter will include a card to show a preview of the page. These crawlers don’t support JavaScript execution. They see the content if the page is server-side rendered.’’ (I5)

In addition, one developer mentioned that SSR was initially used as an SEO tool:

‘‘Initially, this was used as a search engine optimization tool, where you have the content on the page as the crawlers could access the dynamically/ asynchronously loaded content’’ (I4)

The improved user experience that isomorphic web applications give was mentioned by four developers. One developer stated that an SPA tends to be slow when the page is loaded for the first time:

‘‘It’s the snappiness. You get directly to a useful state. Sadly quite a lot of SPAs end up being a bit janky in the start.’’ (I3)

Flickering of the UI was mentioned to be a problem that isomorphic web applications solve:

‘‘There was no flickering in the UI. Getting back to the good old days of HTML-only when you have complete web pages served rather than a shell with five spinners.’’ (I4)

Code sharing was mentioned by two developers. One developer didn’t directly say it is a benefit, but rather a test that you can share code between the server and the client:

‘‘One of these advantages is that it is basically a check that are you able to share code efficiently between these projects.’’ (I4)

One developer stated that if you share code, it simplifies the changes needed to implement isomorphic web applications:

‘‘The good side of doing an isomorphic application is that if you are using the exact same rendering code on both sides, it simplifies some of the changes.’’ (I2)

The easier maintainability of isomorphic web applications was stated as a benefit by two developers. However, it requires the whole application to be set up, before actual maintainability improvements can be observed:

‘‘Once you have set up the isomorphic web application and the whole team recognized this is the way, it is easier to maintain than a regular SPA.’’ (I4)

5.2.5 Downsides and challenges of isomorphic web applications

Framework and library support for building isomorphic web applications was mentioned by five developers. For example, the developers claimed that there is a lot of boilerplate around isomorphism, and it is up to the development team how much work they are willing to do to implement isomorphism:

‘‘In React.js, you are left very much on your own; with other frameworks as well. There is a lot of boilerplate you have to do, and there is a lot of gotchas you have to know.’’ (I5)

Libraries that are installed using Node.js Package Manager (NPM)17 might be incompatible in an isomorphic environment:

‘‘When installing Node.js packages, you might end up with code that’s not suitable for an isomorphic environment’’ (I3)

The isomorphic web application architecture can be hard to understand. This fact was mentioned by three developers:

‘‘Many developers did not fully understand it. They did not understand what it actually means.’’ (I4)

Increased complexity was mentioned by three developers. For instance, Developer 4 mentioned that isomorphic web applications introduce additional build tooling configuration:

‘‘There is additional build tooling configuration required to set it up.’’ (I4)

State management was mentioned by three developers. It is challenging to keep the state in sync between the server and the browser, and how the state is transferred to the client:

‘‘State synchronization is a big challenge; to be able to maintain the initial rendering state from the server to the client without any issues.

You need to somehow fetch the initial state of the app from the back-end, and transport that to the client-side for hydration. You need to make sure that the states don’t get out of sync in the meantime.’’ ’’ (I5)

Data fetching was mentioned by two developers. If the data fetching code is shared between the server and the client, the developer needs to make sure it works on both server and client environments:

‘‘I earlier mentioned data loading. That can get more complex because the rendering code is shared between the server and the client. All the supporting code often might not be shared, so you would use different code for fetching data in the initial load than the rest of the application.’’ (I1)

Additional requirements are a challenge mentioned by two developers. For instance, there could be some implementation-specific behavior on different browsers:

‘‘When serving an isomorphic web application with Node, you are using Google’s open-source high-performance JavaScript and WebAssembly engine (V8) as the JavaScript engine. With Safari, you might be using JavaScriptCore on the client-side. Different JavaScript engines have different implementations, and there is some implementation specific behavior that you can observe -- especially when sorting arrays. Some operations happen in a different order, and if you use only Chrome and always use Node, you will never notice as they both use V8. Some people are using Safari a lot, especially on the mobile use case. Many developers are in a Chrome monoculture, and they fail to understand that the JavaScript code will be executed by a different engine.’’ (I4)

In addition to the browser-specific behavior, extra data transfer was mentioned by two developers:

‘‘Over a server-side rendered app there’s always going to be extra data transfer because you have the JavaScript that needs to be downloaded. You have usually the JavaScript Object Notation (JSON) blob of initial data that has been generated on the back-end that needs to be transferred alongside HTML.’’ (I5)

If the user has strict data caps, isomorphic web applications might not be ideal for them:

‘‘If we lived in an environment with very strict data caps; first you download the pre-rendered stuff, and then you are executing all the JavaScript code again after the initial load. We are basically serving the same data twice. If you really had to monitor your data usage, this could be something. Caching can solve this issue.’’ (I4)

The choice of back-end language was mentioned by two developers. JavaScript is one of the scripting languages that can be run both on the browser and server. There also exists some other web-oriented programming languages, which can be transpiled into JavaScript:

‘‘If you want to create an isomorphic application, you either have to fully use JavaScript, so you have a Node.js back-end and JavaScript front-end, or you use some language that can be compiled to JavaScript.’’ (I5)

Code duplication was mentioned to happen if the server’s and the client’s programming language was not the same:

‘‘If you go with a different kind of back-end (for example Python), then you have duplicate code because you have to have Django18 templates and the React.js templates for the front-end. Those have to match.’’ (I5)

5.2.6 Surprises of isomorphic web application development

The developers shared both positive and negative surprises when developing isomorphic web applications. Library support was a negative surprise said one developer:

‘‘Library support has been a negative surprise. In the React.js ecosystem, this has been a supported feature for five to six years, maybe even longer. There are still many popular libraries that don’t support server-side rendering at all. It causes problems, and you have to build things around it to make them work. You have to defer some components to make them run only on the client-side. You cannot work around these issues with simple if-statements because the outputs of server and client-side rendered pages have to match exactly to ensure that things work. Those are some negative surprises.’’ (I1)

One developer shared that isomorphic code was hard to understand in the beginning:

‘‘In the beginning, it was hard to understand that the code can be run on the server and the client. I sometimes stumble on it when developing isomorphic web applications.’’ (I2)

One developer said in the interview that there was only little information about isomorphic web applications available:

‘‘I was surprised that there was so very little information. I kept Googling for information, and I kept ending up with the same contrived, simple solutions’’ (I3)

The mindset of developers was surprising for one interviewed developer:

‘‘The resistance. Other developers might disagree and say that this complicates things.’’ (I4)

5.2.7 Effects of isomorphic web applications for the developers

Isomorphic web applications complicate the development process, stated by one developer:

‘‘It can complicate some aspects of the development because you have to consider the code running in both client and server side.’’ (I1)

The introduction of isomorphic web applications have lead to the development of isomorphic web application frameworks, such as Next.js19:

‘‘There are good frameworks for building isomorphic web applications, take Next.js for example.’’ (I2)

Isomorphic web applications can be tricky for developers, who have worked only on the front-end side of the technology:

‘‘It can come off as cumbersome if you’ve only worked with React.js front-end heavy applications.

Development might take longer for some things’’ (I3)

5.2.8 The general feeling about isomorphic web applications

The general feeling about isomorphic web applications was very positive. The first developer who was interviewed thought isomorphism was about “fixing a problem that shouldn’t exist in the first place”:

‘‘They are a good thing that they exist, but they are fixing a problem that shouldn’t exist in the first place. Many of these problems are only present because of the way our current HTML and Web applications work and how they are designed. How they are ‘‘hacked’’ around the DOM’’ (I1)

The increased needs of web applications were the general feeling of isomorphism for one developer:

‘‘It’s something that growing web apps need to implement at some point. Rendering the whole DOM on the client is going to be slow, when the application grows in size’’ (I2)

5.2.9 Developing isomorphic web applications in another case

Almost every developer stated that they would develop isomorphic web applications when starting a new project or transforming an existing project to use isomorphism:

‘‘Yes. If I start a new project I usually go with an isomorphic web application setup’’ (I2)

One developer would develop an isomorphic web application to a certain point if the complexity does not overcome the benefits:

‘‘Maybe. For modern applications and certain use cases the initial load time is important to get down. Users don’t want to wait too much for the page to load and for the page to become interactive. In e-commerce applications, I would pretty much always go with isomorphism. If the project is more like a management UI or an admin UI where performance matters, but the initial load doesn’t matter (because the user usually goes to the page and spends a few minutes and then leaves), optimizing for initial load is in my opinion not worth the complexity.’’ (I1)

Table 10 Benefits and challenges of isomorphism, based on the results of the case study [42]

Developer	Improved performance	Improved SEO	Improved user experience (UX)	Code sharing	Easier maintainability	Framework and library support	Hard to understand	Increased complexity	State management	Data fetching	Additional requirements	Back-end language	Code duplication
I1	+	+	+	+	+	$-$	$-$	$-$		$-$		$-$
I2	+	+				$-$	$-$	$-$	$-$
I3	+	+	+			$-$			$-$	$-$
I4	+	+	+	+	+	$-$	$-$				$-$
I5	+	+	+			$-$		$-$	$-$		$-$	$-$	$-$
Total	5	5	4	2	2	5	3	3	3	2	2	2	1

Table 11 Comparison of the results of the gray literature review and developer interview [42]

Concept	Gray literature review	Case study
Performance	The performance of the application improves. Devices, which have a slower internet correction load the application faster. The TTFB of an isomorphic web application is higher because the pages are server-side rendered. Therefore, the initial response is slower.	The performance of the application improved, dropping TTI dramatically. However, the initial response might be slower. On the other hand, performance is given with isomorphism. Google’s Lighthouse tool will detect isomorphic web application slowdowns easier than the user.
Search engine optimization (SEO)	Search engine optimization improves with isomorphism. Page crawlers have an easier time indexing the pages.	Page crawlers have an easier time indexing the pages, and crawlers from Facebook and Twitter correctly show a card preview of the page.
User experience (UX)	Isomorphic web applications have a better user experience because no initial loading indicators or blank page flickering are observed.	The UI is generally faster and no blank page flickering is observed.
Code sharing and duplication	Code can be shared in an isomorphic web application, but using isomorphism can also introduce duplicate code.	Code sharing simplifies the changes needed to implement isomorphic web application architecture. Using a different programming language between environments leads to duplicate code.
Maintainability	Maintainability is improved because code can be reused and the server and the client code is separated.	Once the application is set up, it is easier to maintain than a regular SPA.
Complexity	Code complexity is increased, as the browser and the server have to execute the same code identically. Additional infrastructure requirements are also needed.	Additional build tooling configuration is needed.
Back-end language	No mention.	Using a different programming language between the server and the client makes the code more complex.
Framework and library support	It is a challenge to execute the same code in both environments. To be able to use the same library between two different environments, a wrapper library might be needed.	Some functionality needs to be polyfilled. Not all libraries support server-side rendering out of the box. Isomorphism adds a lot of boilerplate code.
State management	An “isomorphic handoff” needs to be done, which complicates things.	State management is challenging with isomorphism because it has to be kept in sync between the server and the client.
Developer experience	Isomorphic web application architecture has a steep learning curve.	Isomorphic web applications are hard to understand in the beginning and require more experience than traditional SPAs.

6 Discussion

In this article, we studied the benefits and challenges of isomorphism in single-page applications. We first go through the research questions and list the key points we found out while conducting this study. Then, we discuss each topic a bit more in detail. The comparison of the results of the gray literature review and developer interview are listed in Table 11.

In the first research question, we asked about the benefits of isomorphic web applications. From the gray literature review and the case study, we found out that the most mentioned benefit was improved performance. The second most mentioned benefit was improved SEO. The increased performance of the application leads to better UX. Fourth on the list was code sharing, which makes the application easier to maintain. The least mentioned benefit of all was old device support.

The second research question asked about the challenges of adopting isomorphism in single-page applications. Increased complexity was mentioned the most. Isomorphic web applications can be hard to understand and the framework and library support of isomorphic web applications is something the developers need to address. Even though isomorphic web applications are said to have increased performance, a slower initial response might be observed, because the server needs to pre-render the page. Pre-rendering the page server-side causes increased server load. The state of the isomorphic web application needs to be synchronized between the server and the client, so state management opposes a challenge.

6.1 How do Isomorphic Web Applications Affect the End-users?

Increased performance was mentioned many times, both in the gray literature review and the case study. The increased performance of the application was observed in the TTI of the application. However, the TTFB increases with isomorphism because the server has to pre-render the page. This can be solved with caching, but it adds additional complexity to the application. UX is improved with isomorphism because no blank page flickering or loading indicators can be observed in the UI. On devices with slower internet connections, the increased performance of the application can be noticed more easily.

6.2 What Does Isomorphism Bring for Developers?

SEO is a benefit of isomorphic web applications for developers, mentioned in both parts of the study. Even though most search crawlers can index modern web pages that use JavaScript, there are certain limitations on the crawling process. The environment where the search crawlers run on is limited, which means polyfills might be needed to be able to crawl the page correctly. Crawlers that generate previews for Facebook and Twitter work well with isomorphic web applications because the HTML meta tags are inserted into the page in the first response.

Code sharing and duplication is a topic that the articles and developers had many opinions about. The application code can be shared in an isomorphic web application, but code can still get duplicated in some scenarios, for example, when choosing a different programming language for the server of the application.

The ability to re-use code between environments improves the maintainability of isomorphic web applications. The maintainability benefit can be observed after the application has been set up.

Isomorphic web applications introduce additional boilerplate to the application. Because the same code must work on both the server and the client environments, additional abstraction and polyfills might be required. Additional server infrastructure is needed because requests to isomorphic web applications must be handled by a server. Google Lighthouse20 is a tool that developers can use to measure the speed of their isomorphic web application.

In most of the articles and mentioned by developers, JavaScript is the most popular programming language when talking about isomorphic web applications. It is beneficial to choose the same programming language for the server and the client to be able to share code. However, when choosing a different programming language for the server, it will make the application’s code more complex.

Framework and library support was a challenge that was mentioned many times during the gray literature review and the case study. Not all libraries support running the same code in the server and the client environments. Additionally, writing extra code and creating polyfills to make certain libraries function in an isomorphic environment might be mandatory. The differing environments, where the server and the client run, can in the worst-case scenario introduce browser compatibility issues, bugs, and inconsistencies.

The application’s state in isomorphic web applications must be kept in sync between the server and the client. In the gray literature review, this process was called the “isomorphic handoff”. If the states between the server and the client are mismatched, flickering or weird behavior can be observed.

The developer experience mentioned in the articles and by the developers was positive. All interviewed developers would develop isomorphic web applications in another case (for example, when starting a new project). In most cases, the benefits of isomorphism give outweigh the challenges the technology has. With careful planning, the challenges can be minimized.

After reading through the results of the gray literature review and the case study, we interpret that isomorphism in single-page applications introduce new opportunities for developers to improve application performance, SEO and UX, at the cost of increased complexity and the need of additional libraries to support isomorphism. In addition, the developers stated that isomorphism is hard to understand at the beginning, which could make implementing isomorphic web application architectures slower and therefore more expensive.

6.3 Validity of the Results

As there is not that much scientific literature available about isomorphic web applications, we chose to use gray literature. Most of the resources about isomorphic web applications that exist on the internet are blog posts. By definition, low credibility sources include blogs, emails, and tweets [16]. The blog posts, which we selected as candidates in the literature review, are either implementation guides or experiences working with isomorphism.

We took great caution in the process of choosing the gray literature. First, we identified any existing reviews. Then, we proceeded with the planning of the gray literature review and started to construct our research questions. The research questions we chose met our requirements for the target audience and review goals. With the two selected research questions, we were able to compare the results of the gray literature review and the case study. The two research questions that we chose belong to the exploratory research question category [16]. To be able to use the internet articles in the gray literature review, we conducted a gray literature quality assessment [16]. Based on the results of the quality assessment, we formed the final list of gray literature and could continue on the literature review process.

Both in the gray literature review and the case study, we assumed that the results are positively biased. The gray literature review resulted in a total of 52 positive and 21 negative points for isomorphic web applications, which supports our theory that gray literature might be positively biased. On the other hand, the results of the case study were much more balanced; a total of 18 positive and 21 negative points were observed in the case study. The possible reason why we see a much more balanced outcome in the case study might be because we interviewed only five developers. With a small sample size, not all possible answers and opinions are taken into count.

7 Conclusions

In this article, we studied the benefits and challenges of isomorphism in single-page applications. To study these benefits and challenges, we conducted a two-part study, which included a gray literature review and a case study. A total of 20 gray literature articles were reviewed. We also interviewed five developers, who have experience working with isomorphic web applications before. The interviews were transcribed and a comparison with the gray literature review was made.

The results show that isomorphic web applications have benefits for both the end-users and the developers, bringing trade-offs that the developers must be aware of. The downsides and challenges of isomorphic web applications mostly focus on the developer side of the technology.

The benefit of isomorphic web applications, which we observed, was the increased performance of the application. The TTI of the application is reduced, but because the page needs to be rendered server-side, TTFB is increased. Compared to SPAs, an isomorphic web application has a better UX, because it does not have loading spinners or blank-page flickering. Isomorphic web applications also support older devices, which do not have JavaScript support. The isomorphic web application architecture improves the SEO of the application, making all kinds of search crawlers crawl the content of the page correctly. The developers can reuse some application code between the server and the client, to increase the maintainability of the application. In an isomorphic web application, the application infrastructure is more complex because the server pre-rendering the pages has to be set up. Different browsers have different kinds of environments they use, so developers might have to polyfill browser-dependent features to make the application work across different versions of web browsers. Some libraries do not work with isomorphism out of the box, which requires additional work for the libraries to be functional in an isomorphic environment. State management is a big challenge of isomorphism because the state needs to be kept in sync between the server and the client.

The main motivation to research more about isomorphic web applications is the lack of scientific literature around it. For further research, it would be interesting to see how a specific implementation of isomorphic web applications would solve the challenges of isomorphic web application development that we found out when conducting this study.

References

[1] Yudhajit Adhikary. Client side rendering vs server side rendering in react.js. [Accessed 5th May 2021]. Apr. 2020. URL: https://yudhajitadhikary.medium.com/client-side-rendering-vs-server-side-rendering-in-react-js-next-js-b74b909c7c51.

[2] ahrefs Backlinks Checker. [Accessed 28th October 2022]. 2022. URL: https://ahrefs.com/backlink-checker.

[3] Airbnb. Render your Backbone.js apps on the client and the server, using Node.js. [Accessed 5th May 2021]. Oct. 2012. URL: https://github.com/rendrjs/rendr.

[4] angular vs backbone vs gatsby vs next vs vue. [Accessed 9th October 2022]. 2022. URL: https://npmtrends.com/angular-vs-backbone-vs-gatsby-vs-next-vs-vue.

[5] Aziz Barbar and Anis Ismail. “Search Engine Optimization (SEO) for Websites”. In: Proceedings of the 2019 5th International Conference on Computer and Technology Applications. ICCTA 2019. Istanbul, Turkey: Association for Computing Machinery, 2019, pp. 51–55. ISBN: 9781450371810. DOI: 10.1145/3323933.3324072. URL: https://doi-org.libproxy.helsinki.fi/10.1145/3323933.3324072.

[6] L. Birdeau et al. “Delivery of data and formatting information to allow client-side manipulation”. U.S. patent 8136109B1. 2002.

[7] Spike Brehm. Isomorphic Javascript: The Future of Web Apps. [Accessed 5th May 2021]. Nov. 2013. URL: https://medium.com/airbnb-engineering/isomorphic-javascript-the-future-of-web-apps-10882b7a2ebc.

[8] Benjamin Burkholder. Javascript SEO: Server Side Rendering vs. Client Side Rendering. [Accessed 5th May 2021]. July 2018. URL: https://medium.com/@benjburkholder/javascript-seo-server-side-rendering-vs-client-side-rendering-bc06b8ca2383.

[9] Peter Chang. Break Down Isomorphic and Universal Boilerplate: React-Redux Server Rendering. [Accessed 5th May 2021]. Mar. 2017. URL: https://hackernoon.com/isomorphic-universal-boilerplate-react-redux-server-rendering-tutorial-example-webpack-compenent-6e22106ae285.

[10] Coursera. Why and How Coursera Does Isomorphic Javascript: A Fast and Snappy Quiz. [Accessed 5th May 2021]. Aug. 2015. URL: https://medium.com/coursera-engineering/why-and-how-coursera-does-isomorphic-javascript-a-fast-and-snappy-quiz-a42acdd59ef8.

[11] M. Cui and S. Hu. “Search Engine Optimization Research for Website Promotion”. In: 2011 International Conference of Information Technology, Computer Engineering and Management Sciences. Vol. 4. 2011, pp. 100–103. DOI: 10.1109/ICM.2011.308.

[12] Yanze Dai. Server-side rendering (SSR) for an SPA project. [Accessed 5th May 2021]. July 2020. URL: https://dev.to/daiyanze/server-side-rendering-ssr-for-an-spa-project-2ogl.

[13] Elavarasi DC. Isomorphic Web Applications. [Accessed 5th May 2021]. July 2020. URL: https://medium.com/@elavarasi/isomorphic-web-applications-5fbd3118eba9.

[14] Roelof Jan Elsinga. Isomorphic Javascript: What is it and what can I do with it? [Accessed 5th May 2021]. Aug. 2019. URL: https://dev.to/roelofjanelsinga/isomorphic-javascript-what-is-it-and-what-can-i-do-with-it-3mkp.

[15] Facebook Inc. React – A Javascript library for building user interfaces. [Accessed 6th Feb 2021]. 2013. URL: https://reactjs.org/.

[16] Vahid Garousi, Michael Felderer, and Mika V. Mäntylä. “Guidelines for including grey literature and conducting multivocal literature reviews in software engineering”. In: Information and Software Technology 106 (2019), pp. 101–121, ISSN: 0950-5849. DOI: https://doi.org/10.1016/j.infsof.2018.09.006. URL: https://www.sciencedirect.com/science/article/pii/S0950584918301939.

[17] Mehmetcan Gayberi. Isomorphic (Universal) Javascript. [Accessed 5th May 2021]. Jan. 2017. URL: https://medium.com/commencis/isomorphic-universal-javascript-496dc8c4341a.

[18] E.K. Gordon. Isomorphic Web Applications: Universal Development with React. Manning Publications, 2018. ISBN: 9781617294396. URL: https://books.google.fi/books?id=DvThAQAACAAJ.

[19] Elyse Kolker Gordon. An Introduction to Isomorphic Web Application Architecture. [Accessed 5th May 2021]. Nov. 2016. URL: https://medium.com/@ElyseKoGo/an-introduction-to-isomorphic-web-application-architecture-a8c81c42f59.

[20] Gert Hengeveld. Next-gen Web Apps with Universal JavaScript. [Accessed 5th May 2021]. May 2015. URL: https://medium.com/@ghengeveld/on-the-road-to-isomorphism-eb0742a9305f.

[21] Christian Iacullo. What on earth is an isomorphic application? [Accessed 5th May 2021]. Jan. 2018. URL: https://medium.com/@christianiacullo/what-on-earth-is-an-isomorphic-application-cd13d8fb87d5.

[22] Max Jung. Why You’ll Always Need Isomorphic JavaScript. [Accessed 5th May 2021]. July 2016. URL: https://medium.com/@asyncmax/why-youll-always-need-isomorphic-javascript-bd310596d203.

[23] J. B. Killoran. “How to Use Search Engine Optimization Techniques to Increase Website Visibility”. In: IEEE Transactions on Professional Communication. 56.1 (2013), pp. 50–66. DOI: 10.1109/TPC.2012.2237255.

[24] Azat Mardan. Why Everyone is Talking About Isomorphic/Universal JavaScript and Why it Matters. [Accessed 5th May 2021]. Mar. 2016. URL: https://medium.com/capital-one-tech/why-everyone-is-talking-about-isomorphic-universal-javascript-and-why-it-matters-38c07c87905.

[25] Michael S. Mikowski and Josh C. Powell. Single page web applications: JavaScript end-to-end. Manning, 2014.

[26] Lee Mitchell. An Overview of Server Side and Isomorphic Async Rendering. [Accessed 5th May 2021]. Feb. 2020. URL: https://hackernoon.com/an-overview-of-server-side-and-isomorphic-async-rendering-hr743bsa.

[27] Kashyap Mukkamala. A comparison of Server Side Rendering in React and Angular applications. [Accessed 5th May 2021]. Sept. 2018. URL: https://levelup.gitconnected.com/a-comparison-of-server-side-rendering-in-react-and-angular-applications-fb95285fb716.

[28] Brian Neville-O’Neill. Why you should render React on the server side. [Accessed 5th May 2021]. July 2019. URL: https://dev.to/bnevilleoneill/why-you-should-render-react-on-the-server-side-hb3.

[29] Juampy NR. What is an isomorphic application? [Accessed 2nd Feb 2021]. June 2015. URL: https://www.lullabot.com/articles/what-is-an-isomorphic-application.

[30] L. D. Paulson. “Building rich web applications with Ajax”. In: Computer 38.10 (2005), pp. 14–17. DOI : 10.1109/MC.2005.330.

[31] A. Rauschmayer. Is “Isomorphic JavaScript” a good term? [Accessed 16th Apr 2021]. Aug. 2015. URL: https://2ality.com/2015/08/isomorphic-javascript.html.

[32] Emmit Scott. SPA Design and Architecture: Understanding Single Page Web Applications. 1st. USA: Manning Publications Co., 2015. ISBN: 1617292435.

[33] William Oliveira da Silva and Paulo Roberto Farah. “Characteristics and Performance Assessment of Approaches Pre-Rendering and Isomorphic Javascript as a Complement to SPA Architecture”. In: Proceedings of the VII Brazilian Symposium on Software Components, Architectures, and Reuse. New York, NY, USA: Association for Computing Machinery, 2018, pp. 63–72. ISBN: 9781450365543. DOI: 10.1145/3267183.3267190. URL: https://doi-org.libproxy.helsinki.fi/10.1145/3267183.3267190.

[34] Sujaan Singh. Why do we love Isomorphic/Universal rendering? [Accessed 5th May 2021]. Sept. 2019. URL: https://medium.com/@sujankanwar/why-do-we-love-isomorphic-universal-rendering-988c22933933.

[35] Sunny Singh. The benefits and origins of Server Side Rendering. [Accessed 5th May 2021]. Jan. 2019. URL: https://dev.to/sunnysingh/the-benefits-and-origins-of-server-side-rendering-4doh.

[36] Some. You Might Not Need Server Side Rendering. [Accessed 5th May 2021]. Jan. 2019. URL: https://hackernoon.com/you-might-not-need-server-side-rendering-f2681e02e4e.

[37] K. Sons et al. “xml3d.js: Architecture of a Polyfill implementation of XML3D”. In: 2013 6th Workshop on Software Engineering and Architectures for Realtime Interactive Systems (SEARIS). 2013, pp. 17–24. DOI: 10.1109/SEARIS.2013.6798104.

[38] Yiyi Sun. “Server-Side Rendering”. In: Practical Application Development with AppRun: Building Reliable, High-Performance Web Apps Using Elm-Inspired Architecture, Event Pub-Sub, and Components. Berkeley, CA: Apress, 2019, pp. 191–217. ISBN: 978-1-4842-4069-4. DOI: 10.1007/978-1-4842-4069-4_9. URL: https://doi.org/10.1007/978-1-4842-4069-4_9.

[39] A. Taivalsaari et al. “Web Browser as an Application Platform”. In: 2008 34th Euromicro Conference Software Engineering and Advanced Applications. 2008, pp. 293–302. DOI: 10.1109/SEAA.2008.17.

[40] Jane Webster and Richard T. Watson. “Analyzing the Past to Prepare for the Future: Writing a Literature Review”. In: MIS Quarterly 26.2 (June 2002), pp. xiii–-xxiii. ISSN: 0276-7783.

[41] Jeff Whelpley. Isomorphic JavaScript is Dead…Long Live Isomorphic JavaScript! [Accessed 5th May 2021]. Dec. 2017. URL: https://hackernoon.com/isomorphic-javascript-is-dead-long-live-isomorphic-javascript-743e1b7b181c.

[42] Aleksi Huotala. Benefits and Challenges of Isomorphism in Single-Page Applications: A Case Study and Review of Gray Literature, 2021.

Footnotes

¹https://angularjs.org/

²https://backbonejs.org/

³https://redux.js.org/

⁴https://axios-http.com/docs/intro

⁵https://tanstack.com/query

⁶https://www.meteor.com

⁷https://www.google.com/webmasters/tools/siteoverview

⁸https://analytics.google.com/

⁹https://www.bing.com/webmasters

¹⁰https://archive.org/

¹¹https://reddit.com

¹²https://medium.com

¹³https://dev.to

¹⁴https://hackernoon.com

¹⁵https://developers.google.com/search/docs/advanced/crawling/googlebot

¹⁶https://phantomjs.org/

¹⁷https://www.npmjs.com/

¹⁸https://www.djangoproject.com/

¹⁹https://nextjs.org/

²⁰https://developers.google.com/web/tools/lighthouse

Biographies

Aleksi Huotala is a software developer working in a Finnish technology consulting company. Aleksi received his bachelor’s degree and master’s degree in computer science in 2019 and 2021, respectively, from University of Helsinki, Finland. His research interests include software development tools and web development.

Matti Luukkainen is a senior lecturer at University of Helsinki, Finland. He received his Ph.D. in computer science in 2003. His present research interests include continuous software development and software engineering education.

Tommi Mikkonen is a professor of software engineering at University of Jyväskylä, Finland. He received his Ph.D. on software engineering from Tampere University of Technology year 1999. His interests include web programming, IoT, and software architectures.