JavaScript? Yes, but in moderation

Browsers are also a more uncontrolled execution environment than our server. We need to pay attention to this when we push more code into the browser.

JavaScript is executed in a single thread. Only I/O operations are executed asynchronously outside of this thread. A CPU-task blocks the thread. CPU intensive tasks therefore cause the page to become unresponsive. If we execute a lot of business logic, we thereby block the thread and the page feels frozen. Today we can execute code on a separate thread with the help of Web Workers. However, this isn’t supported on older browsers which further decreases the performance on older, slower devices.

Additionally, the uncontrollable execution environment also has certain repercussions. On the server we can choose a version of our programming language (e.g. JDK 7). However, there are an unbelievable amount of web browsers in many different versions. Even the newest version of a browser does not support all of the specified features. The complexity of testing an application is therefore much higher.

In summary, shifting routing, templates and presentation logic onto the client increases the responsibility that it has. Additionally, more infrastructure, coordination, duplication, and indirection are necessay and we transport code from a controlled execution environment into an uncontrolled execution environment.

An alternative architecture

Let’t take a step back and compare the architecture from the previous section with a classic GUI-Application which we would develop with .NET, Swing, or Eclipse RCP. We will realize that the differences are pretty small. This seems very attractive for some teams, especially when they have not yet developed any web applications. Experience with a 3-layer-architecture can be transfered onto the web. The execution environment is no longer Windows, with the CLR or the JVM, but the JavaScript runtime environment in the browser.

Unfortunately, despite its popularity, this approach ignores the actual strength of the web which has been shaped by declarative languages and which therefore has an extremely error-tolerant architecture. A change in technology can illustrate this: the browser is a highly performant graphics engine and is the most optimized application on practically all platforms. It is implemented in C, C++ or other low-level languages like Rust and exploits the hardware acceleration from the underlying systems as much as possible. We can use these capabilities by accessing them via API from JavaScript. Alternatively, we can use the declarative languages HTML and CSS which were developed especially for this environment. The low-level code of the browser can parse, interpret and transform them into the document object model (DOM) for rendering faster than anything else.

Because these languages were created exactly for this purpose, their performance is optimal. Additionally, they are declarative and especially error-tolerant in the adverse execution environment of the browser that is described above. If there is an error in JavaScript code, an exception is thrown and the rest of the code will not be executed. CSS, on the other hand, skips over unknown rules, and HTML treats unknown tags as <span> elements. Their declarative nature also makes it possible to ensure compatibility between browser versions to a great extent. This is how server-side rendered HTML and CSS pages can be interpreted by older and newer browsers, and even devices which did not exist at the time of the creation of the code can usually interpret them to the extent that they are usable.

Those who write server-side code can consider HTML as a component configuration: it is possible to use existing components such as text and input fields, select elements (lists), and video and auto elements without implementing them again. Naturally, JavaScript is also used, but is no longer a necessary ingredient for a working page and instead is an additional element which can improve the ergonomics or the look of the page.

We recommend this approach of relying on the basic features of the web and using these three key technologies based on these core principles. For this reason, we have created a website with best practices and given the approach a name: ROCA (ROCA stands for Resource Oriented Client Architecture).

How can I apply this practially?

Up to now we have talked about the abstract architecture, but what does this look like in practice? Can we really imagine a web application without JavaScript? We have maybe become used to retrieving some JSON structure from the server and using it to generate DOM elements. But JSON is not the language of the web. HTML is the language of the web. Why do we need to take an additional step so that a JavaScript framework can create HTML from our JSON? Almost every backend framework includes a templating engine with which we can directly generate HTML and send it to the client. For instance, the default Spring-Boot application comes bundled with Thymeleaf, and we can use it to directly deliver HTML pages without using any kind of JavaScript framework.

Make it work: HTML

If we want to develop an application without JavaScript, the first step is to create a web application which consists of only HTML. HTML5 includes quite a few elements with a lot of functionality. Three examples of these are:

• <input type="date"> creates a datepicker.
• <audio> creates an player for audio files
• <video> creates a player for video files.

Additionally, there is always a fallback for these elments so that older browsers can still continue to work. Often, the browser can make better decisions about how to render these elements than we can. An <input type="date"> on a smarthone is optimized so that users can select a date with their finger, and it is easier to use this datepicker than the datepicker from a JavaScript Library for this reason. We also should not forget that HTML is not only intended for presentation logic. With a simple link we can jump from one page to another. HTML forms are also extremely powerful and allow us to create dynamic HTTP requests based on user input that are then sent to the server. The server then executes the change that is requested by the user (Fig. 4).

Sometimes we also want to show a different page based on user input. Since the server is now controlling the functionality in the application, it can decide where to go next with a redirect (Fig. 5).

One of the main benefits of this approach is that HTML can be easily consumed by screen readers. This makes it relatively easy to implement accessibility in the application. The A11Y Project is a good resource for further improvements. Of course, it is also possible to create a JavaScript-centric application which is accessible, but it requires greater effort and a lot of focus.

Reusability

Another benefit of HTML is that we can arbitrarily nest elements. In order to make our UI elements easier to reuse, we can extract some element into components. Components are a reusable HTML structure which we can use as an abstraction for our functionality.

To maintain an overview of our components, we can structure them in a system like Atomic Design. You can find more about them in an article by Ute Mayer on page 58. Here larger components always contain smaller components. The easiest way to practically apply this is to define an HTML snippet and to copy the markup and switch out the content in the component. However, this isn’t easy to maintain over time. Most templating engines provide a way to define an HTML snippet once and make it reusable. In Thymeleaf we can do this with th:replace and th:insert.

One of the main benefits of this approach is also that we can style our components based on this HTML structure. This is where the larger challenges begin.

Make it pretty: CSS

Now we come to the point where we may be likely to fail. On the one hand, we could argue that it is most important that the application works even if it doesn’t look very nice. On the other hand, no one wants to use an application which is ugly. In this context, certain aesthetics are important.

Although “beauty” is subjective, we can invest a lot of time in topics like design or typography in order to develop a feeling for how things should appear in a finshed product. Unfortunately, many developers do not have the necessary time or desire to really get into the topic.

Luckily, we don’t always have to reinvent the wheel. It is possible to use finished component libraries like Bootstrap or Foundation. Here the designers have already made the most important decisions so that the application is usable for end users.

For those who want to modify a component library and extend it with additional components, a pattern library toolkit like Fractal is very useful. It is especially helpful when components should be reused between projects. For larger CSS projects we recommend using a preprocessor like Sass so that CSS can be split into multiple files. Then the CSS for a specific HTML component can be placed directly beside the component in the same folder. Here we can use naming convention like BEM for the CSS components. An asset pipeline like faucet-pipeline can be used to compile the CSS. When we also are writing JavaScript for our application we can use faucet for that as well.

Make it fast: JavaScript

We have reached a point where we can stop: we have a working web application that looks pretty. However, we can now optimize and improve our application with JavaScript. The reason why an SPA often feels faster is that the browser does not have to parse and evaulate the CSS and JavaScript with every page transition. With a library like Turbolinks we can achieve exactly this: when a user clicks on a link, the HTML on the page is replaced without having to reload the CSS and JavaScript.

With HTML forms we can achieve something similar: instead of sending the browser the content of a form and retrieving the result as a new page, we can submit the form via Ajax and work with the HTML which is returned and replace only parts of the page.

class MyComponent extends HTMLElement {
  connectedCallback() {
  // instantiate component
  }
}
customElements.define("my-component", MyComponent)