Back to the Future: Server-Side Web Pages With Kotlin (Pt. 1)
Server-side, web page rendering, is making a comeback; here's a look at how an emerging Kotlin library could be used for this purpose.
Join the DZone community and get the full member experience.
Join For FreeWeb development has undergone a variety of changes since the internet became popularized in the 1990s:
- First came the most basic of the basic: HTML pages that were completely statically rendered, with no dynamism whatsoever.
- Later came technologies like the Common Gateway Interface that allowed for generating HTML code for a webpage programmatically.
- Then came templating engines like JavaServer Pages (now Jakarta Server Pages), ASP.NET, and Thymeleaf that enabled developers to work with template files that were predominantly “HTML-looking” with programming code intermixed.
- Next came Javascript-based “client-side scripting” frameworks like Angular, React, and Vue, which transformed web development into two separate disciplines: the “backend” development that contained the traditional web server and business logic code along with “front-end” development (using the frameworks above) that would be concerned with a website’s visualization and receive data from the backend.
However, this is not to say that development trends only advance in one direction and never backward. For example, NoSQL databases like MongoDB quickly gained popularity in no small part due to their ability to hold unstructured data compared to traditional SQL databases like PostgreSQL and MySQL, yet those latter databases have evolved as well and can now contain unstructured data via the JSONB and JSON data types, respectively. Likewise, new Javascript frameworks like Next.js are starting to offer options for server-side rendering alongside their now-traditional client-side rendering capabilities. Again, server-side templating engines like Thymeleaf have also continued to evolve, with Thymeleaf releasing a new version of the framework last December.
But why continue using server-side rendering? Admitting as much – especially for a new project – might draw reactions of disdain in the world of web development where the question asked is not whether one uses client-side frameworks like Angular, React, or Vue but rather which of those client-side frameworks is being used. Despite this, server-side web page generation does pose some advantages compared to client-side web page generation:
- More lightweight experience for the end-user: instead of all of the Javascript libraries that are needed to run a client-side application (along with the moving parts that are needed to run the said application), all that is delivered to a user’s browser is the HTML code that the server has generated along with any auxiliary Javascript and CSS files.
- Server-side web pages can leverage more security-related processing by virtue of the code that renders the web pages having direct access to the security functionality of the server.
- Search Engine Optimization (SEO) – while not being impossible to implement with client-side rendering – is easier to conduct with server-side rendering.
In addition, there still remain active options for “going further back in time,” i.e., using server-side templating engines. For example, Thymeleaf – one of the most well-known choices for Java-based server-side templating engines- also continued to evolve, with Thymeleaf releasing a new version of its framework last December and was highlighted at the Spring I/O 2022 conference in Barcelona. Again asking the question: why would one choose this instead of the previous options? Alongside the advantages listed above for server-side rendering compared to client-side rendering, templating engines offer further benefits:
- There will be fewer potential compatibility issues with regard to whether the user’s browser is capable of executing the Javascript functionality necessary to make the requested web page render and carry out its duties correctly.
- Full-stack development is easier due to there essentially being no separation between the “backend” and “front-end” code; moreover, there being no separate tech stack for the web page generation functionality means less of a learning curve for the project.
With that in mind, what options are available for a developer who wants to create a Spring Boot web application with purely Java-based server-side rendering? There are quite a few choices for templating engines alongside Thymeleaf that one could leverage. In addition to this variety of options, though, another option is available within the realm of the Kotlin ecosystem. The developers of the Kotlin programming language have been busy at work, not just with the language itself but also with various supporting libraries that leverage the language’s capabilities to provide new tools for developers. One of these libraries is the kotlinx.html library which – as the library’s name suggests – allows a developer to generate HTML in a “Kotlin-esque” manner.
About Kotlinx.html
At its core, Kotlinx.html creates essentially a “Domain-Specific Language” (DSL) for writing code that generates or manipulates HTML code. To give an example, here is a small program that launches a Node.JS server and appends HTML code to the resulting webpage body:
fun main() {
window.onload = { document.body?.sayHello() }
}
fun Node.sayHello() {
append {
div {
div {
onClickFunction = { event ->
window.alert("I was clicked - ${event.timeStamp}")
}
p {
+"This is a paragraph"
}
}
a(href = "https://github.com/kotlin/kotlinx.html") {
+"This is a link"
}
}
}
}This results in the following webpage:
Very basic, but as we’ll see later, more “realistic” HTML code can be generated via this library. The above example still provides examples of the key parts of Kotlin functionality that provide the capability to write this DSL:
- Extension Functions: It is possible to create a “new” member function for any class in Kotlin, including pre-existing classes like
Stringor theNodeclass in the example code (which is a basic translation of theNodeclass in the Web DOM model). In essence, this is syntactic sugar for defining a function that accepts an instance of the target class as the first parameter of the function, along with the remaining defined parameters. Still, the benefit is that it allows for cleaner-looking function calls. - Scope Functions: Scope functions are functions that accept a lambda expression that take the object on which the function has been called as the “receiver” – either implicit via
thiskeyword or explicitly – of any function calls within the lambda. As the code demonstrates, this allows the developer to “embed” HTML tags within one another in a way that is similar to actual HTML code. - Named and Default Function Arguments: When declaring HTML tags within the Kotlin code, it is possible to pass in arguments to the specific tag attributes that need configuration. The declaration of the hyperlink tag demonstrates this by specifying the
hrefattribute while leaving the remaining arguments of the tag declaration –targetandclasses– to be filled in by default according to the function definition. - Operator Overloading: Kotlin permits the definition of functions that use traditional operators like +, -, *, /, and so on. As with extension functions, this is syntactic sugar for functions that take in the arguments involved in the declaration within the source code. In the case of the code above, it serves to specify any text value that is to be placed within the enclosing HTML tag (note that the function
text()is also available, and the operator function + here serves as a pass-through totext()as well).
Put together; these features highlight how powerful Kotlin’s capability is to create DSLs for various purposes. Those who would like to see another example of this functionality in action are encouraged to take a look at the Kotlin DSL for Gradle, an alternative to the traditional Groovy-based markup language for Gradle that has been in production since the release of Gradle 5.0 in 2018.
Experimenting
So how does the Kotlinx.html library compare to a traditional templating engine like Thymeleaf? The most natural way to demonstrate this is to attempt to build the same Spring Boot-powered website – a rudimentary website with Bootstrap styling for a hypothetical bookstore that allows the user to view, add, and remove books and their authors – using the two approaches: one that employs Thymeleaf, and one that leverages kotlinx.html.
Thymeleaf
The approach for Thymeleaf is relatively straightforward:
- First, add
org.springframework.boot:spring-boot-starter-thymeleafto the list of project dependencies (in this case, version 3.0.2).
Then, create a template HTML file in the resources/templates directory that contains the necessary Thymeleaf code for the desired webpage:
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="en">
<head>
<title>Bookstore - View Authors</title>
<link th:href="@{/css/bootstrap.min.css}" rel="stylesheet">
<script th:src="@{/js/bootstrap.min.js}"></script>
<script th:inline="javascript">
function confirmDelete(name) {
return window.confirm("Really delete author " + name + "?");
}
</script>
</head>
<body>
<div th:insert="~{fragments/general.html :: header(pageName = 'Authors')}"></div>
<div id="content">
<h2>Our Books' Authors</h2>
<ul>
<li th:each="author : ${authors}">
<form method="post" th:action="@{/authors/{authorId}/delete(authorId=${author.id})}"
style="margin-block-end: 1em;" th:onsubmit="return confirmDelete([[${author.name}]])">
<a th:href="@{/authors/{authorId}(authorId=${author.id})}" th:text="${author.name}"></a>
<button type="submit" class="btn btn-danger">Delete</button>
</form>
</li>
</ul>
<a class="btn btn-primary" th:href="@{/authors/add}">Add Author</a>
</div>
<div th:insert="~{fragments/general.html :: footer}"></div>
</body>
</html>This file is for viewing all authors whose books the bookstore has available and is called. view_authors.html.
- Any fragments of Thymeleaf/HTML code that one may wish to reuse – like the header and footer fragments that are used in each webpage – can be placed in a separate HTML template file, in this case.
resources/templates/fragments/general.html: