Coding / Programming Videos

Post your favorite coding videos and share them with others!

Efficient development of web user interfaces for business applications

Source link

Laptop Apps Icons
© Chinnapong /

Native surfaces are Legacy!

interfaces are now also expected in application areas that involve the
internal use of a system: clerks, workers, power users.
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

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

  • 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
    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

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:

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

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

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 link


Leave a Reply

Please Login to comment
2 Comment threads
0 Thread replies
Most reacted comment
Hottest comment thread
0 Comment authors
Recent comment authors
newest oldest most voted
Notify of

… [Trackback]

[…] Find More here|Find More|Read More Infos here|Here you will find 16036 additional Infos|Infos to that Topic: […]


… [Trackback]

[…] Find More here|Find More|Read More Infos here|There you can find 93258 additional Infos|Infos on that Topic: […]

Translate »