Tags: JavaScript, Express.js, Hotwire, React, Software Architecture, Server-Side Rendering, Single Page Applications
After analyzing HTML (server-side) rendering in [Part 1], JavaScript (client-side) rendering in [Part 2], and Hotwire rendering in [Part 3], we are finally examining how to make a choice. What might be the main criteria for this decision, and what are the consequences of the choice made?
To tackle the topic of web application interface (GUI) rendering and to compare available approaches, the article is split into following parts:
Stay updated with the latest articles from our blog! Choose the tags and topics you're interested in, and we'll send you relevant content directly to your inbox.
As with any general business or technical problem, there is no single clear-cut solution, and web GUI rendering is no exception. The best choice is determined by considering different perspectives, with the solution that best satisfies all of them emerging as the winner.
In this article, the following perspectives are analyzed, and a solution is chosen based on them:
The first relevant perspective to consider is whether the expected user interface is static or dynamic.
Static GUI refers to a web interface that does not change due to user interaction or external factors. In this context, the page loaded for the end-user remains unchanged during their usage of that page. A common interaction that still falls under the static GUI category is when a user's action redirects them to another page, such as clicking on a navigation bar or submitting a form via an action button or link.
It’s important not to confuse static or dynamic GUI with static or dynamic web applications. A dynamic web application generates different content based on various factors. For example, a blog where each post has unique content sourced from a database would be considered dynamic. However, from the GUI perspective, the post page itself is largely static, as the interface remains unchanged during the user's interaction with a specific article. Exceptions might include interactive elements like search and navigation buttons, which are dynamic.
Dynamic GUI, on the other hand, refers to interfaces where multiple small portions or larger sections (partials) of the page change based on user interactions. For example, in an invoicing application, the user might fill in customer details, select an invoice type, set a payment due date, or add and remove invoice items. Each of these actions triggers dynamic behavior in the interface, such as recalculating totals, applying taxes, and validating rules for invoice creation. For instance, adding or removing invoice items updates the total amount, while selecting a different currency adjusts the exchange rates accordingly. In this scenario, nearly every interaction on the invoice page causes one or more elements of the interface to update dynamically.
Choices:
The development efficiency perspective is a critical factor to consider. The complexity of GUI requirements in a project significantly influences the suitability of available approaches, making some choices simpler or more complex. Each approach discussed in this article spans the spectrum from "very simple" to "very complex," depending on the specific GUI requirements.
For example, static GUI pages are easiest to implement using HTML (server-side) rendering. Conversely, implementing highly complex dynamic GUI pages with HTML rendering is the most challenging option.
When the requirements fall between these extremes—where independent partials are updated (not a purely static GUI), but user interactions do not affect multiple parts of the interface (not a highly dynamic GUI)—Hotwire emerges as the best choice. In such scenarios, development is relatively straightforward with Hotwire, while the other two approaches, HTML rendering and Single Page Application (SPA) rendering, result in a medium level of complexity.
An important perspective to consider is the requirement to render one or more visually complex elements that need to be updated due to external factors or user interactions. Such elements typically involve usage history, where past interactions influence the current state. Examples include schematic designs, custom configurable dashboards, or similar components. In these cases, each update often involves adding new elements, making every re-render progressively more complex.
For such scenarios, the best approach among the three considered in this article is Single Page Application (SPA) rendering. With SPA rendering, the interface is loaded once and subsequently updated incrementally with additional data, avoiding the need to re-render the entire element.
The next best option would be partials rendering using Hotwire modules, provided the additional or updated elements are designed as independent parts (partials). This approach ensures only the necessary sections are updated, reducing the rendering workload compared to reloading entire components.
The least effective approach is HTML (server-side) rendering, where the entire interface is re-rendered from scratch with each interaction.
The final perspective considered here involves real-time aspects of the requirements. Real-time updates occur when the interface must be updated within a specified time span following one or more external events. The choice of rendering approach depends on the allowed time span and the complexity of the required visualization.
For scenarios with longer time spans (e.g., updates once per hour or half-hour for slowly changing values like weather temperature), both HTML (server-side rendering) and Hotwire rendering are suitable options. These approaches can handle periodic updates efficiently, as the frequency and complexity of the updates do not demand rapid or continuous rendering.
In contrast, for high-speed scenarios requiring updates in milliseconds—such as stock or cryptocurrency market tracking—Single Page Applications (SPAs) are the best choice from the three. SPAs enable charts, order books, trade lists, and user-specific data to be rendered during the initial load, with subsequent updates handled incrementally as new information arrives. This approach ensures the interface remains responsive and up-to-date in real-time without requiring a complete re-render.
Having considered all these perspectives, it becomes clear that the choice of rendering approach depends on the specific requirements. The good news is that some scenarios lead to very clear-cut decisions:
For requirements that do not fall into these clear-cut categories, deeper analysis is needed. In such cases, development efficiency becomes a key consideration. Throughout the previous parts of this article (Parts 1 to 3), we’ve discussed the complexity of each approach when they are used to satisfy specific requirements:
Based on the perspectives shared in this article, the decision-making process should follow these steps:
In summary: "Choose the least complex approach that satisfies the requirement."
It’s important to note that these approaches are not mutually exclusive. Within an application that primarily uses HTML rendering, certain parts can be implemented with partial rendering or even behave like SPA-rendered elements. Similarly, the reverse is also possible. However, such adaptations are often impractical and not scalable, so we want to keep them as small part of our project.
So, if the application GUI is almost entirely static, with only a small part requiring SPA-like behavior, it is better to choose HTML rendering and use JavaScript to handle the dynamic section (SPA or Hotwire). In cases of uncertainty, favor the more complex option from the list. The reasoning is straightforward: it is easier to create a static page in Hotwire or SPA framework than to build a dynamic component in HTML and JavaScript.
Contact Us or Schedule a Meeting with us to get an offer for our development & consulting services regarding your current or next Web project.