![The figure shows a page comparable in three configurations: SSR, progressive hydration, and islands architecture. All the components are rendered together and then hydrated for the SSR option. In the case of progressive hydration, all the components are rendered, key components are hydrated first, and the rest are then progressively hydrated. For islands architecture, static components are server-rendered HTML; a script executed on the client side is required only for the interactive components. [11] 4](https://www.researchgate.net/publication/377351753/figure/fig1/AS:11431281217246600@1705066862996/The-figure-shows-a-page-comparable-in-three-configurations-SSR-progressive-hydration_Q320.jpg)
Available via license: CC BY-NC-ND 4.0
Content may be subject to copyright.
Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2023.0322000
Resumability - a New Primitive for Developing
Web Applications
Juho Vepsäläinen 1, Miško Hevery2, and Petri Vuorimaa3
1Doctoral Researcher at Department of Computer Science, School of Science, Aalto University, Espoo, Finland
2CTO at Builder.io
3Professor at Department of Computer Science, School of Science, Aalto University, Espoo, Finland
Corresponding author: Juho Vepsäläinen (e-mail: juho.vepsalainen@aalto.fi).
ABSTRACT Hydration is a common technique employed by current JavaScript-based frontend frameworks,
such as React. In hydration, the application code is re-executed on the client to recover component bound-
aries, application state, and event listeners. In this article, we look into a new primitive called resumability
that avoids the work as the necessary information is serialized into HTML. The idea has been adopted by Asta
(2023), Google Wiz, Marko (planned for version 6 [1]), Sidewind (since 2022), and Qwik (2021) as a main
building block. Resumability gives these solutions unique advantages by avoiding the cost of hydration.
Furthermore, resumability can allow developers to leverage code-splitting out of the box, depending on
the implementation. The shift has implications for both developer and user experience. This article aims
to understand why resumability matters and why it is a good option for replacing earlier hydration-based
approaches. We also consider challenges related to adopting resumability on a framework level and briefly
highlight the first resumable solutions for developing web applications.
INDEX TERMS hydration, JavaScript, multi-page applications, page size, resumability, single page appli-
cations, software architecture, web application development, web performance, world wide web
I. INTRODUCTION
In 1992, the World Wide Web was meant as a global infor-
mation exchange [2]. Since then, the web has morphed into
the largest application platform available, reaching roughly
two-thirds of the global population [3]. At the same time, the
size of websites and the share of mobile usage are constantly
rising, as reported by [4], [5]. It is telling that in [4] data, the
median page weight on desktop grew from 669 kilobytes in
March 2012 to 2060 kilobytes in March 2022. The change
has been more drastic on mobile, and a nearly 600 % increase
in page size has been reported [4]. JavaScript contributes
roughly one-third of the size, making it the second biggest
contributor after images and a clear optimization target [4].
A. COST OF JAVASCRIPT
The cost of JavaScript is two-fold. In addition to having a cost
in terms of kilobytes to transfer, there is also a significant
cost related to parsing and evaluating the code1. Especially
in a mobile environment, the cost is felt in terms of reduced
battery life due to increased processing. Due to lower compu-
tational capacities, application performance experienced by
1This is particularly true within a mobile environment when JavaScript
payloads are big enough [6].
the user may be reduced. Due to the cost, any reduction to the
size of JavaScript has a considerable impact on the end user,
and even deferring the cost can be beneficial.
B. SINGLE PAGE APPLICATIONS
Single Page Applications (SPAs) were motivated by the need
to develop highly interactive solutions on top of the web [7],
and they came with many clear benefits for both developers
and users compared to earlier models, such as Multi-Page
Applications (MPAs). SPAs also came with new challenges
related to Search Engine Optimization (SEO), reliance on
JavaScript, and high cost of loading [8]. Especially the cost
of loading has become an urgent issue.
C. NEED FOR RESEARCH AND SOLUTIONS IN THE SPACE
In [9], it was shown that a large majority of external resources
are typically loaded as render-blocking code. In contrast, only
a small portion of the code is used on the initial page load,
implying significant potential for performance improvements
[9]. The finding highlights the need for research and develop-
ment in the space.
VOLUME 11, 2023 1
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Juho Vepsäläinen et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
D. EARLY POTENTIAL OF DISAPPEARING FRAMEWORKS
As discussed by [8], so-called disappearing frameworks ad-
dress challenges related to SPAs by addressing the problem
of shipping as little JavaScript to the client as possible. It is
not only frameworks that matter, but application code specif-
ically, as there is a concrete cost related to loading the code.
One of the possible techniques allowing developers to load
less and later is resumability.
E. RESUMABILITY ALLOWS DEVELOPERS TO LOAD LESS
JAVASCRIPT UPFRONT
Resumability addresses the cost of turning HTML markup
sent to the client into an interactive application by performing
some of the necessary work beforehand on the server, handing
it over to the client, and then picking it up on demand.
In contrast, the current mainstream JavaScript frameworks
implement a hydration technique where JavaScript code is
required to turn a page interactive; it has to be shipped and
evaluated by the client, leading to a double cost [10]. Hydra-
tion can be optimized through approaches, such as islands
architecture [11], but that does not solve the fundamental
issue of hydration fully that resumability avoids by changing
the axioms.
F. HOW CAN RESUMABILITY HELP TO ADDRESS THE
PROBLEM OF GROWING WEBSITE WEIGHT
Since website weight is a significant issue in web develop-
ment and resumability may be one of the key ways to address
it, we have formed the following research question: How does
resumability address the problem of growing website weight?
To understand how we arrived at the concept of resuma-
bility and what motivated its development, we consider the
technical background in Section II. In the following Section
at III, we delve into the concept through the examples of
Sidewind and Qwik. Then, in Section IV, we consider the
implications of resumability and its potential for web devel-
opment. Finally, we conclude the article in Section V and
consider what potential research directions.
II. BACKGROUND
The evolution of the web could be characterized as a shift
from pure websites meant for distributing information and
linking it together to running whole applications on top of
the platform. Several desktop applications leverage web tech-
nologies, such as Electron, underneath. Given that the web
was not designed as an application platform, it went through
growing pains over the decades.
A. EARLY STEPS TOWARDS INTERACTIVITY
The early web did not have a clear way to add interactiv-
ity to websites. In 1995, Netscape Communications, one of
the early successful browser vendors, decided that the web
needed a scripting language [12]. The task was given to
Brendan Eich, who created an early version of JavaScript,
which, despite the name, did not have much to do with the
popular Java language [12]. The idea was that JavaScript
code would be combined with Java applets and other com-
ponents [13]. Early Document Object Model (DOM) was an
API allowing developers to dynamically access and update
documents’ content, structure, and style, and it was available
through JavaScript [14].
B. MULTI-PAGE APPLICATIONS
Early web applications were implemented using the MPA
model in which the application state lives on the server, and
each request from the client to the server reloads the page [7].
The model has several benefits as the initial cost of loading an
individual page can be low [15], Search Engine Optimization
(SEO) is easy [7], [15], there is no dependency on JavaScript
[7], [15], and security practices are well understood [15]. For
a highly interactive application, MPA as a model is imprac-
tical due to its primary constraint of maintaining the state on
the server and refreshing a page on state change.
C. INTRODUCTION OF AJAX
DOM was an important step towards interactive web ap-
plications, but it was not enough. In 1997, Microsoft in-
troduced DHTML and XMLHTTP [13]. Most importantly,
XMLHTTP contained XMLHttpRequest API enabling asyn-
chronous JavaScript (AJAX) development popularized in
2005 by [16]. Using AJAX, developers could fetch data in
the background without refreshing a page [16], allowing new
development models, such as SPAs, to be invented.
D. EMERGENCE OF JQUERY
Given DOM APIs can be difficult to use, a group of libraries
hiding the details and different browser behavior emerged
in the early 2000s. jQuery (2006) is the most successful
example, and it has wide usage, reaching close to 80 % of
websites globally in data tracked by [17]. One of the main
attractions of jQuery was that it could compress the amount
of code needed from tens of lines to only a few through its
chaining syntax [18].
As jQuery does not provide structure for application de-
velopment, frameworks like Backbone.js (2010) and Knock-
out.js (2010) were developed to address its shortcomings. The
current mainstream solutions, including React, Angular, and
Vue, were built to respond to deficiencies in these frame-
works. They implement the SPA model.
E. SINGLE PAGE APPLICATIONS
In contrast to MPAs, SPAs do not rely on refreshing a page
on state change [15]. Instead, they maintain the application
state in the browser and update the user interface dynamically
based on user interaction [15]. As only transaction-related
data moves between the client and the server, the SPA model
can save bandwidth compared to MPAs [7] while coming with
an initial loading cost [15]. These characteristics make SPAs
ideal for long-running and complex web applications where
the initial loading time does not matter.
2VOLUME 11, 2023
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
SPAs have challenges related to SEO [7], [15], [19], se-
curity [7], and potentially routing [15] although the routing
problem has been largely solved by 2023.
Generally, SPA frameworks implement the following con-
cepts [8]: component abstraction, templating, and hydration.
Components provide a way to encapsulate markup and poten-
tially local state, while templating solution, such as JSX or
a domain-specific language, captures markup. The challenge
is how to turn static markup rendered by the server into an
interactive application suitable for a user, and that is where
hydration comes in. Hydration re-uses the existing DOM
nodes, attaches event handlers, and executes component logic
[20].
F. CHALLENGES OF HYDRATION
By definition, hydration requires application component-
related code to run, as hydration is about re-running appli-
cation code to learn about the system’s state. In other words,
there is code to download, parse, and execute. Each of these
steps comes with an associated cost and is visible in the initial
loading cost related to using SPA. Using code-splitting can
defer the cost by allowing code to be loaded later [21]. It is
important to note that this applies only to components not
existing in the initial render tree, reducing the approach’s
usefulness. In other words, code-splitting may be used for
cases requiring user interaction or some other trigger, such
as an intersection observer.
Another option is to push work to build time, as in Static
Site Generation (SSG), where component markup is gener-
ated ahead of time and then served to the user [22]. Markup
generation can also occur during Server-Side Rendering
(SSR) or incremental server regeneration (ISR) passes [22].
Regardless of the approach used to generate the markup, the
hydration process remains the same, meaning earlier draw-
backs remain. Next.js framework is a notable example as
it implements these strategies and allows the developer to
choose between them depending on the use case [23].
Progressive hydration allows hydrating the most critical
components first while hydrating the rest later, although there
is a caveat in the sense that hydration must begin from ap-
plication root [11]. Islands architecture limits the problem
to specific dynamic islands loaded using a specific strategy
while treating the rest of the page as static [11]. It can be
argued that islands are not without their challenges, as you
have the problems of inter-island communication and page
navigation to consider2. Figure 1 illustrates how the three
basic approaches to hydration differ.
III. RESUMABILITY
Resumability approaches the problem solved by hydration
from a different angle. Most importantly, resumability skips
the re-execution portion of hydration, given the compo-
nent boundaries, state, and event listeners are serialized into
2React Server Components address these problems in their way while
coming with a server requirement [24].
HTML, and the client will then pick up from there [25].
Both hydration and resumability have to provide front-end
knowledge about the application. In hydration, the knowledge
is passed via the execution of application components, while
in resumability, the same is achieved by deserializing HTML.
Through serialization, resumability avoids a significant cost
related to hydration at the cost of having to provide the initial
starting point as HTML [26].
A. IMPLEMENTING RESUMABILITY
Technically, resumability is surprisingly simple to imple-
ment as it boils down to how to resume state and execution
from HTML markup. In any case, a JavaScript runtime is
required. Simultaneously, a resumable approach can be de-
signed with progressive enhancement [27] in mind so that the
code will work even if JavaScript is disabled for the client.
Implementation-wise, the question is how much work to do
and how far to go. In the most straightforward implementa-
tions, it is enough to figure out how to read the state from
HTML to a state container. More complex implementations
can do optimizations related to event handling and code-
splitting [21] for example, as those are possible to do in a
novel manner on top of resumability.
1) Sidewind - a runtime leveraging resumability
Sidewind3(2019) is an example of a library that leverages
the idea of resumability. Sidewind is a light4state manage-
ment solution designed to be used directly within HTML
using specific directives modeled using HTML attributes and
standard event handlers. Through resumability, a Sidewind-
based state container can restore its state from the HTML
markup. Sidewind fulfills the criteria for resumability by not
re-executing the application on the client and by serializing
state, listeners, and bindings to HTML.
The example below illustrates the syntax of Sidewind for
a case where execution is resumed in the frontend as it con-
structs its state from HTML and then begins to operate on the
state as visible in the xbinding that shows the loaded data
structure to the client. Due to the way state is included in the
initial HTML markup, the page can be considered to follow
the principle of progressive enhancement [28]. The benefit of
progressive enhancement is that the page would work to some
extent without JavaScript, making it more accessible, not to
mention potentially having SEO benefits.
3https://sidewind.js.org/
4The minified version of Sidewind is roughly 16 kilobytes, and the cost can
be reduced further to around 6 kilobytes by using gzip compression during
transmission. The implementation can be optimized further as the current
version includes all the functionality, and everything is loaded eagerly.
VOLUME 11, 2023 3
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Juho Vepsäläinen et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
<div x-state="{ todos: [] }">
<ul x-each="state.todos" x-ssr>
<li x-template>
<span x="state.value.text">Rate</span>
<ul x-each="state.value.entity.tags">
<li x-template x="state.value">
chore
</li>
</ul>
</li>
<li x-template>
<span x="state.value.text">Read</span>
<ul x-each="state.value.entity.tags">
</ul>
</li>
</ul>
<div x="JSON.stringify(state.todos)"></div>
</div>
It is important to note that Sidewind has no opinions re-
garding how components should be created, so integrating
Sidewind within existing environments or developing your
abstractions to support it may be beneficial. There are also
no strong opinions on how events should be handled or how
more complex code should be loaded, as the developer can
decide how to handle these concerns.
2) Resumability can be decoupled from event handling
Unlike in hydration-based approaches, resumability can be
decoupled from event handling. For example, in Qwik5, one
global event handler leverages browser event bubbling behav-
ior, and events are then activated by user interaction [26]. Due
to this feature, in Qwik, the amount of event handlers spec-
ified by a developer does not contribute to the application’s
5https://qwik.builder.io/
running cost. In Sidewind, the situation is not as straightfor-
ward as the library leverages standard event handlers. It is an
implementation detail of whether or not a single global event
handler should be used.
Figure 2 illustrates the difference in the loading behavior
of hydration against resumability when the user wants to use
an interactive portion of a user interface, especially when a
solution like Qwik is used. It is good to note that while the
hydrated case is loaded eagerly, the resumable case can be
loaded lazily on demand based on user interaction.
FIGURE 2. The figure illustrates how hydration and resumability differ in
loading behavior. While in the naïve hydration case, framework and
application code are loaded eagerly, in resumability, only runtime is
loaded initially, and application code can be loaded on demand. In the
image, the user intends to operate (1) the carousel component, and then
(2) the runtime shipped to the client downloads (3) the related code. To
provide more flexibility, a framework can let the developer adjust this
behavior to consider different use cases, such as mobile and low
bandwidth scenarios.
3) Code-splitting as a first-class citizen
To optimize application loading in hydration-based ap-
proaches, code-splitting [21] is used to defer loading based
FIGURE 1. The figure shows a page comparable in three configurations: SSR, progressive hydration, and islands architecture. All the components are
rendered together and then hydrated for the SSR option. In the case of progressive hydration, all the components are rendered, key components are
hydrated first, and the rest are then progressively hydrated. For islands architecture, static components are server-rendered HTML; a script executed on
the client side is required only for the interactive components. [11]
4VOLUME 11, 2023
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
on interaction or some other trigger. In islands architecture
[11], a similar effect is achieved on an architectural level. Re-
sumability can enable more fine-grained code-splitting than
earlier approaches. For example, Qwik leverages the dollar
($) character to signify a split point, as in the example below
adapted from [29]6.
import *as qwik from "@builder.io/qwik";
export default qwik.component$(() => {
const count = qwik.useSignal(0);
return (
<div>
<span>Count: {count.value}</span>
<button onClick$={() => count.value++}>
Click
</button>
</div>
);
});
Due to its approach, Qwik’s code-splitting boundaries can
be small as they can exist for views, state, and event handlers
[29], unlike in earlier approaches limited to module, typically
component, boundaries. For more complex use cases, Qwik
allows developers to tune the behavior through a Service
Worker [30].
In the case of Sidewind, it is up to the developer to decide if
they want to leverage code-splitting at an event handler level.
Therefore, resumability can be seen as an enabler of granular
code-splitting, and as a concept, it does not guarantee it as it
is an implementation detail.
B. CHALLENGES OF IMPLEMENTING RESUMABILITY
As a new idea, implementing resumability comes with its
challenges. To keep the approach ergonomic, at least some
abstraction is required. In Sidewind runtime, the ergonomics
are somewhat solved by leveraging standard HTML. For
Qwik and Marko, the frameworks have opted for leveraging
a compiler that hides much of the complexity and enables
functionality, such as granular code-splitting. It can be argued
that the existence of a runtime or a compiler comes with
its complexity as there is more for developers to debug and
understand, as the code you write is not entirely what you
may evaluate in the browser. However, the same problem
applies to most mainstream frontend solutions as they rely
on techniques, such as transpilation, that transform code to a
form understandable by the browsers.
1) Serialization requirements constrain a resumability-based
system
Given that resumability relies on the ability of the server
to serialize data into a format that the client can resume,
that gives a significant constraint for implementations. In
other words, data structures that cannot be serialized cannot
live in a resumable system. The same constraint does not
6Examining different code extraction patterns would worth studying on its
own in detail as what we cover here is only one option out of many.
exist in hydration-based systems, and they can consume non-
serializable data without problems.
2) Programming language constraints for resumability
based systems
When a resumability-focused library like Sidewind is used,
the main constraint between the server and the client is that
the server generates markup that the client-side runtime can
parse and restore as a JavaScript structure. Therefore, in this
case, the backend requirements are relatively light.
The situation is more complex for JavaScript frameworks
like Qwik or Marko7as they allow developers to implement
backend logic. The situation is more constrained in these
cases as the backend requires a JavaScript runtime to work.
Simultaneously, developers can achieve more within the same
framework and may be able to implement the most vital parts
of web applications using these solutions.
C. POTENTIAL FOR ADOPTION BY FRAMEWORKS
For framework authors, resumability poses a challenge as it
means a framework has to be reimagined from the ground up
since underlying assumptions related to data loading differ
from hydration-based approaches. The main difference con-
cerns state management and how the state is loaded progres-
sively over time as needed. The biggest shift concerns how
a part of the state is serialized to the initial markup so the
client can resume on it. As a novel idea, there are limited
implementation examples in the wild. The biggest obstacle
to larger framework adoption is the compiler requirement for
ergonomics. However, a runtime-based alternative may be
viable up to a point, as shown by the example of Sidewind.
D. FRAMEWORKS AND LIBRARIES LEVERAGING
RESUMABILITY
Given that it is early days with resumability, possible ways
to implement it have not been fully explored as only a few
implementations exist. The main ones are Qwik, Wiz, and
Sidewind. Out of these three, not much is known about Wiz as
it is closed-source and not distributed publicly. In the case of
Marko, resumability is planned [1] but has not been delivered
yet. As a complete, compiled-based framework, Qwik can
extract split points automatically to build on resumability.
In contrast, Sidewind uses resumability only to capture state
from HTML, leaving code-splitting to the user. Technically, it
would likely be possible to build an entire framework around
it, however. It is too early to tell about how Marko will
implement resumability, but given they control both client and
server-side code in their solution, they will likely find a good
way to implement the idea.
To capture the currently available resumable frameworks
and libraries, Table 1 lists the options while considering sev-
eral attributes, including the streaming approach. The stream-
ing approach is one of the factors where the current options
differ, as their servers can stream content to the client either
7https://markojs.com/
VOLUME 11, 2023 5
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Juho Vepsäläinen et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
TABLE 1. Resumable web application frameworks and libraries
Name Type Templating approach Streaming approach Version Developers Homepage
Asta Framework JSX Unknown 0.0.0 (2023-01-31) Yisar, an individual devel-
oper
https://github.com/yisar/asta
Marko Framework Custom DSL In/out of order [1] 5.32 (2023-11-
17) (beta for
version 6 including
resumability was
planned for Summer
2023 but missed its
deadline [1])
Developed as open source
by eBay Inc. and other con-
tributors
https://markojs.com/
Sidewind Library HTML None 7.6.0 (2022-06-10) Juho Vepsäläinen, an indi-
vidual developer
https://sidewind.js.org/
Qwik Framework JSX In order [1] 1.2.18 (2023-11-16) Developed as open source
by Builder.io, Inc. and other
contributors
https://qwik.builder.io/
Wiz Framework Unknown Unknown Unknown Developed as closed source
by Google
Not available
in or out of order. The same can be said for the templating
approach.
E. EARLY EXPERIENCES WITH RESUMABILITY
As a new approach, there is little experience using resumabil-
ity in practice. That said, early adoption is already visible, in
addition to early empirical evidence that shows the strength
of the approach.
1) Early adoption of resumability in applications
Early adoption of resumability has been visible in various
instances, including Gmail (Wiz, [31]), Google Photos (Wiz,
[31]), Google Search (Wiz, [31]), and eBay (Marko, [32]).
Further, Marko [33] and Qwik [34] based examples are known
to exist. It is safe to say that resumability is still far from a
mainstream idea. More implementations will likely appear as
resumability, and its benefits will be better understood.
2) Early empirical evidence
In [35], it was found that using Qwik can decrease the amount
of JavaScript shipped to the client compared to React. It was
noticed, however, that this comes with a cost in terms of server
rendering time and build time during deployments [35]. The
early results of [36] imply that using Qwik gives benefits in
terms of the initial loading performance of an application. It
is good to note that both studies have limitations and may
not give the full picture as further work is required within the
domain, especially regarding continued application usage.
Google’s Core Web Vitals (CWV) [37] technology report
based on actual usage supports the initial findings and shows
that Qwik-based websites outperform the rest as seen in
Figure 3. It is good to note that there may be some bias in
the numbers as Google evaluated around a hundred sites for
Qwik while at least thousands for others [37]. The low figure
tells about Qwik’s early adoption; more accurate data may be
gained as it becomes more popular.
Similar results can be seen for Google’s median origin
Lighthouse score and page weight, as Qwik is either leading
or near leading in either case [37]. Astro, in particular, can
deliver pages with low page weight, or it is used for sites
with a low page weight, and the same could be argued for
Qwik. Based on the results alone, it is difficult to tell which
case might be true, and as mentioned, there may be bias in
the numbers due to the low sample size for Astro and Qwik
relative to other options.
F. MAIN DIFFERENCES BETWEEN HYDRATION AND
RESUMABILITY
Table 2 captures the main differences between hydration and
resumability to allow contrasting approaches and to capture
the main points presented in this article.
IV. DISCUSSION
Although current mainstream solutions, such as SPAs, allow
us to develop complex, interactive applications, they do not
address the cost of website size and loading as their primary
axioms. Rather, developers have to try to address it on their
own through techniques, like code-splitting, and even then
the results can be suboptimal. By changing the viewpoint,
resumability provides another direction that may yield better
results without additional effort.
A. RESUMABILITY CAN HELP TO ADDRESS THE COST OF
WEBSITE SIZE
Resumability can address the cost issue of websites at the
tooling or library level while making websites faster to load.
In resumability, the server serializes data to the markup,
allowing the client to resume execution as needed. The main
difference is that in a hydration-based approach, the client has
to construct the state of the client independently, therefore
adding cost to the approach. The shift enables code-splitting
[21] as an architectural concern that the developers do not
have to think about unless they prefer to, as prefetching can
become a configurable aspect of an application [30].
6VOLUME 11, 2023
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
FIGURE 3. The figure shows how many websites using a specific JavaScript framework measured by Google have a portion of good Core Web Vitals (CWV)
value while using a mobile client. Astro and Qwik perform above the rest, while Qwik has consistently been better than Astro, especially during the past
few months. Similar results can be seen using a desktop client.
B. RESUMABLE RUNTIMES CAN PROVIDE AN
INTERMEDIATE STEP TOWARDS COMPILERS
As an intermediate solution, resumability can be adopted
through a runtime-based approach at the cost of losing auto-
matic code-splitting. A runtime may be easier to integrate into
an existing project than a compiler-based solution and provide
an alternative to a full refactor or an interim step towards one.
C. CAN MAINSTREAM FRAMEWORKS ADOPT
RESUMABILITY?
One of the open questions is whether current mainstream
frameworks can or even should leverage resumability or will
the concept be adopted solely by new frameworks and li-
braries. Technically it is diametrically opposite to the con-
cept of hydration implemented by many of the frameworks
meaning implementing resumability would represent a major
change and shift in thinking while coming with the constraints
related to serialization requirements.
D. OTHER WAYS TO ACCESS THE COST OF WEBSITE SIZE
The cost of web application size can be potentially mitigated
by leveraging external tools as shown by [38]. The tools,
Waiter and AUTRATAC8, are able to apply code-splitting on
existing codebases and therefore defer loading. In [38] it was
shown that the tools improve First Contentful Paint (FCP),
particularly at slower network speeds. The important point
to make is that the total execution time matched the original
JavaScript but it was loaded with less render blocking which
is a major improvement by itself.
The development of external tooling seems like another
promising way to address the cost of websites. It can be
argued that techniques, like resumability, may provide better
results out of the box but at the same time adopting better
techniques may not be feasible in many cases meaning there
is value in finding solutions that fit existing projects with
minimal effort.
Although the directions of resumability and external tool-
8Both tools are available through GitHub via https://github.com/waiter-a
nd-autratac/WaiterAndAUTRATAC.
TABLE 2. Main differences between hydration and resumability
Aspect Hydration Resumability
Client-side code loading strategy Eager by default, lazy in limited con-
texts
Potentially lazy depending on the solution
Client runtime Library itself can be a runtime that
hydrates application code delivered to
the client
A runtime is generated to load application code that can be loaded separately
Code-splitting approach Component and module-level Granular
Implementation May include a compiler (for example,
JSX) but can be fully a runtime
Most likely implemented as a compiler to enable good development er-
gonomics, although a pure runtime-based solution is possible, as shown by
Sidewind
Programming language require-
ments
None Same language may have to be used on the server and client due to serial-
ization requirements. In Sidewind, it is enough that the server can generate
markup that can be deserialized by client
Server-to-client data serialization No constraints Data passed from the server to the client has to be serializable
VOLUME 11, 2023 7
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Juho Vepsäläinen et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
ing feel orthogonal, there may be some cases where both
resumability and external tooling may be used together as
resumability does not imply automatic code-splitting. In fact,
external tooling could be used to bring the technique to use
cases where only resumability is leveraged initially, espe-
cially when only a resumable runtime is used.
V. CONCLUSION
In this article, we sought to answer the question How does
resumability address the problem of growing website weight?.
Based on [4], we know that site weight, and consequently the
weight of JavaScript execution, is a considerable problem.
Although SPAs have enabled developers to build unprece-
dented, interactive experiences on top of the web platform,
they do not address the size problem as a first-class citizen.
Instead, the developers have to optimize their applications
using techniques such as code-splitting [21] and memoiza-
tion [39], and it can be argued that the results may not be
ideal even then as they push the problem to developers and
may not provide granular enough control. The problem is
that optimization techniques do not address the eager nature
of hydration. Resumability helps to address the site weight
issue by avoiding eager execution and provides one potential
direction for solving the problem of growing web application
size.
A. POTENTIAL RESEARCH DIRECTIONS
As a new approach, many open research questions exist re-
lated to resumability. These can be categorized within ap-
proach, developer, and user-facing directions.
1) Approach related directions
When it comes to resumability as an approach, there are
several levels of validation to be done:
1) Performance against hydration - especially perfor-
mance against hydration using a real-life use case is
interesting to study to see how the approach scales9.
2) Cost per request - given there is more work to be
done by the server by definition, it may make sense
to measure the cost per request against established
approaches. [35] provided initial insight into the topic,
but more research is needed.
3) Continued usage of an application and impact on the
overall performance - [40] did an initial study on the
topic, although the results were inconclusive and not
easy to reproduce.
2) Developer facing directions
Even if the approach is technically sound, there are open
questions related to developer ergonomics and adoption.
1) Developer experience - the underlying assumption is
that it helps when familiar concepts, such as compo-
9For example, https://www.builder.io/ could be compared against https:
//www.builder.io/?render=next as the site has been implemented using both
Qwik and Next.js.
nents, are leveraged. Still, it is unavoidable that adop-
tion resumability implies learning and perhaps chang-
ing development practices.
2) Adoption in established projects - it is unclear how
easy it is to adopt resumability in ongoing projects. The
assumption is that runtimes can help, but not all benefits
may be gained. That is where external tooling, such as
[38], can come into play to defer loading as much as
possible with fully resumable frameworks.
3) Adoption for new projects - as shown by Qwik, the
framework took care to build on existing technology,
such as JSX. The question is, how easy is it to start
a project with a resumable project, and is there a cost
relative to established frameworks?
4) Adoption by new frameworks - assuming resumability
is a worthwhile idea, more frameworks will likely adopt
it. The question is, what are the obstacles related to
implementing the idea? Furthermore, is it possible that
established frameworks could implement resumability?
5) Scalability - given projects tend to grow over time, one
of the main factors to consider is the scalability of the
approach in terms of development and payloads deliv-
ered to the client. By definition, resumability should
scale well as work can be deferred on an architectural
level, but this should be validated.
6) Code complexity - as resumability brings new con-
straints to how code should be developed, it may affect
code complexity. The complexity of resumable code
may be worth considering.
3) User facing directions
From the user’s point of view, the main question is how
resumability affects user experience and whether there are
notable drawbacks to the approach and its implementations.
In other words, is there a cost for user experience? The
underlying assumption is that resumability should provide
a better user experience, as shown by [37], but the results
should be validated through user testing.
REFERENCES
[1] Marko Team, ‘‘Talking Points for Marko - HackMD,’’ https://hackmd.io/
@markojs/BkW3fIze2, 2023, [Accessed 04-10-2023].
[2] T. Berners-Lee, R. Cailliau, J.-F. Groff, and B. Pollermann, ‘‘World-wide
web: the information universe,’’ Internet Research, 1992.
[3] ‘‘Internet and social media users in the world 2023,’’ https://www.statis
ta.com/statistics/617136/digital-population-worldwide/, [Accessed
28-08-2023].
[4] ‘‘Page Weight | 2022,’’ https://almanac.httparchive.org/en/2022/page- wei
ght, [Accessed 28-08-2023].
[5] J. Howarth, ‘‘Internet Traffic from Mobile Devices (Sept 2023),’’ https:
//expl odi ngt opics.com/b log /mo bile- int ernet- tr aff ic, 2023, [Accessed
30-08-2023].
[6] T. Kadlec, ‘‘JS Parse and Execution Time,’’ https://timkadlec.com/2014/0
9/js-parse- and-execution- time/, 2014, [Accessed 13-09-2023].
[7] M. Kaluža, K. Troskot, and B. Vukelić, ‘‘Comparison of front-end frame-
works for web applications development,’’ Zbornik Veleučilišta u Rijeci,
vol. 6, no. 1, pp. 261–282, 2018.
[8] J. Vepsäläinen, A. Hellas, and P. Vuorimaa, ‘‘The rise of disappearing
frameworks in web development,’’ in International Conference on Web
Engineering. Springer, 2023, pp. 319–326.
8VOLUME 11, 2023
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS
[9] L. Vogel and T. Springer, ‘‘An in-depth analysis of web page structure and
efficiency with focus on optimization potential for initial page load,’’ in
International Conference on Web Engineering. Springer, 2022, pp. 101–
116.
[10] X.-A. Cao, ‘‘Headless cms and qwik framework and their practicalities
in the future of application development,’’ 2023. [Online]. Available:
https://urn.fi/URN:NBN:fi:amk-202305057993
[11] L. Hallie and A. Osmani, ‘‘Islands Architecture,’’ https://www.patterns.d
ev/posts/islands-architecture/, 2022, [Accessed 29-Sep-2022].
[12] J. Vepsäläinen, ‘‘Ecmascript–the journey of a programming language from
an idea to a standard,’’ in Joint proceedings EURAS & SIIT 2023: (re-
sponsible) standardisation for smart systems. EURAS Contributions to
Standardisation Research, Jul. 2023, pp. 203–220.
[13] A. Wirfs-Brock and B. Eich, ‘‘JavaScript: the first 20 years,’’ Proceedings
of the ACM on Programming Languages, vol. 4, no. HOPL, pp. 1–189,
2020.
[14] L. Wood, A. Le Hors, V. Apparao, S. Byrne, M. Champion, S. Isaacs,
I. Jacobs, G. Nicol, J. Robie, R. Sutor et al., ‘‘Document object model
(dom) level 1 specification,’’ W3C recommendation, vol. 1, 1998.
[15] V. Solovei, O. Olshevska, and Y. Bortsova, ‘‘The difference between de-
veloping single page application and traditional web application based on
mechatronics robot laboratory onaft application,’’ Automation of techno-
logical and business processes, vol. 10, no. 1, 2018.
[16] J. J. Garrett et al., ‘‘Ajax: A new approach to web applications,’’ 2005.
[17] w3techs, ‘‘Usage Statistics and Market Share of jQuery for Websites, May
2023,’’ https://w3techs.com/technologies/details/js-jquery, 2023,
[Accessed 08-May-2023].
[18] B. Bibeault, A. De Rosa, and Y. Katz, jQuery in Action. Simon and
Schuster, 2015.
[19] T. F. Iskandar, M. Lubis, T. F. Kusumasari, and A. R. Lubis, ‘‘Comparison
between client-side and server-side rendering in the web development,’’
in IOP Conference Series: Materials Science and Engineering, vol. 801.
IOP Publishing, 2020, p. 012136.
[20] A. Huotala, ‘‘Benefits and challenges of isomorphism in single-page ap-
plications: A case study and review of gray literature,’’ Master’s thesis,
University of Helsinki, 2021.
[21] B. Livshits and E. Kiciman, ‘‘Doloto: Code splitting for network-bound
web 2.0 applications,’’ in Proceedings of the 16th ACM SIGSOFT interna-
tional symposium on foundations of software engineering, 2008, pp. 350–
360.
[22] J. Vepsäläinen, A. Hellas, and P. Vuorimaa, ‘‘Implications of edge com-
puting for static site generation,’’ in WEBIST 2023: 19th International
Conference on Web Information Systems and Technologies. Springer,
2023, pp. 223–231.
[23] T. N. Nguyen, ‘‘Family in music platform,’’ 2022.
[24] Vercel, ‘‘Rendering: Server Components,’’ https://nextjs.org/docs/app/bu
ilding- your-application/rendering/server-components, 20233, [Accessed
04-10-2023].
[25] ‘‘Resumable vs. hydration,’’ https://qwik.builder.io/docs/concepts/resuma
ble/, 2023, [Accessed 29-08-2023].
[26] M. Hevery, ‘‘Resumability vs Hydration,’’ https://www.builder.io/blog/re
sumability-vs- hydration, 2022, [Accessed 29-08-2023].
[27] S. Champeon, ‘‘Progressive enhancement and the future of web design,’’
http://www.webmonkey.com/03/21/index3a.html, 2003, [Accessed over
The Wayback Machine, 15-May-2023].
[28] A. Gustafson, L. Overkamp, P. Brosset, S. V. Prater, M. Wills, and
E. PenzeyMoog, ‘‘Understanding progressive enhancement,’’ Oct 2008,
[Accessed 29-Sep-2022]. [Online]. Available: https://alistapart.com/artic
le/understandingprogressiveenhancement/
[29] J. Vepsäläinen, A. Hellas, and P. Vuorimaa, ‘‘The state of disappearing
frameworks in 2023,’’ in WEBIST 2023: 19th International Conference on
Web Information Systems and Technologies. Springer, 2023, pp. 232–241.
[30] ‘‘Prefetching,’’ https://qwik.builder.io/docs/advanced/prefetching/, 2023,
[Accessed 29-08-2023].
[31] M. Ubl, ‘‘11 years at Google,’’ https://www.industrialempathy.com/posts/
11-years- at-google/, 2022, [Accessed 04-10-2023].
[32] Marko.js, ‘‘Marko,’’ https://markojs.com/, 2023, [Accessed 04-10-2023].
[33] Wappalyzer, ‘‘Websites using Marko,’’ https://www.wappalyzer.com/tec
hnologies/web-frameworks/marko/, 2023, [Accessed 04-10-2023].
[34] ——, ‘‘Websites using Qwik,’’ https://www.wappalyzer.com/technologie
s/web-frameworks/qwik/, 2023, [Accessed 04-10-2023].
[35] T. Lonka, ‘‘Improving the Initial Rendering Performance of React
Applications Through Contemporary Rendering Approaches,’’ Master’s
thesis, Aalto University. School of Science, 2023. [Online]. Available:
http://urn.fi/URN:NBN:fi:aalto-202308275116
[36] BuilderIO, ‘‘GitHub - BuilderIO/framework-benchmarks,’’ https://github
.com/BuilderIO/framework-benchmarks, 2022, [Accessed 03-10-2023].
[37] ‘‘Core Web Vitals Technology Report,’’ https://lookerstudio.google.com/
u/0/reporting/55bc8fad-44c2-4280-aa0b-5f3f0cd3d2be/page/M6ZPC?s
=iL-EeFbtDHg¶ms=%7B%22df44%22:%22include%25EE%2580
%25800%25EE%2580%2580IN%25EE%2580%2580Next.js%25EE%2
580%2580Angular%25EE%2580%2580Nuxt.js%25EE%2580%2580Sv
elteKit%25EE%2580%2580Astro%25EE%2580%2580Remix%25EE%2
580%2580Qwik%22%7D, [Accessed 20-11-2023].
[38] L. Vogel and T. Springer, ‘‘Waiter and autratac: Don’t throw it away, just
delay!’’ in Web Engineering, I. Garrigós, J. M. Murillo Rodríguez, and
M. Wimmer, Eds. Cham: Springer Nature Switzerland, 2023, pp. 278–
292.
[39] I. Kainu, ‘‘Optimization in react.js: Methods, tools, and techniques to
improve performance of modern web applications,’’ B.S. thesis, Tampere
University, 2022. [Online]. Available: https://trepo.tuni.fi/handle/10024/1
40258
[40] A. Lipiński and B. Pańczyk, ‘‘Performance optimization of web applica-
tions using qwik,’’ Journal of Computer Sciences Institute, vol. 28, pp. 197–
203, 2023.
JUHO VEPSÄLÄINEN received his M.S. degree
in information technology from the University
of Jyväskylä, Finland, in 2011. Since then, he
founded SurviveJS Oy, a technical self-publishing
company.He is also the director of the Future Fron-
tend conference established in Helsinki, Finland.
He has contributed to open-source projects, such
as Blender and webpack, as a core team member.
Currently, he is pursuing a doctorate in computer
science at Aalto University, Finland.
MIŁKO HEVERY As CTO, Miško oversees the
technology division powering Builder.io applica-
tions. Before joining Builder.io, he created Open
Source platforms for Google, including Angular,
and AngularJS, and was the co-creator of Karma.
At Google, he focused on improving the testing
culture and transitioned to improving the web.
Miško started his career designing digital circuits
and moved to databases, full-stack development,
and finally, front-end frameworks, giving him a
unique perspective. In addition to Google, he has worked for Adobe Systems
and Sun Microsystems. Miško holds an M.S./B.S. from Rochester Institute
of Technology and an MBA from Santa Clara University.
PETRI VUORIMAA Professor Petri Vuorimaa
holds the position of Vice Head of Education
within the Department of Computer Science at
Aalto University, Finland. He also serves as the
Director of the Master’s Programme in Computer,
Communication, and Information Sciences. His
own research and teaching area is Web applica-
tions, technologies, and science. In addition to
his academic roles, Professor Vuorimaa actively
contributes to the industry as a Supervisory Board
Member of EIT Digital and as a Board Member of Sofia Digital.
VOLUME 11, 2023 9
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3352891
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
