Content uploaded by Juho Paakkanen
Author content
All content in this area was uploaded by Juho Paakkanen on Dec 27, 2023
Content may be subject to copyright.
Bachelor’s Programme in Science and Technology
Upcoming JavaScript web frameworks and their
techniques
Bachelor’s Thesis
December 22, 2023
Juho Paakkanen
Aalto University ABSTRACT OF
School of Science BACHELOR’S THESIS
Bachelor’s Programme in Science and Technology
Author: Juho Paakkanen
Title of thesis: Upcoming JavaScript web frameworks and their techniques
Date: December 22, 2023
Pages: 33
Major: Computer Science
Code: SCI3027
Supervisor: Prof. Lauri Savioja, D.Sc
Instructor: M.Sc. Juho Veps¨
al¨
ainen
The interactivity and size of web applications have continuously increased, resulting in
the fact that user interface frameworks alone often no longer meet the requirements of
modern applications. To solve this, one of the latest trends in web software development
has been using server-side rendering to improve the user experience. However, this has
made the developer experience more complex, as a separate meta-framework must be
included to achieve desired server-side functionalities.
This thesis explores current mainstream and upcoming JavaScript web frameworks and
their techniques by studying front-end frameworks and meta-frameworks. The research
question the thesis aims to answer is: ”What benefits does the latest generation of
JavaScript web frameworks offer over mainstream ones?” The goal is to find the best
techniques for future web software development by analyzing research and observing
practical trends. This is carried out through a literature review and by presenting the
implementations of the selected frameworks. The frameworks selected for examination
are React, Next, Svelte, Qwik, Astro, and HTMX.
Many benefits of using upcoming frameworks and novel techniques were found. Newer
solutions offer smaller runtime sizes, more efficient rendering approaches, and often a
better developer experience. These are achieved by techniques such as more extensive
compiler use and adopting finely-grained reactivity with signals. Most of this progress
is incremental, and the benefits are mostly relevant for specific use cases. However,
Qwik uses a technique called resumability, which might fundamentally change the
currently prevalent server-side rendering by eliminating the need for hydration. Lastly,
it is important to recognize that artificial intelligence will most likely have a significant
impact on the future of web development.
Keywords: Front-end frameworks, JavaScript, React, Next, Svelte, Qwik,
Astro, HTMX, Rendering
Language: English
Aalto-yliopisto KANDIDAATINTY ¨
ON
Perustieteiden korkeakoulu TIIVISTELM ¨
A
Teknistieteellinen kandidaattiohjelma
Tekij¨
a: Juho Paakkanen
Ty¨
on nimi: Upcoming JavaScript web frameworks and their techniques
P¨
aiv¨
ays: 22. joulukuuta 2023
Sivum¨
a¨
ar¨
a: 33
P¨
a¨
aaine: Tietotekniikka
Koodi: SCI3027
Vastuuopettaja: Prof. Lauri Savioja, TkT
Ty¨
on ohjaaja(t): FM Juho Veps¨
al¨
ainen
Verkkosovellusten interaktiivisuus ja koko ovat kasvaneet jatkuvasti, mink¨
a takia alun
perin yksinomaan selaimessa toimiviksi tarkoitetut k¨
aytt¨
oliittym¨
akehykset eiv¨
at en¨
a¨
a
vastaa nykyajan vaatimuksia. T¨
am¨
an ongelman ratkaisemiseksi yksi verkkosovelluske-
hityksen viimeaikaisista trendeist¨
a on ollut k¨
aytt¨
a¨
a yh¨
a enemm¨
an palvelinpuolen ren-
der¨
ointi¨
a paremman k¨
aytt¨
aj¨
akokemuksen saavuttamiseksi. T¨
am¨
a on kuitenkin johtanut
kehitt¨
aj¨
akokemuksen monimutkaistumiseen, koska palvelinpuolen render¨
ointi¨
a varten
t¨
aytyy k¨
ayt¨
ann¨
oss¨
a ottaa k¨
aytt¨
o¨
on erillinen metakehys, jonka avulla saadaan k¨
aytt¨
o¨
on
erilaisia palvelinpuolen toiminnallisuuksia.
T¨
ass¨
a kandidaatinty¨
oss¨
a tutkitaan modernien verkkosovellusten kehityst¨
a keskittyen
ensisijaisesti nykyisiin sek¨
a tulevaisuuden JavaScriptin k¨
aytt¨
oliittym¨
akehyksiin, meta-
kehyksiin ja n¨
aiden k¨
aytt¨
amiin tekniikoihin. Tutkimuskysymys on: ”Mit¨
a etuja tulevai-
suuden JavaScript-verkkokehykset tarjoavat verrattuna nykyisiin valtavirran kehyk-
siin?”. Ty¨
on tavoite on l¨
oyt¨
a¨
a parhaita toimintamalleja ja tekniikoita tulevaisuuden
verkkosovelluskehitykseen analysoimalla alan tutkimusta ja havainnoimalla k¨
ayt¨
ann¨
on
trendej¨
a. T¨
am¨
a toteutetaan kirjallisuuskatsauksen kautta sek¨
a esittelem¨
all¨
a valittujen
kehysten toteutuksia. Tarkasteluun valittuja kehyksi¨
a ovat React, Next, Svelte, Qwik,
Astro ja HTMX.
Uudemmissa kehyksiss¨
a sek¨
a niiden k¨
aytt¨
amiss¨
a tekniikoissa havaittiin monia etuja.
Uudet kehykset ovat kooltaan pienempi¨
a, sis¨
alt¨
av¨
at kehittyneempi¨
a render¨
ointitapoja
ja tarjoavat usein paremman kehitt¨
aj¨
akokemuksen. N¨
am¨
a edut on saavutettu muun
muassa k¨
aytt¨
am¨
all¨
a k¨
a¨
ant¨
aj¨
a¨
a entist¨
a enemm¨
an sek¨
a ottamalla k¨
aytt¨
o¨
on signaalipe-
rusteinen tilanhallinta. Suurin osa t¨
ast¨
a kehityksest¨
a on kuitenkin ollut vain hieman
parempien ratkaisujen hy¨
odynt¨
amist¨
a. Poikkeuksena t¨
ast¨
a ovat Qwik ja sen k¨
aytt¨
am¨
a
resumability-tekniikka, jotka saattavat olennaisesti muuttaa nyky¨
a¨
an vallitsevaa hy-
draatioon pohjautuvaa render¨
ointi¨
a poistamalla hydraation tarpeen. On my¨
os t¨
arke¨
a¨
a
huomioida, ett¨
a teko¨
aly tulee hyvin todenn¨
ak¨
oisesti mullistamaan verkkosovelluskehi-
tyksen monin tavoin.
Avainsanat: K¨
aytt¨
oliittym¨
akehykset, JavaScript, React, Next, Svelte, Qwik,
Astro, HTMX, Render¨
ointi
Kieli: Englanti
4
Preface
I wish to thank Juho Veps¨
al¨
ainen for their excellent advice and assistance throughout the
writing process.
I also humbly thank Movial Creative Technologies for financial support, as I was allowed
to write much of this thesis during my working hours.
Tikkurila, 5.12.2023
Juho Paakkanen
5
Contents
Abstract 2
Abstract (in Finnish) 3
Preface 4
Contents 5
Abbreviations 7
1 Introduction 8
2 Mainstream frameworks 10
2.1 React ..................................... 10
2.1.1 Component definition ......................... 10
2.1.2 Client-side rendering ......................... 11
2.1.3 State management .......................... 11
2.1.4 Possible issues with React ...................... 12
2.2 Next ...................................... 12
2.2.1 Server-side rendering ......................... 13
2.2.2 React Server Component ....................... 13
2.2.3 Code splitting ............................. 13
2.3 Svelte ..................................... 14
2.3.1 Component definition ......................... 14
2.3.2 Compiler-centric rendering ...................... 15
2.3.3 Minimalistic and declarative state management .......... 15
2.3.4 Other observations .......................... 15
2.4 Summary ................................... 15
3 Upcoming frameworks 17
3.1 Astro ...................................... 17
3.1.1 Component definition ......................... 17
6
3.1.2 Islands architecture .......................... 18
3.2 Qwik ...................................... 19
3.2.1 Component definition ......................... 19
3.2.2 Heavy use of compiler: code splitting ................ 20
3.2.3 Rendering with resumability ..................... 20
3.2.4 State management with signals ................... 21
3.2.5 Other observations .......................... 21
3.3 HTMX ..................................... 21
3.3.1 Hypermedia-driven approach ..................... 22
3.3.2 Other observations .......................... 22
3.4 Summary ................................... 22
4 Discussion 24
4.1 User experience and performance ...................... 24
4.2 Developer experience ............................. 25
4.3 Language trends ............................... 25
4.4 Use the platform ............................... 26
4.5 Artificial intelligence and the future ..................... 27
5 Conclusions 28
References 29
7
Abbreviations
AI Artificial Intelligence
AJAX Asynchronous JavaScript and XML
CSR Client-Side Rendering
DOM Document Object Model
DSL Domain-Specific Language
DX Developer eXperience
JSON JavaScript Object Notation
JSX JavaScript XML
MPA Multi-Page Application
RSC React Server Components
SEO Search Engine Optimization
SSG Static Site Generation
SSR Server-Side Rendering
SPA Single-Page Application
UI User Interface
UX User eXperience
8
1 Introduction
Early on, the web consisted of static pages linked through hyperlinks [4]. These multi-page
applications (MPAs) were built using technologies such as PHP and delivered via server-
side rendering (SSR) [44]. The invention of Asynchronous JavaScript and XML (AJAX) in
1999 led to the ability to render content on the client without requiring a browser refresh
[59]. This enabled Client-Side Rendering (CSR), and pioneering technologies such as
jQuery began to emerge. Eventually, more complex frameworks such as Angular, React,
and Vue were built to enable a better, more unified Developer eXperience (DX). The shift
towards CSR and Single-Page Applications (SPAs) was driven by the need for a more
interactive User eXperience (UX). However, these advancements came with performance
drawbacks, mainly slower initial page loads. There is an overarching trade-off between
fast initial page load and fast interactivity. When CSR is used, interactivity is fast but the
initial load is slow, and for SSR vice versa. While there has been considerable innovation
since then, the current standard for interactive web applications remains SPAs built with
React [17]. It is worth noting that only occasionally are these SPAs supplemented by a
meta-framework, most commonly Next, also known as Next.js, that allows utilizing SSR
to mitigate some of the performance issues of traditional SPAs.
Modern web pages vary from simple static blogs to highly interactive applications
such as spreadsheet editors. Holotypes is a concept that demonstrates this variety and
different optimal implementation and delivery techniques that distinct application types
have [34]. Moreover, differences in user device performance capabilities and network
connection quality should be taken into account when building applications. This is
increasingly relevant as mobile phones have become the most common way to access the
web [6]. Lastly, from a business perspective, initial load speed is important for conversions
and for retaining users on the web page [3]. These factors have given rise to a need for a
variety of solutions, depending on the use case, and thus there has been a great deal of
interesting recent innovation in this field. Therefore, this bachelor’s thesis aims to answer
the following research question:
•”What benefits does the latest generation of JavaScript web frameworks offer over
mainstream ones?”
To limit the scope of the research, I decided to select JavaScript front-end frameworks
and meta-frameworks with the following selection criteria: the popularity and novelty of
the techniques they employ. Additionally, I decided to include frameworks at various
stages of adoption with the restriction that they would have the first production version
(1.0) released. React and Next serve as the baseline against which newer frameworks are
compared. For semi-established frameworks, Svelte is presented. Subsequently, Qwik and
Astro are examined. These frameworks are innovative and well-received, but in relatively
9
early stages of adoption. Finally, HTMX is introduced to highlight completely different
types of possible solutions. HTMX and other similar approaches may not offer the full
functionality provided by more complex frameworks, but they can be better choices in
some cases.
The rest of this thesis is structured as follows: Chapters 2and 3present a literature
review that explores the selected frameworks and their techniques, ordered according to
their adoption rates, starting with the most widely adopted and proceeding to more novel
and less established ones. Chapter 4focuses on summarizing the findings of the study
and making more general observations about web development trends. Lastly, Chapter 5
provides conclusions and recommendations for future research.
10
2 Mainstream frameworks
According to the Stack Overflow 2023 Developer Survey [51], React is by far the most
used current JavaScript front-end user interface (UI) framework by all respondents, with
Angular, Vue, and Svelte following behind in that order. The State of JavaScript 2022 [17]
results support this and further explore the topic and popularity trends of frameworks.
Svelte stands out as the most liked among widely used frameworks in the State of
JavaScript survey. Furthermore, React and Vue are also well-regarded, but Angular
is less favored by the developer community. Angular is an opinionated and structured
framework maintained by Google that has traditionally focused on stability. However,
recent efforts have been made to improve DX and ease the learning curve by migrating
to signals and introducing a new template control flow in Angular 17. Angular, React,
and Vue are all from roughly the same era and in a similar stage of evolution. Svelte
is a somewhat newer framework that is known for its innovative techniques, such as the
heavy use of a compiler [11] and a strong focus on improving DX [21].
This chapter presents selected mainstream JavaScript frameworks. Section 2.1
introduces React, and Section 2.2 presents Next, which is the most popular meta-
framework for React. The chapter continues with an analysis of Svelte in Section 2.3.
Lastly, Section 2.4 provides a summary of the chapter.
2.1 React
Jordan Walke created React in the early 2010s for Facebook, now known as Meta, since
the solutions available at that time were inadequate for their needs [24]. The framework
was later open-sourced in 2013 [25] and has since become the most popular framework for
modern front-end web development. React has greatly influenced the web development
space. For example, one of the central ideas of React is that the UI is a function of the
application state, and this has been widely adopted later by other frameworks.
2.1.1 Component definition
React popularized using reusable components as the basic building blocks of web
applications. For templating, React uses JavaScript XML (JSX), which has been later
adopted by many other frameworks. JSX is a syntax extension for JavaScript that enables
writing markup similar to HTML inside a JavaScript file, which is then compiled at build
time to JavaScript [33]. Listing 1shows a component that returns a JSX expression.
11
Listing 1: React incrementing counter
1import R e act , { us e S t a t e } f r o m ’ r e ac t ’
2
3const Counter = ({ i n i t i a l C o u n t } ) = > {
4const [ co un t , s et C ou n t ] = u s eS ta t e ( in i ti a lC o un t )
5
6return (
7<di v >
8< p s ty le = { { c ol o r : ’ re d ’ }} > { c o un t } < / p >
9< b ut t on o nC l i ck = { () = > s et C o un t ( c o u nt + 1 ) } > + </ b u tt on >
10 </ di v >
11 )
12 }
13
14 export d e f a u l t Counter
2.1.2 Client-side rendering
Rendering in the web development context is a process done by browsers. It converts
JavaScript, HTML, and CSS code into visual and interactive representation. React uses
CSR, which has the following high-level steps: 1) the client gets minimal HTML from the
server, 2) the client gets and executes JavaScript from the server, and 3) the client renders
the web page. This technique gives a smooth UX as the application can update its state
without refreshing the browser, but it comes with the drawback that initial loading is
slow.
The Document Object Model (DOM) is an interface used by browsers for rendering,
and it defines the web page as a tree representation. For rendering, React uses virtual
DOM, which is a memory representation of the real DOM. The basic rendering approach
can be detailed as follows: when something changes that triggers a page re-render, React
re-renders relevant parts of the virtual DOM, starting from the component that has
changed and including all of its children recursively. After that, React compares the
resulting virtual DOM with the previous virtual DOM to determine the difference. Once
the differences are identified, React makes those changes to the actual DOM. The initial
page render is simply building the entire virtual DOM and copying it to the actual DOM.
2.1.3 State management
State management for components is done with hooks, the most basic one being useState,
which takes in the initial state and returns a setter and a variable. Another basic state
management hook is useReducer, which is similar to useState but also requires a reducer
function and returns a value and a dispatcher that is used for sending actions to the
12
reducer function. useReducer allows for more complex state management. For passing
data, React uses one-way data binding; the parent component communicates to the child
component via props, and callback function props can be used to communicate data from
child to parent. Listing 1demonstrates the use of the useState hook and the most
typical way in React to pass props via JavaScript object destructuring. For global state
management, there is the React Context API, but it is seldom recommended as proper
use cases are limited and it is very easy to misuse, which results in unnecessary full
application re-renders. In practice, global state management is handled with external
state management libraries, which has led to fragmented space that is not great for DX,
as the developer needs to learn a different state management solution for each project
depending on what solution the project happens to use.
2.1.4 Possible issues with React
React’s rendering philosophy could be described as very safe when there is a state change.
The emphasis is on ensuring that everything is rendered correctly. Therefore, possibly
doing some extra work is not considered a major issue. This approach and use of the
virtual DOM have lately been criticized for poor performance [39,19]. Thus, the need for
optimized performance might be a good reason to use something other than React, or at
the very least, consider utilizing a meta-framework to assist with rendering. There have
been studies finding React’s performance inadequate compared to other options [14,39,
32]. Another performance-related issue is that the minified and gzipped size of React with
ReactDOM is over 40kB [7]. Consequently, there is a separate light-weight framework
called Preact that is 4kB minified and gzipped [7] and aims to be a more optimized version
of React for performance-sensitive or resource-constrained environments.
From a DX perspective, getting started and the initial learning curve can be
considered relatively easy [1]. Additionally, the React development team released an
extensive documentation overhaul in 2023 to improve the learning experience [37].
However, Svelte and some of the other newer frameworks are often regarded as even easier
to learn and use [5]. Furthermore, to achieve modern reactivity and performance with
React, a meta-framework must be utilized, and techniques such as potentially problematic
memoization [16] need to be used. This increases the complexity of the application and
makes DX worse. The React development team is aware of issues with memoization and
is working on a compiler called React Forget, which would make the memoization process
automatic and thus improve DX [45].
2.2 Next
Next is a meta-framework by Vercel. Version 1.0 was released in 2016, and it is the most
common solution for SSR and other server-side features for React. Remix is the main
13
competitor for Next, and they have mostly the same functionalities. Advantages of using
Next or other similar meta-framework include automatic code splitting, lazy loading,
built-in CSS support, image optimization, and SEO optimization [28]. The current version
is Next 14, and it did not introduce new features aside from partial prerendering, which
is a new preview stage feature that allows for more customized initial rendering.
Next couples the front-end and the back-end into the same app when used as a full-
stack framework, making it well-suited for apps with low back-end complexity. Thus,
Next works best as a serverless and stateless back-end. For apps with more complex
back-end logic, it is likely better to go with separate back-ends written in languages that
are more robust or performant than JavaScript, such as Go or Rust. In such cases, Next
would only be used as the back-end for front-end (BFF) [38] layer, if at all.
2.2.1 Server-side rendering
In SSR, initial HTML generation is done on the server-side. The process can be split
into two phases. First, the client first gets HTML from the server that the client can
show as a non-interactive web page faster than when CSR is used. This is followed by
the second phase, called hydration, where the client gets JavaScript from the server and
executes it to make the web page interactive. SSR has benefits, such as faster initial load
and improved search engine optimization (SEO) [27,29,32].
React rendering is traditionally done entirely on the client side. However, current
official documentation [48] recommends utilizing meta-framework such as Next or Remix
for SSR and other extra functionalities. Despite this, the majority of even new React
apps are still traditional SPAs [17].
2.2.2 React Server Component
The previous major update, Next 13, brought significant changes, such as the new
app router and support for React Server Components (RSC). RSC represents an
implementation of the islands architecture, which is discussed more in Section 3.1.2.
This is a major paradigm shift compared to the previous SSR approaches. The basic idea
of RSC is that components are divided into two types: server components, which render
on the server and do not include any client-side JavaScript, and client components, which
function as traditional React components on the client side. This approach allows for a
clear separation of concerns between different kinds of UI elements.
2.2.3 Code splitting
Code splitting is a process where code is split into separate bundles that can be loaded
independently [31]. In practice, actual code splitting is done at build time by bundlers
such as Webpack, Vite, Rollup, and Turbopack. The main benefit of code splitting is
14
achieving a faster initial page load, but it also makes other optimizations feasible [29].
React allows for component-level code splitting by manual lazy loading, which makes
it possible to employ route-level code splitting. Next enhances this process by making
further optimizations attainable and automating the basic route-level code splitting, thus
improving the DX.
2.3 Svelte
Svelte was created by Rich Harris, and version 1.0 was released in 2016, with the main
selling point being performance gains over incumbent solutions [20]. Currently, Svelte
is the most favorably viewed by JavaScript developers among the most commonly used
front-end frameworks [17,5].
2.3.1 Component definition
Svelte uses domain-specific language (DSL), which could be considered an extension of
JavaScript. Using DSL allows for a more concise syntax and a couple of ingenious new
ideas. In Svelte, each .svelte file represents a single Svelte component. Components
are divided into three optional parts: 1) a script that contains logic, 2) markup where
JavaScript can be inserted with curly braces, along with various types of directives,
for example, for event handling and templating control flow, and 3) styling. Listing 2
illustrates this structure.
Listing 2: Svelte incrementing counter
1<script >
2export l e t initialCount
3let coun t = i n i t i a l C o unt
4</ s c ri pt >
5
6<di v >
7<p class=" r ed - t e xt " > C u rr e n t c o un t : { c o un t } < / p >
8< b ut t o n o n : c li c k = { () = > c o u nt + +} > + < / bu t to n >
9</ di v >
10
11 <sty le >
12 . re d - t ex t {
13 c ol o r : r ed ;
14 }
15 </ s ty l e >
15
2.3.2 Compiler-centric rendering
Svelte does not use virtual DOM for rendering. Instead, it uses data binding-based
rendering and directly modifies the DOM when there is a change in a reactive variable,
resulting in more optimal performance than React [39]. The compilation process from
the DSL into JavaScript is the following: the Svelte compiler analyzes which variables
have an effect on the DOM and embeds that information, along with variable dependency
information, directly into compiled JavaScript. In some cases, the developer has to mark
a variable as reactive. For this, JavaScript’s label syntax [35] is leveraged by using the
$:-syntax. This allows for fine-grained reactivity when there is a change in a reactive
variable.
2.3.3 Minimalistic and declarative state management
State management is straightforward in Svelte, assignments are reactive, and additionally,
$:-syntax marks statements as reactive. Global state management is done with stores
that are most commonly created with the writable-function. The store has methods set
and update that can be used to mutate the state and subscribe-method for listening
to changes. This approach is simple but comes with a known drawback, where in some
cases it can be confusing whether some application state changes will be reflected in the
UI or not [52].
2.3.4 Other observations
SvelteKit is a meta-framework for Svelte that was released in 2021. It offers many similar
functionalities for Svelte as Next does for React. Performance for Svelte is generally
considered quite good compared to other solutions. One study found Svelte to have similar
performance to Next [50]. Another study observed that Svelte had better performance
than Angular [54]. Lastly, the size of Svelte when minified and gzipped is less than 3
kB [7]. Svelte is generally considered easy to learn, and its domain-specific language
allows developers to write much more concise code than with most other frameworks [5].
Currently, there are certain aspects the Svelte team finds problematic, and thus the next
major version of Svelte will include big changes to syntax and functionality by adding
runes as a new abstraction of doing reactive state that is built on top of signals internally
[52].
2.4 Summary
Frameworks presented in this chapter have been shaping the field of web development
and are very popular currently. React has significantly influenced web development by
popularizing many ideas, such as component-based architecture, declarative UI, JSX,
16
and unidirectional data flow. However, some design choices have been later criticized.
For example, the rendering strategy with the virtual DOM has demonstrated poor
performance compared to newer frameworks. Next improves the performance of React
applications by offering multiple useful optimizations and SSR capabilities. There are
clear performance benefits to using Next, but some aspects of React, such as manual
memoization techniques, remain problematic. Svelte pioneered the idea of relying heavily
on the compiler instead of the runtime to improve performance and DX. Currently,
Svelte’s main differentiating factor is the heavy use of the compiler combined with DSL,
which allows for compact code. This approach is well-received by developers, as Svelte
is the most desired of the commonly used front-end frameworks. Table 1summarizes
selected factors of frameworks analyzed in this chapter.
Table 1: Mainstream-framework comparison
Name Version Size Templating Notes
React 18.2.0 45 kB JSX -
Next 14.0.3 * JSX Meta-framework for React
Svelte 4.2.7 3 kB Svelte DSL Has meta-framework called SvelteKit
* Includes many optimizations to reduce the size of the React application.
17
3 Upcoming frameworks
There are three fundamental principles in current mainstream frameworks: 1) a focus
on reusable components, 2) templating with a DSL, most often JSX, and 3) hydration
[56]. Presently, there are many interesting upcoming frameworks, and some of them are
challenging these established principles. These include various JavaScript frameworks
and meta-frameworks such as Qwik, Fresh, Solid, and Astro. Additionally, less traditional
solutions have emerged, such as HTMX. For newer JavaScript frameworks, there has been
a recent focus on utilizing a compiler extensively for various optimizations and minimizing
JavaScript delivered to the client.
Disappearing frameworks, a concept that was first introduced in 2018, is part of this
trend [40]. The term disappearing frameworks comes from the idea that the framework is
made as small as possible when it is shipped to the client application [56]. Transitional web
applications is a similar term [10]. Furthermore, the hydration process and its associated
costs are often critically evaluated in disappearing frameworks [55]. The previously
analyzed Svelte ticks many boxes for a disappearing framework, as it uses a compiler
instead of runtime for most of the work and aims to ship less JavaScript to the client
compared to more incumbent solutions such as React or Angular [57].
This chapter presents a selection of upcoming frameworks and reviews the techniques
they utilize. The chapter first focuses on solutions that aim to be relatively similar to
current frameworks but better. Section 3.1 presents Astro, which is a versatile meta-
framework. Following this, Section 3.2 introduces Qwik and the innovative techniques
it uses. Next, Section 3.3 showcases HTMX, which is a radically different approach
designed for less interactive use cases. Lastly, Section 3.4 provides a summary of the
topics discussed in this chapter.
3.1 Astro
Astro is a meta-framework that was created by Fred K. Schott in 2021. It started with
a focus on static site generation but has evolved into a multi-purpose framework that
supports various SSR techniques. Additionally, it is framework-agnostic, meaning it
allows for the use of any popular JavaScript front-end framework or even mixing multiple
front-end frameworks in the same project, as seen in Listing 3. Astro is often praised as a
good solution, especially for more static content, as it has excellent support for displaying
markdown and other static formats [50].
3.1.1 Component definition
Astro uses special .astro files, and components are split into two parts. The first part
is frontmatter, which is enclosed between two code fences, marked by ---, where local
18
variables can be declared or components imported. The second part is templating, which
is a superset of HTML that can be used somewhat similarly to JSX. Listing 3highlights
this structure.
Listing 3: Astro component showing 3 different counters
1---
2import ReactCounter fr o m ’ . ./ c o mp on e nt s / R ea c tC o un te r . js x ’
3import SvelteCounter f r o m ’ . ./ c o mp o ne n ts / C o un te r . s ve l te ’
4import QwikCounter f r o m ’ . ./ c o mp on e nt s / Q wi k Co u nt er . t sx ’
5const title = ’ M ul t i pl e c o un t e r i s la n d s ’
6---
7
8<di v >
9< h2 > { t i tl e } < / h2 >
10 < R ea c t Co u n te r c l ie n t : lo a d / >
11 < S ve l t eC o u nt e r c li e nt : i d le / >
12 < Q wi k C ou n te r / >
13 </ di v >
3.1.2 Islands architecture
Astro popularized the islands architecture, which involves splitting code into static
components that are rendered on the server and interactive components that require
client-side hydration. By default, all Astro components are static, but hydration can be
added with client directives, which employ progressive hydration by controlling hydration
priority and can also be used to set the component to only render on the client. Listing 3
illustrates how various frameworks can be used to make separate interactive counter
islands. React and Svelte islands are specified to be interactive and have hydration
priorities based on directives client:load and client:idle. Notice that the Qwik
does not need any directives as it does not use hydration. Figure 1demonstrates how
different kinds of islands can look in application and how progressive hydration differs
from standard SSR.
19
Figure 1: Differences between modern SSR, progressive hydration, and islands
architecture. In SSR, everything is hydrated simultaneously, and the page only
becomes interactive after the whole process. Progressive hydration hydrates components
sequentially, so the most important components can become interactive sooner. In islands
architecture, static components are rendered only on the server, and only interactive
islands are hydrated on the client. [43]
3.2 Qwik
Qwik was created by the Builder.io team, which includes developers Miˇsko Hevery, Adam
Bradley, and Manu Almeida. It is a relatively new framework; version 1.0 was released in
May 2023 [47]. The framework was inspired by Wiz, an internal Google framework that
powers many of Google’s front-end apps, borrowing ideas, such as resumability, from it
while making the framework more DX-friendly [8].
3.2.1 Component definition
Qwik components are relatively similar to React components as they both use JSX and
multiple components can be defined in a single file. However, Qwik uses TypeScript out
of the box instead of JavaScript. Listing 4illustrates the use of TypeScript and JSX.
20
Listing 4: Qwik incrementing counter
1import { c o m p o n ent$ , u s e S i g n a l } f r om ’ @ b ui l d er . i o / q wi k ’
2
3interface CounterProps { // Type definit i o n f or props
4i ni t ia l Co un t : n u mb er
5}
6
7export d e f a u l t c o mp on e nt $ < C o un t er P ro ps >( ( { i n it i al C ou n t }) = > {
8const c ou nt = u se S ig na l ( i ni t ia l Co u nt )
9
10 return (
11 <di v >
12 < p s ty le = { { c ol o r : ’ re d ’ }} > { c ou nt . v a lu e } </ p >
13 < b ut t on o nC l i ck $ = { () = > c o un t . v a lu e + + } >+ < / b ut t on >
14 </ di v >
15 )
16 })
3.2.2 Heavy use of compiler: code splitting
The code splitting is done by a compiler called the Optimizer. It automatically reorganizes
components into three parts: 1) view, 2) state, and 3) event handlers. Additionally, it
allows for granular code splitting using the $-sign to indicate function scope or closure.
This code splitting with $-sign is also visible in component definition and event handlers,
as seen in Listing 4. This very granular code splitting is central to Qwik, as it is one of
the main factors that enable its special rendering approach called resumability.
3.2.3 Rendering with resumability
Resumability is a key idea of Qwik that essentially means serializing the framework and
application state and embedding this information into the HTML that is sent to the client
[22]. As a result, resumability totally skips the need for the hydration step, and it can
be considered conceptually as streaming JavaScript to the browser. The framework aims
to offload as much work from the main thread as possible by aggressively prefetching
the data for the current page. This is achieved by using service workers to load small
chunks into the browser cache that the user might need next. It also employs a very
lazy loading strategy and a runtime called Qwikloader that instructs how the rest of the
application should be loaded. For rendering performance, Qwik’s main focus is on Time
to Interactive (TTI).
21
3.2.4 State management with signals
Signals are reactive primitive for managing state and achieving fine-grained reactivity,
and they can be considered an implementation of the observer pattern [9]. The general
idea is old, as similar constructs were present in Knockout and Vue a decade ago, but
Solid popularized them by making improvements to UX that led to current widespread
adoption by frameworks such as Preact, Qwik, and Angular [11]. For signals, the idea
is that there is a reactive primitive that returns getter and setter, and the framework
does dependency tracking for signals to update them correctly. It is also possible, either
directly or indirectly, to subscribe to listening for changes in a specific signal.
Qwik utilizes a variation of signals but additionally virtual DOM when change is
structural, so reactivity is not as fine-grained when structural changes happen as in Solid.
The reactive basic function that acts as primitive is useSignal, which returns an object
with a single property .value, which can then be accessed or updated, as can be seen in
Listing 4.
3.2.5 Other observations
Qwik City is a meta-framework for Qwik that offers typical server-side functionalities
similar to what Next does for React and SvelteKit for Svelte. Additionally, it comes pre-
integrated with Partytown, which is a library that allows offloading third-party scripts
to web workers. Qwik promises great performance, and performance tests by the Qwik
Team support this, especially for TTI and First Contentful Paint (FCP) [46]. However,
early performance tests in production that compared Qwik to vanilla React and Next
did find that the performance benefits of Qwik were inconclusive [30]. The size on Qwik
runtime is less than 1 kB when minified and gzipped [7].
3.3 HTMX
HTMX is a JavaScript library that acts as an HTML extension, created by Carson Gross
in 2020. It is a completely different, minimalist approach compared to currently prevalent
component-driven frameworks, as it does not deal with components or client-side state.
HTMX enables making AJAX calls directly from HTML, thus storing much more HTML
on the server than prevalent frameworks. The HTML response can then be inserted
anywhere in the DOM, possibly replacing some other element, as seen in Listing 5.
22
Listing 5: HTMX example: Button that is replaced to server HTML response
when user clicks. [23]
1<s cr i pt s r c =" ht t ps : / / un p kg . c om / h t mx . o r g@ 1 . 9. 6 " > </ s cr ip t >
2<button h x - p os t = "/ c l ic k ed " h x - sw a p =" outerHTML">
3Clic k M e
4< / bu tt on >
3.3.1 Hypermedia-driven approach
Hypermedia interactions are central to HTMX. JavaScript Object Notation (JSON) is
the conventional format for exchanging web API responses between the back-end and
front-end. HTMX challenges this by using HTML as the API payload. JSON-based
schema typically decouples interactions on the application level; on the other hand,
HTMX couples interactions on the application level but decouples interactions on the
network level [18]. Another factor is that HTMX moves most of the complexity to the
server, which aligns well with the current general shift to utilizing the server as much as
possible for the rendering.
3.3.2 Other observations
Potential benefits of HTMX could include a simple developer experience and better
performance, especially on lower-end devices, as it moves complexity towards servers.
However, HTMX might not be suited at all for building highly interactive applications
or complex front-ends. It is a suitable option for those back-end developers who do
not prefer to write JavaScript or TypeScript, as it is back-end agnostic and allows for
developing front-ends without writing JavaScript. For HTMX and similar approaches,
wide-spread adoption might be hard, as using them requires a completely different mental
model than more traditional frameworks. On a higher level, HTMX acts as a thought-
provoking example that, in many ways, challenges looking at web front-end development
from a totally different point of view. HTMX can be supplemented by sprinkling in
some JavaScript with a lightweight framework such as Alpine, which can be described
as modern jQuery. HWY is a meta-framework in beta, designed to be used with HTMX
that takes concepts from Remix and ports them to the HTMX context [13]. The size on
HTMX is 15 kB when minified and gzipped [7].
3.4 Summary
This chapter covered three very different innovative solutions. Astro notably embraced
islands architecture, which has probably been inspiration for solutions such as RSC.
23
Another key aspect that separates Astro from most other meta-frameworks is that
it supports multiple front-end frameworks rather than just one, as is typical. Qwik
introduced resumability, which is a very transformative new idea as it removes the
hydration step that is currently used when SSR is utilized. Resumability is achieved
mainly by the clever use of compiler, code splitting, and service workers. HTMX is
a quite unique approach that challenges many current conventions. It is hypermedia-
driven and transfers more of the dynamic behaviors to the server, reducing the need for
JavaScript on the client. Table 2summarizes some basic factors of these frameworks.
Table 2: Upcoming frameworks compared
Name Version Templating Size Notes
Astro 3.6.0 Astro DSL* - Framework-agnostic meta-framework
Qwik 1.2.19 JSX 1 kB Has meta-framework Qwik City
HTMX 1.9.9 HTML+ 15 kB Hypermedia-driven approach
* Relatively similar to JSX
+ Extends standard HTML with extra features
24
4 Discussion
In this chapter, the findings of the thesis are summarized, and some interesting aspects
and observations about current JavaScript web development are explored. The research
question that this thesis explored is: ”What benefits does the latest generation of
JavaScript web frameworks offer over mainstream ones?”. Multiple benefits were found,
and they can be categorized into two main improvement types: 1) UX and performance
and 2) DX. Other aspects that are explored in this chapter include recent language
trends, whether the current comprehensive JavaScript frameworks are needed at all, and
the impact of artificial intelligence.
4.1 User experience and performance
Recent, so-called disappearing frameworks have quite small bundle sizes for runtimes,
typically 1-3 kB, and there are known benefits for minimizing application size [29].
However, when analyzing the effect this has, there is a need to keep in mind that
framework size is typically a tiny portion of application size. Another similar issue is
that even if the whole application itself is fast, third-party libraries can have a significant
performance impact, often by blocking the main execution thread. Techniques such as
efficiently tree shaking and off-loading external third-party libraries to service workers
with solutions such as Partytown aim to solve this problem further.
Lately, SSR and novel techniques related to it have been the main source of
innovation. There have been many solutions that aim to fine-tune where rendering of
components happens, such as Astro’s islands implementation or React’s RSC. Controlling
the order and efficiency of rendering with the use of different lazy loading and caching
techniques is an area that has been continually improved. Additionally, there has been
a movement away from virtual DOM-based solutions as they are considered inefficient.
Currently, Vue is working on a mode called Vapor, which would allow the use of the
framework without the virtual DOM [26]. Most newer frameworks utilize compilers
extensively to reduce the amount of work needed at runtime. Additionally, React is
planning a compiler called React Forget to achieve similar benefits.
Edge computing is the idea that computing is brought from data centers closer to
the user, thus achieving faster response times and saving bandwidth. In the context of
web frameworks, edge rendering means using edge servers to serve and render content to
clients and thus reduce latency. New frameworks, such as Qwik and Astro, highlight edge
readiness and functionalities in their advertising, but Next also has good built-in support
for it, especially if deployed on Vercel.
Qwik is based on an especially transformative idea: resumability, which aims to
completely eliminate the traditional hydration step with SSR. Another key aspect of
Qwik is that its fine-grained function-level code splitting allows for very effective HTML
25
streaming that is conceptually similar to media streaming with technologies such as HTTP
Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH).
4.2 Developer experience
Many of the latest techniques aim to improve the DX, for example, by using a compiler to
automate processes that have traditionally been done manually. Other DX improvements
include offering convenient APIs such as signals for state management. Signal-based state
management has become the norm for the front-end frameworks, with only React having
a fundamentally different solution. JSX has become the default solution for templating,
but Svelte’s approach to extending JavaScript with their own DSL has been well-received
by developers as it often allows for more concise syntax. Another DX-related aspect is
documentation, and there has been a strong focus on it lately. This has led both React
and Angular to improve and overhaul their documentation in 2023 to be more in line
with current expectations.
DX has become more complex, as a developer must understand both the front-end
framework and a meta-framework that supports it. Typically, each front-end framework
has one or a couple of meta-frameworks that support it, and most meta-frameworks are
intended for just one front-end framework. Presently, there is a clear trend in framework
design: the front-end framework and tailored meta-framework for it are designed by
the same people. However, Astro supports many frameworks and has excellent support
for static content. This is convenient, as learning a new front-end framework does not
necessarily require learning a new meta-framework. Furthermore, Astro allows using a
micro-frontend architecture approach, where different frameworks can be used for different
parts of the application.
4.3 Language trends
The biggest somewhat recent language trend in this space has been the widespread
adoption of TypeScript for web development. This can also be seen in the context of
frameworks, as Qwik, the newest of the analyzed frameworks, uses TypeScript as the
default instead of JavaScript. However, there has been some recent critique of TypeScript,
especially among library authors. The Svelte project moved to use JSDoc internally for
types to eliminate the build step [2]. JSDoc is a markup language that offers type safety,
but it comes with the drawback of more verbose syntax than TypeScript. Furthermore,
the latest ECMA proposal includes exploring optional types for JavaScript [53] that could
eventually make TypeScript redundant.
This thesis focuses on JavaScript frameworks, but there are some notable other
languages and techniques that can be used for web development. HTML and CSS
are markup and style sheet languages, respectively, that are utilized together with
26
JavaScript for building web applications. Approaches such as leveraging WebAssembly
or some multi-platform framework offer developers totally different routes for building
applications.
HTML and CSS are getting frequent updates and improving. For example, CSS has
gotten support for nesting and the View Transition API, and HTML has new Dialog
and Popover elements. These updates reduce the need for JavaScript for web pages as
they expand the functionality of HTML and CSS. Thus, certain approaches, such as CSS
preprocessors, are becoming redundant. For performance, this is good as browsers are
very good at processing HTML, and it greatly reduces the complexity needed for these
functionalities and thus improves the DX.
WebAssembly, often abbreviated as WASM, is a low-level language supported by
all major browsers that is similar to assembly languages but intended for browsers.
Additionally, it is seldom written directly but used as a compiler target for higher-level
languages such as C, C++, or Rust. It can provide native-like performance for web
applications and enable porting apps from native to the browser. The most famous early
adapter was Figma [58], but other programs such as Photoshop [41] have been ported to
the browser as well. In both cases, the original app was written in C++. WASM is often
used together with some JavaScript framework that works as an outer, simpler UI layer.
Multi-platform approaches such as Flutter and React Native are also viable
candidates for some use cases. Flutter makes it possible to use a single codebase for all
platforms. It uses Dart as a programming language, which is then compiled during the
build time to a platform-specific target, which is JavaScript for web applications. React
Native makes it straight-forward to write both iOS and Android mobile applications using
React and JavaScript, thus offering familiar DX for web developers. Moreover, there is
a recent trend to write and rewrite JavaScript tooling in more performant languages,
especially Rust. In the end, it is hard to predict the future, but JavaScript has long
remained at the center of web development, and as the creator of JavaScript, Brendan
Eich, famously said, ”Always bet on JavaScript”.
4.4 Use the platform
The JavaScript web development space is very fragmented, and there is constant change
in tooling and frameworks. There is even the term ”JavaScript Fatigue” that relates
to frustration with this. One intriguing angle is asking the question, ”Are the current
somewhat extensive frameworks and many other tools needed at all?” Additionally,
there might be somewhat overreliance on external 3rd party libraries for even simple
functionality, as demonstrated by the famous left-pad incident [12]. For example, it is
possible to make many less complex applications with just vanilla JavaScript and standard
web APIs. Personally, I have experience using vanilla JavaScript to make a relatively
27
simple but animation-heavy web application front-end that serves media content and is
packaged for various TV platforms and mobile devices.
Web Components enable the development of even more complex applications without
using the traditional JavaScript framework. Web Components are the following set of
techniques: utilizing custom elements, shadow DOM, and HTML templates. These
techniques are used to extend standard HTML through the creation of new, reusable
components [36]. Drawbacks of this approach include that using novel server-side
rendering techniques is not straightforward, and DX is different compared to current
mainstream methods. Nevertheless, it is important to recognize that there might currently
be an over-reliance on tooling and high-level abstractions in web development.
4.5 Artificial intelligence and the future
In the future, generative Artificial Intelligence (AI) tools that produce different kinds of
components will likely become popular. The idea is that components can be created with
prompts or even auto-completed instead of coding them traditionally. There have been
various low-code solutions before, yet prompting gives a convenient, unified, and flexible
user interface that is similar to searching. In addition, more powerful models will enable
the creation of more custom content than before. Current general state-of-the-art Large
Language Models (LLMs) are already excellent for certain subsets of development tasks,
but their use cases are yet somewhat limited.
GitHub’s Copilot has been a pioneering solution in this space that can be integrated
into a code editor and used as an intelligent auto-complete or more comprehensive code
generator. GitHub was recently re-focused from Git to Copilot [15] as another sign
of the future importance of AI tooling. Furthermore, for design, there are tools such
as prompt2design-plugin for Figma that make it possible to turn prompts into layouts.
Visual Copilot by Builder.io is a recently released tool that can be used to produce
components from multiple frameworks using Figma layouts as input [49]. Vercel’s v0 is
another generative AI tool that produces React components with shadcn/ui and Tailwind
CSS [42].
At the moment, most of these solutions are still in quite early stages, but I could
see these kinds of approaches becoming big eventually once these tools get more capable
and a company such as Vercel or GitHub could eventually integrate them with the whole
deployment platform, thus making shipping sophisticated custom software much easier
than currently. Going forward, code will be increasingly AI-created, so framework design
should take this into account, and frameworks should be easy and effective for AI to
use. This development will likely lead to humans coding increasingly declaratively and
eventually in plain text prompts at some later stage.
28
5 Conclusions
This thesis explored some mainstream and upcoming JavaScript frameworks and their
techniques, focusing on the benefits of the new approaches. While many factors were
thoroughly examined, there were certain known limitations. First, analysis was mostly
restricted to the selected frameworks and their techniques. Another limitation stems from
the rapid pace of change in this field, which results in the fact that there is not much up-
to-date scientific research about this topic. Thus, blog posts and documentation need to
be often used for getting information. These resources are not vetted as well as scientific
research and can be more inaccurate and biased. Finally, the analysis of frameworks was
limited to certain aspects of them and done on a relatively general level. Thus, some
aspects, such as security and accessibility, were not included in the analysis.
Many benefits of using upcoming frameworks and novel techniques were found.
Newer solutions offer smaller runtime sizes, more efficient rendering approaches, and often
better DX. These are achieved by techniques such as more extensive compiler use and
adopting finely-grained reactivity with signals. Most of this progress is incremental, and
the benefits are mostly relevant for specific use cases. However, Qwik uses a technique
called resumability, which might fundamentally change the currently prevalent SSR by
eliminating the need for hydration.
It is also important to remember that incumbent solutions are improving and trying
to adopt the best practices. This can be seen, especially with quite a rapid pace of
change in React and Next. However, there seems to be a clear trend that more innovative
techniques are first adopted by upcoming frameworks. Only after they have served as
proof-of-concept and are well received by the developer community will more established
frameworks adopt similar solutions. This adoption process and general cooperation
among framework authors have led to frameworks becoming increasingly similar in certain
aspects. Another aspect to highlight is that there are different use cases that call for a
wide array of solutions that each come with specific trade-offs based on their design.
There are various interesting areas that could be explored in more detail due to
the somewhat general nature of this thesis. For example, the state management or
performance impacts of various techniques could be analyzed more closely. For state
management, there is consolidation towards signals, but every framework that uses signals
has its own implementation of them. Thus, one could compare those solutions in detail for
different frameworks. Different performance optimization methods could also be studied
further. A comparative study of compiler techniques would be a possible topic as well.
The handling of external third-party libraries was not analyzed in the thesis, but these
often have a significant performance impact. Thus, an interesting topic would be exploring
techniques that optimize the handling of these libraries. Lastly, the impact of artificial
intelligence on frameworks would be an intriguing topic to study.
29
References
[1] S. Aggarwal et al., “Modern web-development using ReactJS,”International Journal
of Recent Research Aspects, vol. 5, no. 1, pp. 133–137, 2018.
[2] T. Anderson, “TypeScript is ’not worth it’ for developing libraries, says Svelte
author, as team switches to JavaScript and JSDoc,” https://devclass.com/2023/05/
11/typescript-is-not-worth-it-for-developing-libraries-says-svelte-author-as-team-
switches-to-javascript-and-jsdoc/, 2023, [Accessed 23-11-2023].
[3] C. Anstey, B. Pavic, and J. Wagner, “Why does speed matter?” https://web.dev/
articles/why-speed-matters, 2019, [Accessed 29-10-2023].
[4] T. Berners-Lee, R. Cailliau, J.-F. Groff, and B. Pollermann, “World-wide web: The
information universe,” Internet Research, vol. 2, no. 1, pp. 52–58, 1992.
[5] S. Bhardwaz and R. Godha, “Svelte.js: The most loved framework today,” in 2023
2nd International Conference for Innovation in Technology (INOCON), 2023, pp.
1–7.
[6] I. Bouchrika, “Mobile vs desktop usage statistics for 2023,” https://research.com/
software/mobile-vs-desktop-usage, 2023, [Accessed 04-11-2023].
[7] Bundlephobia Team, “Bundlephobia |size of npm dependencies,” https://
bundlephobia.com/, [Accessed 30-10-2023].
[8] S. Campbell, “Misko Hevery on why Qwik will improve JavaScript frameworks,”
https://thenewstack.io/misko-hevery-on-why-qwik-will-improve-javascript-
frameworks/, 2022, [Accessed 19-10-2023].
[9] R. Carniato, “A hands-on introduction to fine-grained reactivity,” https://dev.to/
ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf, 2021, [Accessed
31-10-2023].
[10] ——, “Understanding transitional Javascript apps,” https://dev.to/this-is-learning/
understanding-transitional-javascript-apps-27i2, 2021, [Accessed 03-11-2023].
[11] ——, “The evolution of signals in Javascript,” https://dev.to/this-is-learning/the-
evolution-of-signals-in-javascript-8ob, 2023, [Accessed 30-10-2023].
[12] K. Collins, “How one programmer broke the internet by deleting a tiny
piece of code,” https://qz.com/646467/how-one-programmer-broke-the-internet-by-
deleting-a-tiny-piece-of-code, 2016, [Accessed 08-11-2023].
[13] S. J. Cook, “Hwy documentation,” https://hwy.dev/, [Accessed 04-11-2023].
30
[14] R. N. Diniz-Junior, C. C. Figueiredoy, G. D. Russo, M. R. Bahiense-Junior, M. V.
Arbex, L. M. Dos Santos, R. F. Da Rocha, R. R. Bezerra, and F. T. Giuntini,
“Evaluating the performance of web rendering technologies based on Javascript:
Angular, React, and Vue,” in 2022 XVLIII Latin American Computer Conference
(CLEI). IEEE, 2022, pp. 1–9.
[15] T. Dohmke, “Copilot transforms GitHub into the ai-powered developer platform,”
https://github.blog/2023-11-08-universe-2023-copilot-transforms-github-into-the-
ai-powered-developer-platform/, 2023, [Accessed 23-11-2023].
[16] D. Dorfmeister, “The uphill battle of memoization,” https://tkdodo.eu/blog/the-
uphill-battle-of-memoization, 2023, [Accessed 06-11-2023].
[17] S. Greif and E. Burel., “State of Javascript 2022,” https://stateofjs.com/en-US, 2023,
[Accessed 02-10-2023].
[18] C. Gross, “Two approaches to decoupling,” https://htmx.org/essays/two-
approaches-to-decoupling/, 2022, [Accessed 04-11-2023].
[19] R. Harris, “Virtual DOM is pure overhead,” https://svelte.dev/blog/virtual-dom-is-
pure-overhead, [Accessed 19-10-2023].
[20] ——, “Frameworks without the framework: Why didn’t we think of this sooner?”
https://svelte.dev/blog/frameworks-without-the-framework, 2016, [Accessed 29-10-
2023].
[21] ——, “The truth about Svelte,” https://gist.github.com/Rich-Harris/
0f910048478c2a6505d1c32185b61934, 2019, [Accessed 29-10-2023].
[22] M. Hevery, “Resumability vs hydration,” https://www.builder.io/blog/resumability-
vs-hydration, 2022, [Accessed 31-10-2023].
[23] HTMX Team, “Htmx documentation,” https://htmx.org/, [Accessed 04-11-2023].
[24] P. Hunt, “Why did we build React?” https://legacy.reactjs.org/blog/2013/06/05/
why-react.html, 2012, [Accessed 29-10-2023].
[25] F. H´amori, “The history of React.js on a timeline,” https://blog.risingstack.com/the-
history-of-react-js-on-a-timeline/, 2018, [Accessed 29-10-2023].
[26] icarus.gk, “All we know about Vue 3’s Vapor Mode,” https://icarusgk.hashnode.dev/
vue-3-vapor-mode, 2023, [Accessed 09-11-2023].
31
[27] 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.
[28] H. A. Jartarghar, G. R. Salanke, A. K. AR, G. Sharvani, and S. Dalali, “React apps
with server-side rendering: Next.js,” Journal of Telecommunication, Electronic and
Computer Engineering (JTEC), vol. 14, no. 4, pp. 25–29, 2022.
[29] J. Koivukoski, “Reducing the loading time of a single-page web application,”Master’s
thesis, Aalto University, School of Science, Espoo, 2021.
[30] A. Lipi´nski and B. Pa´nczyk, “Performance optimization of web applications using
Qwik,” Journal of Computer Sciences Institute, vol. 28, pp. 197–203, 2023.
[31] B. Livshits and E. Kiciman, “Doloto: Code splitting for network-bound Web 2.0
applications,” in Proceedings of the 16th ACM SIGSOFT international symposium
on foundations of software engineering, 2008, pp. 350–360.
[32] T. Lonka,“Improving the initial rendering performance of React applications through
contemporary rendering approaches,” Master’s thesis, Aalto University, School of
Science, Espoo, 2023.
[33] Meta, “Jsx specification,” https://facebook.github.io/jsx/, 2022, [Accessed 29-10-
2023].
[34] J. Miller, “Application holotypes: A guide to architecture decisions,” https://
jasonformat.com/application-holotypes/, 2019, [Accessed 07-11-2023].
[35] Mozilla Developer Network, “Labeled statement,” https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Statements/label, 2023, [Accessed 30-10-2023].
[36] J. M¨
annist¨
o, A.-P. Tuovinen, and M. Raatikainen, “Experiences on a frameworkless
micro-frontend architecture in a small organization,”in 2023 IEEE 20th International
Conference on Software Architecture Companion (ICSA-C), 2023, pp. 61–67.
[37] K. Nanz, “Everything you need to know about the updated React docs,” https://
dev.to/kathryngrayson/whats-new-in-the-updated-react-docs-on2, 2023, [Accessed
07-11-2023].
[38] S. Newman, “Backends for frontends,” https://samnewman.io/patterns/
architectural/bff/, 2015, [Accessed 30-10-2023].
[39] R. Ollila, N. M¨
akitalo, and T. Mikkonen, “Modern web frameworks: A comparison
of rendering performance,” Journal of Web Engineering, 2022.
32
[40] P. O’Shaughnessy, “Disappearing frameworks,” https://medium.com/samsung-
internet-dev/disappearing-frameworks-ed921f411c38, 2018, [Accessed 03-11-2023].
[41] A. Osmani, “Photoshop is now on the web!” https://medium.com/@addyosmani/
photoshop-is-now-on-the-web-38d70954365a, 2023, [Accessed 03-11-2023].
[42] J. Palmer, “Announcing v0: Generative ui,” https://vercel.com/blog/announcing-
v0-generative-ui, 2023, [Accessed 09-11-2023].
[43] Patterns.dev, “Rendering patterns,” https://www.patterns.dev, [Accessed 10-10-
2023].
[44] PHP Documentation Group, “A brief history of PHP,” https://ifj.edu.pl/private/
krawczyk/php/intro-history.html, 2000, [Accessed 07-11-2023].
[45] O. Proskurin, “How React Forget will make React useMemo and useCallback
hooks absolutely redundant,” https://dev.to/usulpro/how-react-forget-will-make-
react-usememo-and-usecallback-hooks-absolutely-redundant-4l68, 2023, [Accessed
07-11-2023].
[46] Qwik Team, “Framework benchmarks,” https://github.com/BuilderIO/framework-
benchmarks, 2023, [Accessed 04-11-2023].
[47] ——, “Qwik reaches v1.0,” https://www.builder.io/blog/qwik-v1, 2023, [Accessed
29-10-2023].
[48] React Team, “React documentation,” https://react.dev/, 2023, [Accessed 29-10-
2023].
[49] S. Sewell, “Introducing Visual Copilot: A better Figma-to-code workflow,” https:
//www.builder.io/blog/figma-to-code-visual-copilot, 2023, [Accessed 04-12-2023].
[50] V. Sj¨
olund and D. Wernersson, “Choosing a rendering framework a comparative
evaluation of modern Javascript rendering frameworks,” Bachelor’s thesis, Linnæus
University, Sweden, 2023.
[51] Stack Overflow, “Developer survey 2023,” https://survey.stackoverflow.co/2023/,
[Accessed 02-10-2023].
[52] Svelte Team, “Introducing runes,” https://svelte.dev/blog/runes, 2023, [Accessed
20-10-2023].
[53] G. Tayar, D. Rosenwasser, R. Cintra, and R. Palmer, “Ecmascript proposal for type
syntax that is erased,” https://github.com/tc39/proposal-type-annotations, 2022,
[Accessed 23-11-2023].
33
[54] T.-D. Tripon, G. Adela Gabor, and E. Valentina Moisi, “Angular and Svelte
frameworks: A comparative analysis,” in 2021 16th International Conference on
Engineering of Modern Electric Systems (EMES), 2021, pp. 1–4.
[55] J. Veps¨
al¨
ainen, “Disappearing frameworks explained,” arXiv preprint
arXiv:2309.03201, 2023.
[56] J. Veps¨
al¨
ainen, A. Hellas, and P. Vuorimaa, “The rise of disappearing frameworks
in web development,” in International Conference on Web Engineering. Springer,
2023, pp. 319–326.
[57] ——, “The state of disappearing frameworks in 2023,” arXiv preprint
arXiv:2309.04188, 2023.
[58] E. Wallace, “Figma is powered by WebAssembly,” https://www.figma.com/blog/
webassembly-cut-figmas-load-time-by-3x/, 2017, [Accessed 03-11-2023].
[59] E. Woychowsky, AJAX: Creating web pages with asynchronous JavaScript and XML.
Prentice Hall Upper Saddle River, NJ, USA, 2006, vol. 8.
