Efficient development of web user interfaces for business applications

Laptop Apps Icons
© Chinnapong / Fotolia.com

Native surfaces are Legacy!

Web interfaces are now also expected in application areas that involve the internal use of a system: clerks, workers, power users. The benefits for the user are obvious: no installation effort, basic availability on different devices, portability, standardization (communication, security) in the front-end area. A non-web-based application may be as great as it pleases – it has a huge leg twist on its success in the immediate future.

A lot of software houses, the z. B. originated in the 90s, are facing a major conversion pressure. Of course, these software houses have also gained experience with the Web world – and “glued” web extensions to their product where the scenarios required it. But the core internal-use dialogues developed in native technologies (C ++, Java, C #, Qt) very often remained untouched, knowing that their conversion would be a different house number …

Fig. 1: Case worker scenario in the browser. © Björn Müller

Business applications have their own characteristics

Business applications are usually quite large: the number of dialogues is high, typically in the three-digit range. Many of these dialogues are classic, form-like masks with a focus on consistent data entry. There are also lists, evaluations, diagrams – but also a large number of special and demanding dialogues: planning boards, control stations, graphic monitoring and so on.

  • Many of the dialogues do not follow the motto ” Simplicity first! “, But ” Efficiency first! “. The user wants to see all the data that helps him to do his job – so the amount of information in many dialogues is sometimes very high.
  • Business applications have a lifecycle that typically goes well beyond 10 years. An application system – for example, a production control – is not exchanged at the customer every 5 years, but has to be developed and maintained for substantial longer periods of time.
  • The development teams behind business applications usually have a manageable size. You often see teams of 10-15 developers who have been working on an application since the 1990s, and who today have a very extensive application thanks to a rather homogenous technology (eg “everything in Java”).

The development of a web front-end is therefore a huge project – in the case of an existing application, it is equivalent to a re-implementation. The demands on efficiency and long-term investment security are correspondingly high.

Mainstream: client-centric development of web applications

Client centric approach
Fig. 2: Client-centric approach. © Björn Müller


Today, the web development architecture follows the following mainstream: Using HTML and JavaScript technologies, develop a client-side program that works independently in the browser – the so-called ” single page application “. This program builds the interface of HTML elements for the user, sets properties of HTML elements, responds to their events and data changes. It fetches data via interfaces (REST, web service) from its server, transfers it to the dialogs and, if necessary, writes back data via interfaces to the server.


The basis of everything is therefore on the one hand HTML / CSS. Everyone knows by now that direct handling is complex and also dangerous from a browser compatibility point of view.

Therefore, there are a variety of client-side frameworks that aim to encapsulate this complexity and provide the developer with a component model in which HTML events are more or less concealed. Known representatives of these frameworks are z. Angular, ReactJS, Sencha, Vue, Polymer and SAP UI5. On the one hand, the frameworks offer a JavaScript modularization concept as the basis for the formation of components as well as component libraries based on them, in which a large number of controls are provided that go far beyond the range offered by HTML.

Developing a client-side application without the help of such a framework makes no sense at all: the technology costs that one has to operate to develop HTML / CSS efficiently are simply too high.

But watch out: on the one hand, the development of dialogs with the help of a framework is initially complex. Every framework has its own usage of JavaScript and HTML / CSS, which you first have to get used to, and which then has little to do with the development of “simply learned JavaScript”. In all frameworks, as a developer, you often come into direct contact with HTML / CSS, at the latest when it comes to the development of complex dialogs (eg interactive planning board).

On the other hand, all frameworks do not come around to core weaknesses of HTML / CSS – after all, they are based on it. For example, in the area of ​​vertical placement, HTML has weaknesses that are based on the fact that HTML does not “think” screen-oriented, but always draws it into an endless page. It is Z. For example, for many Java UI developers, it’s amazing how difficult it is in an HTML world to define a constant header area, a constant footer area, and a scrollable content area in between.


The web developers love JavaScript! It seems so. Be warned, or better: learn to differentiate what most people love about JavaScript. So let’s first look at the lovable aspects:

  • First of all, there are only JavaScript as a programming language and runtime environment in the browser. The only indirect way to work around this is to choose a programming environment that offers a different, “better” language for development, and then translate that language to JavaScript ( cross-compiling ). TypeScript from Microsoft does that and Google did that within the Google Web Toolkit (GWT) based on Java.
  • JavaScript is running “immediately”! As a developer you do not have to install a development environment, you do not need a compile / build process. Save code and try it directly! J2EE Java projects, in particular, are familiar with the scenarios in which small code changes can only be tested after the execution of powerful ant / maven / gradle builds and then time-consuming deployment on the server.
  • JavaScript has become fast. Thanks to just-in-time-compilings, it has a good performance. Statements that JavaSript is too slow to handle large, complex tasks are definitely a thing of the past.

Now comes the big “but …”: JavaScript is a scripting language with serious disadvantages, and they lie in the type concept of the scripting language:

  • Well-known is the missing typing. A variable in JavaScript can have a string value, then a numeric value and then an object instance. There is no compiler that monitors type safety. This missing typing is just one external feature of the completely dynamic type concept of JavaScript. As a developer, you can add or remove any attribute “ad hoc” to any object (well, objects are actually function instances …).
  • Also well-known is the lack of linguistic possibility of inheritance. The JavaScript way is called “prototyping” – an approach that is highly flexible, but which can not oppose the simplicity of inheritance concepts. Prototyping can be used to build structures that work in a similar way to inheritance, which is what some of the enumerated frameworks do. However, the inheritance is not in the language, but in the framework.

Here you notice: JavaScript was not created to formulate application logic in a structured way. Instead, it was created to be flexible and sometimes wild in the browser. Attaching an additional attribute and an additional method to a field or to all fields means that, in typical UI environments (eg Java-Swing), it is quite time-consuming to derive corresponding classes. In JavaScript, the new attribute and the new method are simply appended at runtime. Finished!

The execution of major developments with a large part of application logic components based on JavaScript thus has a critical complexity – and requires an extremely high level of discipline from all participants. Simple write errors when referencing variables can lead to errors that become known only at runtime. Although the tooling for JavaScript has improved, it still can not prevent simple error constellations due to the dynamics of the language.

JavaScript developments often start in a small, manageable framework – with a “JavaScript crack” that has all the contexts in mind. The challenges become immensely bigger as the projects grow – and the efficiency is extremely poor. From my personal viewpoint, large projects can not be satisfactorily mapped using JavaScript – in this case, languages ​​set to JavaScript, such as “TypeScript”, create significantly better prerequisites.

Angular, ReactJS, Sencha, Vue, Polymer, SAP UI5 …

Please do not expect any statement now: this framework is the best! Each has its own specific history and followers. Firstly, the frameworks differ in the depth at which they support the developer: some focus on the “view” layer (eg ReactJS) and release the developer, as now specifically the UI components to the application logic is connected in the client. Others (eg Angular) go deeper and then include MVC concepts and advanced functions in the field of logical processing.

On the other hand, the frameworks differ in their handling of JavaScript: Angular, for example, is not directly based on JavaScript, but on the “TypeScript” already mentioned.

efficiency analysis

Today’s mainstream development model of standalone client development, along with the common frameworks, provides tremendous ease of application development compared to native HTML / CSS.

Nevertheless, it is a long way from being an efficient, simple foundation for complex application clients with hundreds of dialogues. The “skillset” required by the application UI developers is extensive, and the lack of compile security in the JavaScript area is a significant efficiency problem. Application developments that, for example, move from a Java client to a Web client, are often overwhelmed by this complexity.

Long-Term Consideration – Framework Volatility

Let’s take a look at one of the big framework builders – Google: In 2006 Google released the “Google Web Toolkit (GWT)”. In 2012, GWT was turned over to the community because Google wanted to exclude and focus on the “Dart” framework. Hardly anybody speaks of darts today. In 2009, the line “AngularJS” was also proclaimed. In 2016, “Angular 2” came as a successor, but incompatible with “Angular”.

Of course, there are maintenance releases for the old frameworks. But the problem is clear: continue the area of ​​web development is one in which constantly new framework hype is driven through the streets. The framework I’m applying for today will be obsolete in 5-10 years – and the hype will be elsewhere! Of course, this is a big problem from the point of view of the development of a comprehensive business application – the development of core dialogues is simply too costly to subject them to a framework change every year.

Server-centric development of web applications

The counterpart of client-centric development is server-centric development. This is not the mainstream today, but the past few decades have shown that this mainstream seems to be subject to a permanent cycle: every time you can “do” something in the client, it magically pulls all developers into the client. Then all of a sudden, everyone suddenly sees that “too much logic” is at the front, demanding too much data, and you are returning to the server-centric approach.


Server zentrischer Ansatz
Abb. 3: Server-zentrischer Ansatz. © Björn Müller

In the browser runs a JavaScript program, the “Web Renderer”. This program is a ” single-page application ” in type, but has little to do with “application” because it is a technical, application-independent program.

The web renderer is sent by the server the description of a surface to be displayed, z. As an XML definition. It interprets this description and renders the dialog in HTML components accordingly – with whatever control library. The web renderer now waits for actions of the user within the established dialog. Depending on the type of action, the action is buffered in the client (for example, entries in “normal” fields) or the action triggers communication with the server. In a communication, all buffered actions as well as the triggering action are communicated to the server in one go.

Server processing now receives the actions that the user performed in the dialog and integrates them into the application. Then she returns the dialog description of the now updated dialog to the web-renderer. This is done in the delta process, so that not always the complete dialog description is sent, but only changes to this. The web renderer now interprets the updated dialog description and integrates it into the existing dialog.

The web renderer is nothing more than a technical, generic program that displays dialogs coming from the server and then sends the user’s input back to the server. The actual interaction processing thus takes place on the server: here it is defined what exactly is sent as a dialog to the client and how to respond to actions of the user.

Framework needed

Server-centric development requires a framework that handles the described processing. It consists of:

  • The web-renderer and JavaScript developed in JavaScript
  • a server-side counterpart, in which the definition and processing of the dialogues is made possible in a simple manner.


Hello World!
Abb. 4: Hello World! © Björn Müller

A number of software developments have written such or similar framework themselves – but there are also freely available frameworks. Vaadin is probably the most well-known name in the java camp, and the “CaptainCasa Enterprise Client” is also known in German-speaking countries.

What does a concrete development of a ” Hello World! ” Page with such a framework – here: “CaptainCasa Enterprise Client” – look like?

The developer defines the page on the server based on a control library – either dynamically or by XML definition:

<br><t:rowtitlebar text="Some demo..." /><br><t:rowbodypane ><br>    <t:row ><br>        <t:foldablepane rowdistance="5" text="Hello world!" width="100%" ><br>            <t:row><br>                <t:label text="Your Name" width="120" /><br>                <t:field text="#{d.DemoHelloWorld.name}" width="200" /><br>            </t:row><br>            <t:row><br>                <t:coldistance id="g_ccpreview_9" width="120" /><br>                <t:button actionListener="#{d.DemoHelloWorld.onHello}" text="Hello!" /><br>            </t:row><br>            <t:rowdistance height="30" /><br>            <t:row id="g_ccpreview_12" ><br>                <t:label text="Result" width="120" /><br>                <t:field enabled="false" text="#{d.DemoHelloWorld.output}"<br>                width="100%" /><br>            </t:row><br>        </t:foldablepane><br>    </t:row><br></t:rowbodypane><br><t:rowstatusbar/>

There are so-called expressions in the layout that point to a server-side Java class. Fields are associated with Java properties, Buttons with Java methods:

public class DemoHelloWorld extends DemoBasePageBean
String m_name;
String m_output;
public DemoHelloWorld()

public void setName(String value) { m_name = value; }
public String getName() { return m_name; }

public String getOutput() { return m_output; }

public void onHello(ActionEvent ae)
    if (m_name == null)
        m_output = "No name set.";
        m_output = "Hello World, "+m_name+"!";

The development of the web interface happens thus without a line programming of JavaScript and without any knowledge of HTML / CSS / Web frameworks.

Immediate efficiency advantages

For some, especially web developers, such a framework is initially restrictive, but robs them the ability to even in the browser with HTML and JavaScript to develop – and that’s finally something “pretty cool”! However, “seasoned” application developers recognize the efficiency benefits:

  • Application development itself has virtually nothing to do with the complexity of client development. It only defines and programs the dialogs on the server side. Application development makes web dialogues, but does not have to master JavaScript, for example.
  • Interaction processing and logical processing run in the immediate vicinity of the server – and do not need to communicate with each other via external interfaces.
  • The communication between client and server takes place automatically with a blocking: a user action (eg user presses button) is exactly connected with a roundtrip. The ability to run both fast and slow connections is guaranteed.
  • The data exchange between browser and server is easy to handle from a security point of view. There is only one external interface: the communication channel between web renderer and server.
  • The explicit “skillset” for developing web dialogs is in the hands of a few specialists and does not need to be extended to the entire application development.

Long-term efficiency advantages

The explicit decoupling of a web render from a server via an explicit protocol brings long-term stability and efficiency. So it is now possible to exchange the web renderer for another renderer without the underlying application on the server noticing it.

What initially sounds like “theoretically correct” also happens in practice. For example, the aforementioned CaptainCasa Enterprise Client was built using the renderer technique in 2007, but with a java-swing-based renderer. In 2012, a JavaFX renderer based on the same protocol was deployed. Then in 2015, the web renderer was made available. An application that was developed in 2007 and then ran on the Java Swing Renderer, runs today without conversion on the Web.

Disadvantages of server-centric dialog development

Of course, the problem side of a server-centric approach should also be mentioned here:

  • From a network usage perspective, the fact that application interaction is controlled by the server can potentially increase the number of roundtrips between client and server. While there are fewer “heavy-weight-roundtrips” with large amounts of data, there are potentially more “light-weight-roundtrips” with small amounts of data.
  • Each user occupies a certain amount of memory ( session state ) in the server at runtime. This, in turn, must be considered when scaling an application. Scalability over thousands of users is no problem when it comes to handling millions of users, this is a knockout criterion. But then you also know why you give up the efficiency benefits and why you really have to develop directly in the web client!

Suitability for business applications

The server-centric approach is well-suited to efficiently and consistently develop the core dialogs (clerk, worker, power user) of a business application for years to come. It allows existing z. For example, Java development teams can jump into the Web world without being directly confronted with their complexity.

The server-centric approach is an efficient way to decouple application development from framework volatility in the Web space. Disadvantages of the server-side approach usually play no significant role in the core area of ​​applications, in particular scalability in the millions of users is not given here.


Keep an eye out for developing business applications on the web: there are different approaches and there is a healthy volatility of opinions and hypes! The idea of ​​”everything with a framework” is a wrong approach on the Web.

  • The area of ​​internal core dialogues is characterized by longevity, stability, performance, efficiency and visual equality through hundreds of dialogues. The server-centric approach is suitable for this.
  • The range of external dialogues z. For end consumers, for example, it is characterized by explicit design, high frequency of change, cool gadgets, and scalability in potentially very high traffic levels. And here the client-centric approach is beneficial.

Source: https://www.informatik-aktuell.de/entwicklung/programmiersprachen/effiziente-entwicklung-von-web-benutzeroberflaechen-fuer-geschaeftsanwendungen.html

Share This:

Powered by FrontNet