Native surfaces are Legacy! Fig. 1: Case worker scenario in the browser. © Björn Müller Business applications have their own characteristics

• 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”).

Mainstream: client-centric development of web applications

functionality

HTML / CSS

JavaScript

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

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

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

efficiency analysis

Long-Term Consideration – Framework Volatility

Server-centric development of web applications

functionality

Framework needed

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

example

<t:rowtitlebar text="Some demo..." />
<t:rowbodypane >
    <t:row >
        <t:foldablepane rowdistance="5" text="Hello world!" width="100%" >
            <t:row>
                <t:label text="Your Name" width="120" />
                <t:field text="#{d.DemoHelloWorld.name}" width="200" />
            </t:row>
            <t:row>
                <t:coldistance id="g_ccpreview_9" width="120" />
                <t:button actionListener="#{d.DemoHelloWorld.onHello}" text="Hello!" />
            </t:row>
            <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%" />
            </t:row>
        </t:foldablepane>
    </t:row>
</t:rowbodypane>
<t:rowstatusbar/>

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.";

    else

        m_output = "Hello World, "+m_name+"!";

}

}

Immediate efficiency advantages

• 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

Disadvantages of server-centric dialog development

• 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

Conclusion

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